TIBCOmmunity Server Syndication Feed

GI Forums and Blogs Have Moved to www.generalinterface.org

dhwang — Tue, 12 Jan 2010 19:38:05 GMT

General Interface Forums and Blogs have Moved

If you didn't already know, as part of the GI Open Source contribution to Dojo Foundation, General Interface forums and blogs are now hosted on www.generalinterface.org.

GI developers and contributors will continue the blogs and forums post on the new site.

You can access the new forums at General Interface Forums

The new blogs are at GI contributor blogs

Here's an RSS URL

Look for news on GI 3.8 releases, GI 3.9 features and latest on GI 4.0 on www.generalinterface.org.

This will be my last blog on TIBCommunity, but not the last blog for GI. So we look forward to seeing all developers on the new General Interface Forums

OSGi DevCon 2010

tdiekman — Tue, 22 Dec 2009 18:20:33 GMT

It is this time of the year again, when the call for submissions to EclipseCon and OSGiDevCon went out and were answered numerously.

OSGi DevCon 2010 will be again hosted together with EclipseCon 2010 in March in Santa Clara, CA. Register early to get a significant discount as alumni or OSGi Alliance member.

This time, I was honored to be asked to join the program committee of OSGi DevCon. Together with Andreas Kraft, Christer Larsson, Mike Francis, and Peter Kriens we went over all submissions to find a good balance and interesting program. We haven't finalized the program yet, but we are getting closer to a consensus about the allocation of the time we were given.

I must say I am impressed with the variety and quality of the proposed talks. If I had the chance, I would go to all of them. Unfortunately, we will need make some choices and disappoint a lot of potential speakers.

The final list will be published beginning of 2010, so stay tuned.

Tim.

Introducing Space Browsers: the easiest way to create distributed applications or services

JNM — Mon, 21 Dec 2009 21:58:16 GMT

ActiveSpace Browsers

Well, it has been a little while since my last post, and I think it is very much time to post some new information on ActiveSpace by introducing a new concept that is specific to ActiveSpaces and we believe extermely useful: the Space Browsers.

Space Browsers are a very simple to use yet very powerful feature of AS that allows programmers to implement the following architectural paradigms in order to create truly elastic distributed applications and services:

Iterating over a subset (view) of the entries stored in a Space
Continuous Queries
Using a Space as a distributed Queue
Grid computing paradigms such as Map/Reduce

Space Browsers (and Listeners) complement the Space’s basic put/get/take/lock methods (which require the user to provide a specific value for the key fields, and therefore operate on a single Space entry at a time) with the ability to ‘iterate’ through sets of entries for which the exact key field values are not known in advance.

A Space Browser is an object that can be seen as a sort of continuously updated iterator over entries stored in a Space. I say ‘sort of’ because, like an iterator, it has a ‘next()’ method which returns the next entry to ‘work’ on, but that’s where the similarities stop.

Browsing over a Space view

Let’s look at the first use case: iterating over a ‘view’ of the entries stored in a Space: when a Browser is created over a Space an optional filter string can be passed that will refine the set of entries being considered by the Browser.

In ActiveSpaces filters (which can be applied to both Browsers and Listerners) follow the SQL-92 syntax and implement many (but not yet all) of its clauses, put simply a filter is the part of a query that follows the ‘where’ statement in a ‘select * from Space where …’ query.

For example if a Space ‘customers’ contains Tuples that have an ‘Age’ field, browsing through all of the entries in the Space for people aged less than 30 years old is as simple as passing the string “Age < 30” as a filter when creating the Browser.

Continuous Queries

However unlike a query in a database that works only on a snapshot of the data contained in the database at a specific point in time, Space Browsers are continuously updated according to the changes in the Space being browsed and can be open-ended, effectively providing ‘Continous Query’ capability of the data contained in the Space. To that extend and unlike a more ‘traditional’ iterator object, the Browser objects do not have a ‘hasNext()’ method, but rather have a timeout value. That value is the amount of time the programmer is willing for the final ‘next()’ call to block for while waiting for something new of ‘next’ on.

Because of the low latency orientation of ActiveSpaces, a blocking 'next()' will unblock and return the newly inserted or updated Tuple in real-time as soon as the change happens, and that no matter how many Listeners or Browsers may be interested in that new Tuple.

Using a Space as a distributed Queue

This continuous real-time updating of the Browser also means that changes happening to the data in the space are automatically reflected on the list of entries about to be browsed as they happen: a Space Browser never gives the user outdated information!

For example, if an entry existed at the time the Browser was created, but this entry gets taken from the space before the Browser’s ‘next()’ method gets to it, then this entry will not be returned by the ‘next()’ method.

Also, unlike a traditional iterator that only allows its users to look at a series of data items, Space Browsers allows users to not only look but also operate on entries in an iterative manner. To that extend Browser have a ‘type’ that influence the type of operation applied to the entry when the Browser’s ‘next()’ method is invoked:

The GET Browser’s ‘next()’ method does a ‘get()’ on the next entry to browse (very much like a regular iterator).
The TAKE Browser ‘next()’ method however does a ‘take()’ on the next entry (that is, it atomically retrieves AND removes the next entry currently availbe to take from the space).
The LOCK Browser ‘next()’ method does a ‘lock()’ on the next entry to browse (that is, it atomically retrieves AND locks of the next entry currently available to lock in the Space).

Because of the fact that Browsers are continuously updated in real-time according to the changes in the unerdlying Space, TAKE and LOCK Browsers effectively (and very simply) allow 1-of-n ‘consumption’ of the entries stored in a Space. No matter how many TAKE Browsers may be created over a Space (even if those Browsers are created by many separate processes deployed on many separate physical hosts), what is taken from the Space by one Browser’s ‘next()’ method will NEVER be taken by another Browser’s ‘next()’ method, thereby allowing the programmer to use a Space like one would use a store-and-forward messaging Queue (for temporal and localization de-coupling, analoguous to the ‘master/worker’ pattern in Space-based architecture for example), except that in our case the Tuple ‘Queue’ being a Space, it can be distributed and scalled up as needed.

Writing elastic applications and services made easy

Creating a distributed service is therefore extremely easy to program using ActiveSpaces, clients simply put requests in a ‘request’ space, and servers simply create a TAKE (or LOCK) Browser on the Space, when ever a new request is put in that space by a client, it is automatically taken by one (and only one) of the servers for processing (and the reply Tuple can be put in a ‘reply’ Space), all the implementer of that service has to do is invoke ‘next()’.

The code below is a copy-and-paste of the part of the ActiveSpaces example server-side program that shows this feature, in this example the program waits for a request to be put in the 'request' space (by the client-side example program) and 'processes' it by adding a new field to the request tuple and putting this updated tuple into the 'reply' space. If there is no new requests to process after 500 milliseconds the program just prints out a status of the number of requests it has processed so far and goes back to waiting for more requests.

        // Create a Take Browser on the request space with a timeout of 500 milliseconds
        BrowserDef browserDef = BrowserDef.create().setTimeout(500);
        Browser takeBrowser = null;
        try {
            takeBrowser = metaspace.browse(space_req.getName(), BrowserType.TAKE, browserDef);
        } catch (ASException e) {
            System.out.print("Problem creating the take browser: " + e);
            return;
        }
 
        // the TakeBrowser allows the use of the 'request' space as a queue 
        Tuple tuple = null;
        SpaceEntry entry = null;
 
        do {
            // Try to take a tuple from the space
            try {
                entry = takeBrowser.next();
                // if next() returned an Entry, we successfully took/consumed the entry from the Space
                if (entry != null) {
                    tuple = entry.getTuple();
                    // add the replyer field to the tuple and put it into the reply space
                    tuple.put("replyer", selfmember);
                    space_resp.put(tuple);
                    served++;
                    if (served % 100 == 0) {
                        System.out.println("I have serviced " + served + " requests");
                    }
                } else // there is nothing to take: the next() timed out and returned null
                {
                    System.out.println("I have serviced " + served + " requests and I am waiting for more");
                }
            } catch (Exception e) {
                System.out.println("Exception in the take browser: " + e);
            }
        } while (true);

New server instances can be added (or removed) on the fly, without service interruption, thereby allowing ActiveSpaces users to create ‘write-once, deploy as many as you need’ elastic applications.

Subscription with 'Initial Values'

But that’s not all of what you can do with a Space Browser: Browsers (and Listeners) have two associated scopes that can further refine (than a filter) the set of entries being browsed.

The ‘time scope’ can be used to narrow down the period of time of interest:

'SNAPSHOT' means that the browser starts with all the entries in the space at the time the browser is created (or initial values), but is not updated with new entries that are put into the space after that moment.
'NEW' means that the browser starts empty, and is updated only with entries (or associated events) put into the space after the moment of the browser’s creation.
'ALL' means that the browser starts with all the entries in the space, and is then seamlessly continuously updated with new entries as they are added into the Space. Readers familiar with pub/sub messaging systems will note that creating a Listener with a time scope of ‘ALL’ allows then to receive ‘initial values’ before they start receiving future publications.

Grid computing programming made easy

The other scope of Browsers and Listeners is the ‘distribution scope’ and it can be used to narrow down the set of entries according to their distribution over the Space's seeders:

‘ALL’ means that all of the entries stored in the Space will be considered, regardless of where they are being seeded
‘SEEDED’ means that only the entries assigned to the local metaspace member on which the Browser/Listener is created will be considered.

What may not be obvious right away is that the distribution scope of ‘SEEDED’ is the gateway to easy creation of grid-computing applications using (for example) a Map/Reduce pattern.

The Map/Reduce pattern can be described as follows: a very large data-set is divided in a set of Key/Value pairs (or in the case of ActiveSpaces in a set of Tuples) that are evenly distributed over a set of nodes (i.e. a Space’s seeders): this is the ‘mapping’ phase. Each node then processes the subset of the data that was assigned to it and puts the result of it’s processing (a smaller or equal set of Tuples) in another Space for the client to retrieve (or for another set of nodes to process): this is the ‘reduce’ phase. Most grid computing applications can be architected as a series of ‘Map’ and ‘Reduce’ phases.

This type of grid computing applications is very easy to create using ActiveSpaces: ‘mappers’ are simply nodes that join a ‘mapping’ Space as seeders each one creating on that space a Browser with a distribution scope of ‘SEEDED’ and just need to invoke ‘next()’ on that Browser: every time a new subset of the data is mapped to a specific node, that node’s ‘next()’ method will return with the new tuple to process. Alternatively a ‘control’ Space could be used to coordinate which mapping or reduce phase of the overall process is currently being executed if a more ‘batch’ rather than ‘event-driven’ type of processing is desired.

Conclusion

In conclusion, while I didn’t even describe completely all of the features of the Space Browsers and Listeners (for example the EventBrowsers), I hope I will have been able to show the power of the Browser concept and the various ways they can be used, and how they greatly simplify the work of the application programmer allowing them to very easily create elastic distributed/grid-enabled applications and services.

So, what's next in OSGi?

tdiekman — Mon, 07 Dec 2009 01:32:03 GMT

With the release of the Enterprise Profile beginning of 2010, this is not the end of the EEG

Our agenda is full and in full steam. In the next meetings we will go further into the details of

Subsystems, or what is commonly referred to as 'applications'. After agreeing on the requirements we are now commencing the detailed design work

OSGi Bundle Repository (OBR). This relatively old spec is now being worked on again after we have agreed on the requirements and mandated the detailed design work

Namespace. The support for namespaces was left out of the Blueprint spec in R4.2 and will now be completed

Weaving. The support for byte code weaving is essential to many specs, but quite difficult to do right.

Web Container API. The current spec does not allow for programmatic web app creation yet.

Multiple Extenders. The more extenders we have in the system, the more their interaction needs to be coordinated or the system becomes unpredictable. We have agreed on the requirements and start detailed design work now.

Asynchronous Communication. The integration of JMS and other pub/sub, request-response, etc. technologies will be a major part of the next OSGi version

... and many more interesting technologies.

You may also be interested to learn that OSGi APIs are finally catching up with JAVA 1.5 constructs. Thanks to interesting compiler options like -jsr14 it becomes possible to use Generics in the API while still providing backward compatibility for the mobile users, who's APIs are limited to 1.4.

Stay tuned,

Tim.

OSGi Enterprise Profile released

tdiekman — Mon, 07 Dec 2009 00:00:50 GMT

Welcome to my OSGi Blog @ TIBCO.

If you are looking for TIBCO specific information about OSGi, then I have to disappoint you. This blog is meant for communicating Enterprise Export Group related information to the greater OSGi community. The EEG is open only to OSGi Alliance members and it is up to the group members and especially the chair-men to open up the communication and information flow.

You may have heard that my co-chair since the inception of the EEG in late 2006, Eric Newcomer, has moved on to new responsibilities, which unfortunately do not allow him to stay involved in the OSGi work. I am very grateful to Eric for his help and mentorship.

However, we are very happy to have found an excellent successor in David Bosschaert from Progress Software.

Ok, back to business.

For the last three years the Enterprise Expert Group has worked on integrating mostly J* specs with OSGi in a manner that makes it easy for JEE developers to run existing JEE applications in OSGi while at the same time with only minimal adjustments to the design to allow for making optional use of the unique OSGi capabilities. One example of this adaptation is JNDI. For the JNDI spec, we have come up with an elegant way of using JNDI capabilities through services, while at the same time allowing for existing hard wired application to run in OSGi in "traditional" mode. You may also read this as "classic" or "legacy" depending on where you stand on the JEE vs. OSGi debate. In a similar fashion we have worked out the integration of JPA. Others map easily and elegantly without a lot of complications, e.g. JTA and JDBC.

In addition, in the enterprise profile we introduce new capabilities to OSGi, which are not driven by JAVA specs, i.e. Remote Services and Remote Service Admin Service. These powerful concepts allow for scaling of OSGi services across JVM boundaries and open up a whole new set of designs and use cases.

What is the Enterprise Profile now?

Glad you asked. Let me start by saying what it is not:

It is not an all-or-nothing specification document that requires compliant implementations to support every service listed. As such there is no single TCK that can be run against an implementation to claim compliance.

Instead, the profile is a collection of services from the core, compendium, as well as new enterprise driven services, which will ultimately be part of the compendium itself. The Enterprise Profile is the first point of reference for enterprise developers looking for guidance in the vast amount of spec documents. The first question someone new to OSGi typically is driven by is

'What is relevant to me? Do you expect me to read the entire 400 pg. core spec plus the 800 pg. compendium stack before I can do anything useful with it?'.

The introduction chapter to the spec is trying to put the services in context with typical use cases that developers can follow and identify themselves with. The following chapters are literal copies of the relevant chapters from the core and compendium specs for easy reference.

When you download the current draft you will notice that the list of included services seems incomplete. Indeed it is. The final version will also include already published and final specifications like Configuration Admin Service and Blueprint.

Where can you find the public Enterprise Profile?

The public interim draft can be found at the public OSGi web site for download by everyone.

In the near future we plan to release the final version and make it available for the general public. We encourage the OSGi community to take advantage of it, try it out, and provide valuable feedback about what works and what does not.

Stay tuned for more updates of the EEG at this location.

Tim.

What is BusinessEvents "advanced Rete"?

pvincent@tibco.com — Fri, 20 Nov 2009 20:59:43 GMT

Steve Nunez (who usually works with multiple BREs) posted a comment in another vendor blog post including:

"I'd hardly call TIBCO's rete implementation 'enhanced' or to have 'full rule engine capabilities'"

Strong words! So lets list what enhancements BE has over "standard BREs" in the rule engine department:

1. event processing - in other words built in channel and event support. {Most BRE's have a single, invocation interface...}

2. event cache - in other words shared storage for events and concepts, and built-in object-backing store persistence. {Most BREs rely on J2EE to do this, or have the equivalent of DBConcepts}

3. multi-threaded Rete - see the latest BE3HF and will form part of BE4 {Most BREs don't yet have good explicit thread control}

4. concept history option

5. compile-to-bytecode architecture

But BE doesn't have a few things other BREs tend to have: built-in J2EE container support, for example (BE is a J2SE component and is its own platform, for performance reasons). BE also does not have the separation of "update an object versus working memory", whereby some BREs require you to explicitly call the engine to update the WM value of an object you update in an action. Except in the context that in BE you can define concepts in-memory (local only) vs cache (shared across engines), which is somewhat different .

What about "full rule engine capabilities"? BE's philosophy is certainly different to "interpreted" BREs in that the rule language is "simpler". If you want to do aggregations in a condition - well you shouldn't in BE, whereas other BREs allow that with commands like "accumulate". The basic Rete architecture - mapping declarations to tuples of all combinations of those declarations then applying filters and joins per the conditions - as described in standards like OMG PRR - are what BE concentrates on.

"It's often very fustrating to express conditions when you don't have expressions as basic as a 'not' or existential operators."

You can do "not" expressions on those filters and joins, but no quantified expressions (eg if at least one tuple, if n tuples, ...etc ), or array restrictions (eg declaration X in array Y.Z). So why these "restrictions" in rules?

Well, one answer to that is that usually, quantified expressions are about statistics or aggregations on your working data. This is precisely what you'd want a query language for - and what BE provides in BQL. So the term "at least n" or "sum of" are in fact business terms that warrant declarative declarations in their own right - for example, creating an event that can be referenced in a rule.

Of course, there are some rules and event patterns which may be easier in a rule, some in a query, some in a combination... and there is probably room for more language types to support CEP and features to allow these other languages to support rules better. (Customers and partners under NDA who have seen the BE roadmap will know what I am talking about here).

AFAIK, no BRE includes a separate "query language", although some come close, eg by allowing shared / common rule conditions.This does mean that developers used to a "everything goes in the rule" approach need to change view slightly when using BE, which also includes state models, timer rules, etc to support the CEP mission.

{Note that I am not claiming the BE rule language is not going to be extended in future, nor that some of the other BRE extensions would not be useful in BE!}

Reminder on BusinessEvents 3.0 feature list

pvincent@tibco.com — Mon, 26 Oct 2009 13:31:24 GMT

Here is a quick status update on the spec for TIBCO BusinessEvents 3.0:

- graphical models: concept, event (UML Class), state (UML State)

- graphical reports: project analyser/debugger

- event processing languages: rules language, BusinessEvents Query Language (BQL)

- event processing agent types: inference node, query node, cache node

- architectures: any combination of agents in any processing order

- event persistence: in-memory, cache (Coherance), checkpoint (BerkeleyDB), backing store (Oracle), any combination thereof

- rule engine capabilities: inference (Rete-type), defined statically (project-level code persistence), compiled to bytecode

- query language capabilities: static and continuous queries, defined dynamically (run-time code compilation)

- dashboard: provided through Syndera, RTView, GE / AJAX UIs

- business user interface: Decision Manager (for decision tables) BRMS

- business user interface workflow control: Rule Management System, customisable

- standard channels: EMS, RV, internal

- standard interfaces: DBMS (Oracle DBConcept), BW

- packaging: with and without state model / engine (Enterprise, Inference editions)

The key to Elasticity, and why you need it

JNM — Mon, 14 Sep 2009 22:02:17 GMT

We have been very busy working over this summer on ActiveSpaces, so busy in fact that a new post is way overdue on this blog. Fortunately for you readers, being stuck in some random coach seat for well over 12 hours without net access (but with a spare battery ) means that I finally got around to write down some of my thoughts on Elasticity, fault-tolerance and maximizing infrastructure. Unfortunately there's lots to write about those subjects and I had more than one of those long flights to go through, so my apologies if this post is a bit lengthy.

Premise:

There is currently a lot of talk about 'cloud computing' and/or 'elastic computing', but what defines exactly elastic computing, and what does it do for you, why would you need it? And how does it all relate to ActiveSpaces?

Let me answer the most practical question first: why do you need your computing infrastructure to be elastic? The most important answer is very simple: to save money by optimizing your resource utilization, because 'idling' or 'stand-by' hardware and software (licenses) cost your enterprise money without being productive. Other reasons include the ability to maintain your SLAs in the face of extremely variable load conditions and of hardware and software faults.

One of the design goals of AS is to provide an infrastructure to be used for the creation and operation of 'Elastic' applications and services. And by 'elastic' I mean more than just 'distributed': and yes, there IS a distinction, which I will now try to explain. In order to understand the difference between those two terms let's first define them:

Distribution is the ability to divide a task into smaller sub-tasks that can be executed in parallel. It is what allows a distributed application or service to 'scale out': write the code once, and run it on as many machines as needed in order to achieve a target Service Level Agreement given a specific request load.

Elasticity, as it's name implies, when applied to an application or a service, describes the ability to to easily and seamlessly 'scale up' (add more resources in order to increase the overall processing power when needed) and 'scale down' (being able to 'switch off' some of those resources when the load on the overall system goes down and the system is over-provisioned). Obviously in order to be elastic, an application or service has to be distributed, but the reverse is not necessarily true!

The distinction between these two terms hinges on the keywords 'easily' and 'seamlessly': a distributed application or service is not elastic if it has to be brought down and reconfigured in order to take advantage of a new host or instance of itself, or in order to decrease the number of instances.

To take a practical example, compute clouds are elastic: they let you to add and remove machines, their associated OS and file-system images by simply invoking a web service. This means that clouds provide the elasticity of the hardware and of the platform, and can even fire up another instance of your application. However if your existing (or remaining) application or service instances have to be notified or configured in any way to be told to make use of (or stop using) this new instance, you do not have true elasticity of the software and therefore of your service.

So, why do you need to make your applications and services elastic? There are plenty of reasons, but as stated earlier for me the most important one is the following: the load generated by your business is almost never constant, it varies over time, and many studies have shown that in the increasingly digitized world we live in there is an ever increasing gap between your average load and you peak load. There are also plenty of material documenting the increasing impact a degradation of the performance of the service a business is providing has on the bottom line: customers are increasingly volatile, and the competition never more than a click away. Not meeting your SLAs to your customer means in some cases means they are entitled to a discount and will impact your revenue, and in some industries not meeting SLAs can even result in fines being imposed. There is even measurements by Google and Amazon suggesting that increases measured in milliseconds in the serving of a web page resulted in lower number of page views.

The traditional approach to this problem has been to size and provision the infrastructure for the peaks not for the average load: this is obviously an expensive proposition as it means that some (in some cases, most) of the infrastructure will most of the time just sit there idling, waisting electricity and costing money when the load is not at its peak.

The development of virtualization technologies and now of the cloud computing (and in the future the use of technologies like Complex Event Processing to anticipate and pro-actively prepare for the changes in the load) paradigm have been becoming increasingly popular because they allow the enterprises than know how to leverage them to save a lot of money by easily sizing up or down ('elasticizing') your hardware infrastructure as you need it optimize. However hardware and os virtualization only provide part of the overall solution: a service is composed of more than just the platform is runs on, the software that implements the service also need to be elastic in order to 'close the loop' and automate the re-sizing of the complete stack and to be able to react to expected or unexpected variations of the load.

ActiveSpace Elasticity:

As mentioned at the start of this post, ActiveSpaces is an in-memory data and messaging grid that allows application programmers to create elastic applications and services extremely easily. This is due not only to ActiveSpace's API and to the fact that the Space-based architecture is a natural match to distributed systems, but also to the fact that ActiveSpaces itself is elastic: nodes/applications/machines contributing storage and computing resources can be added and removed from the Metaspace (the cluster of nodes working together) on the fly, without requiring any change to a configuration file (as there are exactly zero configuration files!) or without needing to run a specific deployment manager application and without any service interruption.

Start with a single node, scale up by simply starting another instance of your application on any machine on the network, and back down according to your load and SLAs by simply stopping one of those instances, there is no need to do anything other than start and stop processes or new instances of your application on any node on the network.

How is this possible? Because ActiveSpaces is built using a true peer-to-peer distributed architecture. In order to really understand what this means allow me to explain a bit more how it works and how it compares to other kind of architectures typically used by other data-grids or distributed caches.

First let's define the problem that needs to be solved: since a Space is used to store data, in order to scale a Space over multiple machines a distribution mechanism has to be used to distribute the storage and management (what we call the 'seeding') of basic data elements (in our case, tuples (i.e. 'database rows')) as evenly as possible over the set of cluster members (that we call 'seeders'), this is also sometimes referred to as 'partitioning'. At the same time in order to be enterprise production quality the distribution mechanism has to be able to provide resilience to node failure (i.e. 'fault-tolerance' or the ability to survive the sudden loss of a machine without incurring the loss of any data stored in the Space).

Distribution:

ActiveSpace uses a proprietary group membership protocol and peer-to-peer 'distribution algorithm' that allows each member of a Space to quickly (and independently) find out which member of the Space (i.e. which 'seeder') is responsible for the storing of a particular tuple and to send the request directly to the appropriate seeder.

Compare this to more traditional techniques where the mapping of specific data item to specific cluster member nodes (the 'partitioning' of the data) is handled by a centralized server (i.e. a single member node of the cluster that takes over the role mapping lookup server role), requests to read or write data have to include either a 'lookup' operation with the server (and therefore a network round trip), or be redirected by that server node (which will sooner or later become a bottleneck to the performance and scalability of the overall system).

Another disadvantage of the techniques and algorithms used by other data-grid systems is that they typically require configuration files to be created listing the addresses of all the nodes potentially participating in the cluster, or the potential maximum and minimum number of partitions to be used. Those files not only have to be distributed to all the nodes, but they have to be kept in sync for the cluster to work properly (as an aside, I find it slightly ironic that some of the existing data-grid products that thrive to provide coherence of the data they store rely on the system administrator to provide coherency of their configuration files in order to work well). Another down-side being that a lot of those systems require you to bring the whole system down, update and re-distribute some configuration files before some changes (sometimes as simple as adding another node, or adjusting the number of partitions) can take effect.

Fault-tolerance:

Even more important than the ability to deal with peaks in the load without performance degradation, is the need to make the services fault-tolerant. A problem that has traditionally been solved by making the infrastructure redundant and deploying (and buying) everything twice in order to have an idling backup ready to take over in case the primary fails, what is called an 'active-passive' fault-tolerance architecture.

ActiveSpace Tuplespaces can be made tolerant to the sudden catastrophic failure of one of the nodes (seeders) in the cluster by specifying a 'degree of replication' for that Space: a degree of replication of one means that any single node can fail at any time without an data being lost, a degree of replication of two means that up to two nodes can fail at exactly the same time, and so on. ActiveSpaces uses the same peer-to-peer 'distribution algorithm' in order to provide fault-tolerance of the service it offers: the algorithm is not only able to determine which cluster member (seeder) is responsible for the original storage of the tuple, but at the same time it determines which node is responsible for the first degree of replication, which node is responsible for the second degree, etc…

Besides speed and scalability this algorithm has a couple of very important advantages:

- 'active-active' fault-tolerance: there are no standby 'cold', or even 'warm' nodes that do nothing but wait for a 'primary node' to fail.

- The replication itself is distributed: what is stored (seeded) by one node is uniformly and evenly replicated over all of the other nodes in the cluster. This not only makes degree of replication higher than one possible, it also means that after a sudden catastrophic node failure, the distribution of the tuples remains balanced.

Compare this to more traditional techniques where nodes responsible for the storage of data are deployed in fault-tolerant pairs, one node being the 'primary' node doing all the work for the partition of the data that has been assigned to it, and the other node being a standby 'backup' node that does nothing but use electricity and rack space until the primary node fails and in the worst case requiring the deployment of a usually very specific type of shared file system between the two nodes (worst-case because besides the extra complexity and price of a shared file-system the secondary node needs to read all of the data from that shared file system to come up providing for less than optimal fail-over time). Another disadvantage of the primary/secondary fault-tolerance architecture is that it can not provide a degree of replication higher than two: if both primary and secondary servers fail, not only is data being lost, but the given that some of those systems can not deal with all of the nodes assigned to a particular partition being down at the same time, the whole system will actually go down.

Conclusion:

ActiveSpaces provides true elasticity to your distributed applications and services. It is able to do this because it is thoroughly elastic itself: its true peer-to-peer architecture allows it to scale up and down on the fly without requiring any reconfiguration or user intervention other than starting another instance of an ActiveSpace-enabled process on the network. This peer-to-peer architecture and algorithms also means that fault-tolerance is 'active-active' and that none of the nodes participating in the nodes are idling unused as 'passive' backup servers, thereby optimizing the usage of your existing infrastructure, and saving money.

Virtualization and Its Affect on Architecture

abailey — Wed, 15 Jul 2009 11:16:52 GMT

A couple of days ago I posted a comment to the general TIBCOmmunity regarding virtualization. However, I feel it was not the appropriate place to publish my observations on virtualization. I am including the text in this blog, because of the ramifications virtualization has on architectural decisions.

Virtualization: Hyper-V, VMware, and Xen

Over the past year I have been involved in several project that use VMware, and I have used Hyper-V on my own systems. I do not have any experience using Xen, so I will not go into detail about it.

Virtualization In General

While VMware, Xen, and Hyper-V offer the benefit of better hardware utilization and easier management, there is also a downside to using virtualization. Performance is the major drawback. Processing seed is reduced between 10% to 25% (VMware claims 15% reduction) , and I/O (mainly network) can be reduced by as much as 50%. All of the vendors have tuning guides, and you should follow the suggestions in these guides if you want to achieve the best performance possible.

All virtualization hosts require resources to manage the guest operating systems. If all of the CPUs are used by guest OSs and the host needs to do some processing it will swap out one of the guest OSs and take command of one of the CPUs. Once the host is finished processing the gust will return to normal. This delay is typically less than a second, but if you have latency sensitive operations in the guest OS you should make sure that there is at least one free CPU for use by the host OS. Also, I would reserve around 1GB of RAM for the host OS.

Programs that use a lot of disk I/O like large databases, and programs that require very low latency should not be put on virtualized guest OSs. I also would advise not putting EMS or RVRD on a virtual machine. With EMS I have seen as much as 75% decrease in performance running on VMware ESX 3.5 Update 3.

Microsoft Hyper-V

Hyper-V supports a very broad set of hardware. Just about any system with 4GB or RAM and a CPU that supports Intel VT or AMD-V will work. The performance of Window Server 2003 R2, and Windows Server 2008 guest OSs are excellent. I have found that once everything was tuned the CPU reduction was between 10% and 15%, and the network performance was only reduced 10%.

In Windows Server 2008 the management applications are not very good, but that should improve in Windows Server 2008 R2. However, it still has a long way to go before it will have the feature list of VMware.

Although Microsoft claims to support Windows Server 2000, Windows XP, and SUSE Linux Enterprise Server 10 SP1/SP2, the support for these OSs are pretty poor, and I would suggest not running them on Hyper-V.

VMware ESX

VMware ESX is by far the most popular virtualization host. It also offers the most management features. VMware ESX requires an exact set of hardware to work. The complete list is on the VMware’s web site, but must hardware vendors will offer servers that are specifically designed to work with VMware ESX. ESX 3.5 and ESX 4.0 offer good guest CPU and network performance. I have seen and reduction of 15% to 20% in CPU performance and a reduction of 15% to 20% in network performance.

Version before ESX 3.5 Update 2 did not have good network performance. With ESX 3.0.2 I experienced an I/O reduction of more than 60%. I highly advise running TIBCO applications only on ESX version 3.5 Update 2 and above. The new ESX 4.0 promises many performance improvements, but I have not run any test on it yet. We will have more information in November after TIBCO India completes their performance tests on ESX 4.0.

VMware ESX supports a large number of guest OSs, With Windows Server and Linux being the most common. However, Red Hat Enterprise Linux version earlier than 4.7 and 5.2 have a interrupt timing issue with ESX, and should be avoided. Even with RHEL 4.7, 5.2, and greater you have to put divider=10 as a boot parameter in GRUB to alleviate this timing issue. Please follow the instructions in the VMware guide “Installing and Configuring Linux Guest Operating Systems”. You can find it on the VMware support web site. Although VMware publicly says this is just an issue with the machine time, it actually causes problems with I/O interrupts drastically reducing performance. Therefore, do not run RHEL guests unless you have the divider=10 in the GRUB.

The new VMware vShpere (ESX 4.0) suite offers many new exciting features like active fault-tolerance and site recovery manager to name a few. However, these features have numerous limitations and you need to look at the fine print. For example, the new active fault-tolerance feature will only work on guest OSs that use one CPU, and the site recovery manager requires special hardware.

Conclusion

Virtualization is great of management and hardware utilization, but it has its limitations. Make sure you know these limitations when architecting a solution, and beware of the performance and latency implications.

Creating a Firebug Log Handler

dhwang — Fri, 03 Apr 2009 20:26:22 GMT

I had this in the draft for a while.. It is actually no longer relavant in 3.7.1. However, I think it may be relavant in a different context of how to create your own custom log handler. So I'm post this now..

While GI always had its own log monitor, it is still useful to be able to log to Firebug which is the single most useful development tool for web devlopers. This is a new log handle introduced in GI 3.7.1, however, what if you're not using 3.7.1? Well the code will still work previous version of GI

It is important that this class be loaded at the very beginning, so you want to add this to the JSX/js/fx/jsx.js file

/**
 * Handles a logging record by sending it to the Firebug console.
 */
jsx3.Class.defineClass('jsx3.util.ConsoleHandler', jsx3.util.Logger.FormatHandler,  nul l,
    function(ConsoleHandler, ConsoleHandler_prototype) {
 
  // maps logger levels to console method names
  var methods = [nul l, "error", "error", "warn", "info", "debug", "debug"];
 
  ConsoleHandler_prototype.handle = function(objRecord) {
    if (window.console) {
      var method = methods[objRecord.getLevel()];
      if (method) {
        try {
          console[method](this.format(objRecord));
        } catch (e) {}
      }
    }
  };
 
});

Logger.xml


  <!-- Logs messages to the Firebug console, when available. -->
  <handler name="console" class="jsx3.util.ConsoleHandler"/>

 <!-- The global logger. -->
  <logger name="global" level="INFO">
    <handler-ref name="memory"/>
    <handler-ref name="console"/>
    <handler-ref name="ide"/>
    <handler-ref name="fatal"/>
    <!--<handler-ref name="appMonitor1"/>-->
  </logger>