Alexandre Alves's Blog

New Blog Account

2008-06-26T01:42:35Z

As several others at dev2dev, I've also decided to have my own personal blog account: http://adcalves.wordpress.com/

CEP, Rules Engines, and SQL

2007-08-14T00:01:00Z

There has been a lot of discussions on the differences between CEP/ESP and rules engines, specifically regarding RETE implementations. I particularly like this entry from Tim Bass on the subject.

In my opinion, the very fact that we are comparing CEP/ESP and rules engines is a sign that these subjects are not yet very well understood.

Partly, the reason for the confusion is that CEP/ESP, rules engines, and RETE are at different levels of abstractions.

CEP/ESP is a technology. It is a collection of techniques, methodologies, and implementation procedures intended on solving a common set of problems of a domain, namely, in the case of CEP/ESP, (loosely speaking) to achieve online processing of streaming data (i.e. events) to support, among other things, real-time business decision.

Although CEP and ESP have different definitions, for the purpose of this article I will use both terms interchangeably.

There are several aspects to CEP: visualization of events, storage of events, programming model for the development of CEP applications, rule (or query) governance, the runtime processing engine, etc.

With respect to the runtime processing engine, there are several implementations options. However, before considering an engine implementation, one must first consider what language, or what language paradigm, should be surfaced to the user so that the user can program to this engine.

One option is to take the well-known imperative programming language paradigm and use any one of the popular procedural or object-oriented languages such as Java as the event processing language of choice that is surfaced to the user. For example, this is the approach taken when one implements their CEP application with hard-coded rules directly in Java.

Another option is to use a more data-driven approach. Considering that one is dealing with events, which is a type or extension of data, this seems an appropriate choice.

Within the realm of data-driven approaches, one option is to use SQL. SQL, needless to say, has proven to be a very convenient and pervasive domain-specific language for dealing with data, which allows one to leverage existing skill-sets. Another common option is to use logic programming. Note that there is an equally intriguing discussion around CEP and SQL currently going on.

Logic programming is a very interesting, but long subject. In a logic programming language, programs consist of a set of statements that specify what is true about a desired goal. This is different than in imperative languages (e.g. Java), where programs specify the set of statements that must be executed to achieve the desired goal.

More specifically, in logic programming, programs contain only logical statements. Logical statements are statements that are either true or false. Logical statements that are always true are called axioms. The role of a logic program is to infer new logical statements called theorems from the axioms through some automated algorithm. The automated algorithm used by the program is called its inference rules. Theorems are the goals that represent the desired results.

Pure logic programming is very powerful indeed. In pure logic programming, at no time one specifies how to derive the goals, that is, there are no control statements (e.g. if-then-else). Pure logic programming is also very hard to implement. Hence people came with simpler models that support sub-sets of the full logic programming paradigm. One of these is called First Order Predicate Calculus.

In First Order Predicate Calculus, logical statements are formed of constants, variables and their quantifiers (e.g. for all values, for any value), predicates, and connectives. Much of the expressiveness and power of First Order Predicate Calculus comes from the connectives. Common connectives are the logic operators AND, OR, NOT. Additional connectives are implication and equivalence. To say that A implies B, means that B is true when A is also true.

It turns out that even the restricted sub-set First Order Predicate Calculus is hard to implement. Thus people have further simplified it in attempts to facilitate implementations; Horn Clauses is the most commonly used sub-set of First Order Predicate Calculus. Horn Clauses do not support the specification of variable quantifiers, and of the equivalence operator, among other limitations. Prolog, probably the most widely used logic programming language, supports Horn Clauses.

Loosely speaking, a rule-based system or rule-based engine is an implementation of a logic programming language, usually based upon Horn Clauses, with some few procedural extensions. These systems are sometimes called production systems. In a production system, logical statements that are constants (i.e. always true or false) are called assertions, and compose what's called the working memory. Logical statements that make use of the implication connective, that is, follow a if-then structure are called productions, and make up the production memory.

Rules engine execute by following a recognize-act algorithm; that is, as new logical statements are made available (i.e. inputted by the user), the engine matches (i.e. recognizes) the left-hand side of all productions against the contents of the working memory. This process results into a set of production instantiations. Next the engine executes (i.e. acts) the right-hand side, called actions, of the matched instantiated productions. The actions may result in new content in the working memory. Changes to the working memory causes the engine to re-enter the recognize-act cycle, which continues until no more matches occur.

One procedural extension to rules engines is to be able to directly manipulate the content of the working memory. This is done in the right-hand-side (i.e. actions) of the productions, where one may create, delete, and modify assertions present in the working memory.

Matching through thousands of productions against thousands of assertions can be quite expensive. A naive approach would cost O(productions * assertions). Matching can take around 90% of the processing time of a rules engine.

So let's consider a way of optimizing this. Essentially what the engine is trying to do is to find out which assertions match against the left-hand-side of the productions, in another word, the end goal is to find a set of productions. What if we create a graph of nodes, where the nodes represent the conditions we are trying to match, and as we traverse the graph matching these nodes we eventually reach a terminal node representing the production for which the conditions apply?

For example, consider the following four productions P1, P2, P3, P4:

P1: if attr1 = 'value1' and attr2 = 'value2' then action1

P2: if attr1 = 'value1' and attr2 = 'value3' then action2

P3: if attr1 = 'value4' and attr2 = 'value5' then action3

P4: if attr1 = 'value6' and attr2 = 'value7' then action4

The corresponding matching graph is:

Now consider that assertion A is inputted:

A1(attr1 = 'value1', attr2 = 'value2')

The first step is to match for attr1, which will take the engine to the child node n2, and then to match attr2 to the terminal node P1, which is our goal. This has a total of 4 comparisons in the worst-case. A (very) naive implementation would take 8 comparisons in the worst-case.

Although over-simplified, this is the general idea of the RETE (i.e. Latin for network) matching algorithm invented by Dr. Charles Forgy. RETE also has additional considerations for optimizing the handling of the binding of variables, of joins, and techniques for keeping the network of matching nodes up-to-date, among other things.

RETE is a very efficient algorithm for performing matching in productions systems. Does it look as if it is generic enough in its entirely or parts of it to be used in different contexts? Yes, it certainly does to me. In fact, we use some of the ideas, with combination of hash functions, in the implementation of some aspects of our CEP engine, which is based upon SQL and not on a logical programming language.

To put all of these in perspective, let's look at an example. Let's say you want to find out if a certain stock has changed its value more than 20% when compared to a previous value in the past. Consider that a stock is defined as:

Stock: SYMBOL, VALUE, TIMESTAMP

First, let's start with a logic programming language. I will use Prolog in this case:

stockUp(X) :- stock(X, Price1, Time1), stock(X, Price2, Time2),

Time2 > Time1, Price2 > (Price1 * 1.20).

If we feed the following assertions into the Prolog's working memory:

stock(aaa, 10, 0).

stock(bbb, 15, 1).

stock(ccc, 10, 2).

stock(aaa, 12, 3).

stock(bbb, 14, 4).

stock(ccc, 13, 5).

We will get the following result:

stockUp(X = ccc)

Which means that the last stock assertion (i.e. 'stock(ccc,13,5)') generates the creation of the new assertion 'stockUp' for symbol 'ccc'.

Next, let's try with BEA EPL, which mostly follows the SQL idiom:

INSERT INTO StockUp
SELECT a.symbol FROM Stock a, Stock b RETAIN ALL EVENTS
WHERE a.symbol = b.symbol and (a.price > b.price * 1.20)

This EPL statement provides the same result. However, in this case, we will be feeding the engine with Java Bean events rather than assertions. So, instead of creating the assertion:

stock(aaa, 10, 0)

We will create the Java Bean:

new Stock("aaa", 10.0)

It is interesting how events and assertions map seamlessly to each other, at least for this simple scenario. Intuitively, this seems to make sense to me, as both are conceptually immutable and represent some known aspect of the problem domain.

Note how we specify RETAIN ALL EVENTS in the EPL query. Using rule-based systems as an analogy, the RETAIN clause provides a declarative way of managing the CEP engine's working memory. In the case of this example, it is doing exactly the same thing as the Prolog program, that is, keeping all assertions forever, which is probably not a realistic situation.

Consider this next EPL statement:

INSERT INTO StockUp

SELECT symbol FROM Stock

RETAIN 10 EVENTS WITH LARGEST timestamp PARTITION BY symbol

WHERE price > (prev(1,price) * 1.20)

In the first EPL query, we were considering that the stock events were ordered in non-decreasing time within the stream. This is a fair assumption to make considering that we are dealing with streams executing within an underlying stream infrastructure; whereas we couldn't really make this assumption with regards to logical statements, and hence the need of explicitly including the timestamp in the Prolog predicate clause. Nevertheless, for sake of comparison, let's assume that the events are not ordered, which means that the EPL query itself has to take the ordering into account. This is done with the WITH LARGEST timestamp clause. This clause will keep the stock stream in ascending order of timestamp; in my opinion WITH LARGEST timestamp is more declarative than the logical counter-part timestamp2 > timestamp1.

Likewise, note how the second EPL statement does need to join on symbol, which is explicitly done by both the logical statement 'stock(X, Price1, Time1), stock(X, Price2, Time2)' and by the first EPL statement 'a.symbol = b.symbol'. Instead, the clause PARTITION BY symbol will group the stocks by symbol and allow one to compare (in this case using the previous function) within just that group.

Needless to say, this second EPL query provides the same result as of the first one, but in a more declarative manner. The one semantic difference between these two is that the 2nd query only considers 10 events at a time (i.e. RETAIN 10 EVENTS), rather than all events (i.e. RETAIN ALL EVENTS). In another word, we are declaratively restricting the working memory to 10 events in this case.

Ok, so one may argue that rule-based systems are better suited to handle inference, which my simple example fails to demonstrate.

That is a valid point, so let's consider the scenario where stocks are part of a cluster that moves together, that is, if several other stocks within the same cluster go up, it is likely that the remaining ones within the cluster will also go up in the near future.

A simple production rule for this scenario is:

stockUp(aaa) :- stockUp(bbb), stockUp(ccc)

If one creates the following new assertion:

stock(bbb, 25, 6).

One will get the following result, which is expected:

stockUp(X = bbb)

And, in addition, the engine would infer that:

stockUp(X = aaa)

Can we do something similar with EPL? Certainly, here is the query:

INSERT INTO StockUp

SELECT 'aaa' AS symbol

FROM StockUp a, StockUp b RETAIN 10 MINUTES

WHERE a.symbol = 'bbb' AND b.symbol = 'ccc'

Again, it is expressed in terms of SQL joins, which arguably is a less natural form of expressing inference, but nonetheless correct.

Thankfully, EPL also supports a pattern matching idiom, in contrast to just a SQL idiom, which, in my opinion, provides better expressiveness for describing inference:

INSERT INTO StockUp

SELECT 'aaa' AS symbol

MATCHING StockUp(symbol = 'bbb') AND StockUp(symbol = 'ccc')

RETAIN 10 MINUTES

So which language is better? SQL-based languages? Rule-based languages?

In my opinion, the discussion around CEP technology is larger than the discussion around which language to use for its engine, and definitely larger than discussing which matching algorithm, RETE or otherwise, this engine should be built upon.

When discussing the CEP technology, I find it important to focus on use-cases.

Regarding programming languages, there is a place for more than one language in CEP, and, equally, one does not want to be restricted by any one language in particular.

Technorati Tags: CEP, EDA, Rule-Based Systems, Production Systems, Prolog

The EDA Programming Model

2007-07-27T01:01:10Z

In the previous post A Short Dissertation for EDA, I try to describe what is EDA, and why it is important.

Having established that EDA is indeed desirable, the next step is to determine how does one actually author an event-driven application. That is, what are the new abstractions, models, and design patterns that we should be using for EDA.

This is analogous to the problem that enterprises faced before Java EE came about. Before Java EE, developers would have to go long ways to create enterprise applications in Java. EE brought the necessary abstractions to facilitate this, by defining, among other things, the concepts of Session Beans, Entity Beans, Message-Driven Beans, and Enterprise Archives (i.e. EAR), which packaged and assembled these entities together.

So what abstractions do we need for EDA? That is, what would be a good programming model for creating event-driven applications?

To no surprise, the needed abstractions for the EDA programming model are:

Event Sources and Event Sinks: application code that respectively generate events and receive events
Streams: channels through which events flow, these channels don't hold on to events, they actively stream events
Processors: agents capable of processing events; the processing function or capability varies per agent
Event Types: metadata defining the properties of events

Developers author event-driven applications by creating instances of these abstractions.

For example, consider a simple financial market pricing application. The goal of this pricing application is to determine what would be the best price to quote its clients that wish to trade stocks. This event-driven application creates two event sources, each receiving stock tick events from two different exchange markets. For sake of simplicity, the stock tick event contains only two event properties, its stock symbol (e.g. BEAS) and the latest traded price of the stock. The application further defines a processor that is configured to calculate and output the price of a stock symbol as being the average price received from the two event sources. Finally, there is a single event sink that publishes the calculated average stock price to a well-known JMS destination. The event sources are connected to the processor by having the event sources send events to a common stream that the processor listens to. Likewise, the processor is connected to the event sink by sending its event, the average stock price, to a shared stream that the event sink listens to.

The events flow from the two event sources, to the first stream, then to the processor, then to the second stream, and finally to the event sink. This flow of events across the EDA components forms a Event Processing Network (EPN).

An EPN is another abstraction of the EDA programming model. Formally, it is defined as:

A directed graph of event sources, event sinks, streams, and processors; all collaborating towards fulfilling the function of a event-driven application. A EPN models horizontal composition and vertical layering of event processing.

Essentially, an event-driven application specifies a EPN, and the EPN assembles the EDA components (e.g. event sources, event sinks, processors, streams) together.

In the previous example, why do you need a stream to begin with? Couldn't one just link together the event sources to the processor and then to the event sink? Actually, you could, but streams are useful for several reasons:

Streams de-couple event sources from event sinks; this is similar to what a JMS destination does to JMS publishers and subscribers
Streams manage the flow of events; this is done by providing queuing capability, with different rejection policies, and by providing different dispatching mechanisms, such as synchronous and asynchronous dispatching

As long as we are defining a new programming model, let's also consider some other lessons that we have picked up along the way. For instance, it is important that the specification of a EPN be declarative, in another words, we want to assemble the event driven application by using some declarative mechanism, such as XML. Furthermore, it is also equally important that we keep the business logic de-coupled from the technology. Finally, we would like to pay-as-you-go for functionality. This latter means that if you don't need a service, for example persistence or security, then you should not need to configure, reference (e.g. implement some technology interface), or otherwise be impacted by this service that you don't intend on using to begin with.

WebLogic Event Server (EvS) has native support for this EDA programming model.

In EvS, a user application is a EPN, and has first-class support for creating event sources, event sinks, streams, processors, and event types.

Event sources and event sinks may be bound to different plug-able protocols, such as JMS. A event source or event sink that is bound to some specific protocol and is responsible for converting or passing along external events to and from the EPN are known as Adapters. Processors support BEA's Event Processing Language. Java Beans may be registered in the EPN as Event Types. Streams support dynamic configuration of queuing and concurrency parameters.

The EPN itself is specified in a XML configuration file, called the EPN assembly file.

To be able to support the de-coupling of the user code from (infrastructure) dependencies, we have created our own dependency injection container, supporting both setter and constructor injection...

Just kidding! The EPN assembly file is a custom extension of a Spring framework context XML configuration file. What this means is that we leverage Spring's Inversion of Control (IoC) container in its entirely, thus allowing one to seamlessly use Spring beans (and any other Spring feature, such as AOP) in the assembly of a EPN. EvS defines its own custom tags for the EDA components, hence a developer does not need to understand how the Spring framework works to create event-driven applications. The EDA programming model extensions to Spring is called Hot-Spring.

Back to our pricing application example, if you consider that the event sources and event sinks are re-using existing adapter implementations respectively that understand the market exchange protocol and JMS, then the whole EDA application can be authored without the developer having to write a single line of Java code! The developer only has to specify the EPN assembly file and configure the processor and adapters that it is using, all done through XML files or through a command-line interface (CLI) Administration tool.

What if the developer needs to use some custom business logic somewhere in the EPN? Well, the developer can always create Java POJOs (Plain-Old-Java-Objects) functioning in the roles of event sources or event sinks and assembled them together in the EPN. This reflects a common manifest from the Spring community, "simple things are easily done, complicated things are still possible".

Finally, after having authored the EvS application, how do you deploy the application to EvS?

EvS deployment unit is a Spring-OSGi bundle. What is this? To begin with, a bundle is a regular JAR file. The Spring aspect of it means that this JAR file must contain a Spring context configuration, which in the case of EvS is a EPN assembly file, within the directory META-INF/spring. The second aspect of this is OSGi. OSGi is a service-oriented, component-based backplane. Why do you care? Well, generally speaking the developer does not need to care about this. Essentially, a OSGi bundle contains special OSGi entries in its MANIFES.MF file within the JAR file that specify, among other things, service dependencies and service advertisement. The fact that a EvS application is a OSGi bundle helps promote maintainability, re-use, and interoperability. The idea here is that we are bringing SOA directly to the code.

In summary, if you must remember only two things from this article, please remember:

In the same way that Java EE created a new programming model for server-side Java enterprise development, there is a need for a new EDA programming model
The EDA programming model must not only abstract and provide first-class support for the EDA concepts, but it must also promote re-use, openness, and dependency de-coupling

We have tried to achieve these in WebLogic Event Server. Please let us know how we have done.

Technorati Tags: EDA, CEP, WebLogic Event Server, programming model

A Short Dissertation on EDA

2006-11-13T19:46:25Z

Event-driven architecture is an architectural style composed of decoupled applications that interact by exchanging events. These applications are called event-driven applications. Event-driven applications may play the role of an emitter of events, and of a responder or processor of events.

Event-driven architecture is important, because the real-world is event-driven. One example is the financial world, in which trader applications react to events (or changes) made to the financial exchange market. Event-driven situations should be modeled by event-driven architecture.

Event driven applications are sense-and-respond applications, that is, applications that react to and process events.

Events are state changes that are meaningful to an observer. Generally, events are in the form of a protocol message. Events may be simple or complex. Simple events contain no meaningful member events. Complex events contain meaningful member events, which are significant on their own. An example of a simple event is a stock bid event, and a stock offer event; an example of a complex event is a stock trade event, which includes both a bid event and an offer event.

Events may be delivered through different mediums, two of which are channels and streams. Channels are non-active virtual pipes, that is, a producer component is responsible for inserting data into one side of the pipe and another consumer component is responsible for removing the data at the other side of the pipe. The data is stored in the channel as long as it is not removed by a component. Of course, channels may be bound, in which case it may stop accepting new data or purging existing data as it sees fit. Examples of channels are JMS queues and topics. In the contrary, streams are active virtual pipes, that is, they support a continuous flow of data. If a producer component does not directly listen to the stream, it is likely to miss some data. Because streams do not need to store data, streams are able to support a high-volume of streaming data flowing through them. An example of a stream is the of the air TV broadcast.

Having received events, the next task of an event-driven application is to process the events. Event Processing is defined as a computation stage that consumes and optionally generates events. Currently, as specified by Roy Schulte, there are four ways to categorize event processing:

Event passing: Events are simply handled off between components, there is mostly no processing, and it generally deals only with simple events. Event-passing applications are asynchronous, staged, and trigged by the arrival of one event from a single event stream or channel. Sometimes they are referenced as message-driven or document-driven applications. Examples are simple pub-sub applications.

Event mediation (or brokering): Events are filtered, routed (e.g. content-based), and transformed (e.g. enriched). Event mediators are stateless, and deal with both simple and complex events; however they do not synthesize new complex events of their own, that is, event mediators cannot combine (i.e. aggregate) simple events into complex events, mostly due to the fact that they do not keep state. Generally, there is a single event stream or channel fan-in, and multiple event streams or channels fan-out. Examples are integration brokers.

Complex Event Processing (CEP): Events are processed by matching for complex patterns, and for complex relationships, such as causality, timing, correlation and aggregation. CEP applications are state-full; simple and complex events are received from several event streams and new complex events may be synthesized. CEP applications must be able to handle a very high volume of events, and hence generally only using streams.

Non-linear Complex BPM: Event-based business processes modeling non-linear complex work flows. The business process is able to handle unpredictable situations, including complex patterns, and complex event relations.

Event Stream Processing (ESP) is event processing solely on streams, as opposed to channels. Hence, CEP is always part of ESP; however ESP includes other event processing types, such as event passing and event mediation, when those are performed on streams, rather than on channels.

An event-driven application may play the roles of event source, event sink, or both. An event source generates events to event sinks. Note that event sources do not necessarily create the event, nor events sinks are necessarily the consumer of events. Furthermore, event sources and event sinks are completely decoupled from each other:

An event source does not pass control to event sinks, which is the case of service consumers delegating work to providers; and
Event sinks do not provide services to event sources, which is the case of consumers that initiate and consume work from providers; and
One can add and remove event sources and sinks as needed without impacting other event sources and sinks.

How does EDA compare to SOA? That depends on how the loosely term SOA is defined. If SOA is defined as an architecture that promotes re-use of modular, distributed components, then EDA is a type of SOA. If SOA is defined as an architecture where modules provide services to consumer modules, then EDA is not SOA.

The concepts previously described are based upon work from Roy Schulte, Mani Chandy, David Luckham, and others.

Next, let’s focus on real-time concepts.

Real-time is the capability of a system on being able to ensure the timely and predictable execution of code. In another words, if a developer specifies that an object must be executed in the next 100 milliseconds (or in the next 100 minutes for that matter), a real-time infrastructure will guarantee the execution of this object within this temporal constraint.

Event-driven architectures are suitable for real-time. Event-driven applications are generally implemented using asynchronous mechanisms; this lack of synchronicity improves resource usage, which in turn helps guarantee real-time quality of service.

Objects that have temporal constraints are named schedulable objects. The system measures how well the temporal constraints are being met by means of a particular metric, for example, the number of missed deadlines. Schedulers order the execution of schedulable objects attempting to maximize these metrics. Schedulers make use of different algorithms or policies to do this, one of which is the Rate Monotonic Analyze (RMA). RMA relies on thread priority as a scheduling parameter and determines that the highest priority should be associated to the shortest tasks.

Let’s re-consider CEP. CEP allows one to specify temporal constraints in the processing of events. For example, one can specify to match for an event that happens within 100 milliseconds of another event. Hence, CEP rules (e.g. queries) are essentially a type of schedulable object, and therefore a CEP agent must be a real-time agent.

In a very loosely form, CEP can be further characterized by two functions, a guarding function, and an action function. The former determines whether an event should trigger a response, and the latter specifies the responses to be taken if the guard is satisfied.

Consider a system that supports CEP agents whose action functions are coded in Java. This implies that the system must support the development, and deployment of Java applications, and hence, in this regards, it must be to some extent a Java application server, or rather as we have concluded previously, a real-time Java application server.

To be more exact, CEP Java action functions do not need the full services of a complete application server, for instance, part of the transactional, persistence, and security container services may not be needed. What is needed is a minimal-featured application server. This minimalist aspect is also applicable to the real-time capability. We do not need a full set of real-time features that enables the development of any type of applications, but rather a minimal set of real-time features that enables the support of CEP agents.

A system that supports CEP also supports other event processing types, such as event passing and event mediation. Therefore, a light-weight real-time Java application server that is able to host CEP agents is a good overall solution for achieving EDA.

Myths on BPEL

2006-06-12T19:17:15Z

Like any other new technology, BPEL has its share of miscommunications and misconceptions.

Let's consider a few of them:

BPEL is a human interaction workflow language: FALSE

BPEL4People

BPEL is well suited for programming in the small, that is, programming at the module level: FALSE

BPELJ

BPEL provides a standard visual notation for representing business processes: FALSE

BPMN

BPEL provides process choreography, that is, means of specifying a network of communicating processes: FALSE

WS-CDL

BPEL is a declarative language, especially so as it is specified in XML: FALSE

if-then-else

switch-case

while

BPEL allows the modeling of long running processes: TRUE

undo

BPEL allows the modeling of highly concurrent activities: TRUE

Memory management for real-time applications in Java

2006-05-22T18:01:54Z

One of the main advantages of using Java is not to have to worry about disposing objects [1], that is, to let the Java runtime take care of the memory management of Java objects.

This is done by letting the Java runtime garbage collect Java objects that are no longer being used.

Garbage collection is a relatively complicated process. Generally, the Java runtime will traverse the heap, checking for objects that are no longer being referenced by any other objects, and thus can be safely deleted.

However, as garbage collection uses CPU cycles, it may impact the execution of application code. That is, if during the execution of the application code, garbage collection is performed, the application code may take more time to respond. This causes the latency of the user transaction to increase. Even worse, as it is unknown to the user when a garbage collection may occur, the latency increase is unpredictable.

Real-time applications have strict timing requirements, that is, they have to execute application code under some determined, known latency. Thus the unpredictable latency increase that may be caused by the garbage collection becomes a problem.

What are the solutions to this problem? One obvious solution is not to use Java for real-time applications. This is a poor solution. Java brings a lot as a programming language and as a development platform; we should be able to solve this problem in Java.

Another solution is to use a different memory management approach in Java instead of garbage collectors. RTSJ, the Real-Time Specification for Java, defines the concept of immortal memory, and scoped memory. Immortal memory is memory that is never garbage collected; it lives forever until the JVM is brought down. Scoped memory is memory that is allocated and released in chunks. That is, the user explicitly creates a scope of memory where the objects will live and the objects are released when the scope is exited or destroyed. In both cases of immortal memory and scoped memory, there is no need for garbage collection. However, there is a drawback, the onus of managing the memory has again moved back to the user, as it is the case for C/C++ applications. This still seems too high of a price to pay. Can we do better?

Ok, so let's re-consider garbage collection, the main problem with garbage collection is the unpredictable latency spikes it causes. Can we avoid this unpredictable behavior? Or rather, can we limit (i.e. bind) this unpredictable behavior? Yes, by doing garbage collection more often and consistently, we can bind the maximum latency pause time. This is the approach taken by WLRT. Thus, garbage collection becomes a predictable task, with a known cost, which can be considered and modeled by the real-time developer as needed. And, most importantly, we don't sacrifice Java's easy of use.

]]> [1] it should be noted that Java programs can still have memory leaks, in spite of garbage collection or any other memory management technique. For instance, by not removing component objects from containers, when they are no longer needed.

Resolving XML QNames

2005-11-12T01:49:35Z

The XML Namespace specification defines the concept of a qualified name as a name consisting of a local part and namespace URI.

A qualified name, or QName, is specified in terms of a prefix and a local part (e.g. <foo:bar xmlns:foo='urn:foo'>), where the prefix (foo) is resolved to a namespace URI ('urn:foo'). This process of resolving the prefix results in what is commonly known as the expanded name.

The rules for resolving a prefix are mostly uniform in the context of different XML processors, with the exception of how default namespaces (e.g. xmlns='urn:foo') are dealt with.

Specifically:

- XML elements: if the QName does not have a prefix, then the in-scope default namespace must be used.

XML	Resolved namespace for element 'foo'
<foo xmlns='urn:foo'/>	'urn:foo'

- XML attributes: if the QName does not have a prefix, then the namespace URI is NULL, that is, the default namespace is not used.

XML	Resolved namespace for attribute 'a'
a='attr1'/>	NULL
ns1:a='attr1' />	'urn:foo'

- Attribute value of W3C Schema primitive type QName: if the QName does not have a prefix, then the in-scope default namespace must be used.

XML

Resolved namespace of attribute value of attribute 'a'

where

'urn:foo'

- XSLT (1.0) variable or parameter: if the QName does not have a prefix, then the namespace URI is NULL, that is, the default namespace is not used.

XSLT	Resolved namespace for variable
<xsl:variable name='varA' xmlns='urn:foo' />	NULL
<xsl:variable name='ns1:varA' xmlns='urn:foo' xmlns:ns1='urn:bar' />	'urn:bar'

- XPath 1.0 node tests: if the QName does not have a prefix, then the namespace URI is NULL, that is, the default namespace is not used.

XPATH	Resolved namespace for Node Test 'b'
/ns1:a/b	NULL
/ns1:a/ns1:b	'urn:foo'

- XPath 2.0 node (name) tests: if the QName does not have a prefix, then the in-scope default namespace must be used.

XPATH	Resolved namespace for Node Test 'b'
/ns1:a/b	'urn:foo'

Standard Compliance and BPEL TCK

2005-10-25T07:13:53Z

Different standard bodies deal differently in respect to verifying compliance to their published specifications.

Sun's JCP (Java Community Process version 2.1) is very stringent on implementors of its specifications. The specification lead must provide a technology compatibility kit (TCK). The TCK includes tests, tools, and documentation that a implementor must use to verify and prove conformance to the specification. These TCKs usually consist of huge test-beds, containing hundreds of test-cases. The implementor can only promote conformance to a specification after all test-cases have passed with a positive result.

In contrast, OASIS defines a Adoption Service program. Adoption services are a group of services whose aim is to drive adoption of OASIS standards (and OASIS committee drafts) by means of providing conformance, interoperability, or training/personal skill certification programs. Organizations can work together with OASIS to create a referral relationship, which is then used to advertise the certification programs that the organizations provide. Conformance certification programs usually consist of test assertion summary documents, and a testing process.

I did a quick search in the Web and I could not find any single OASIS referred adoption service program for BPEL, version 1.1 or otherwise.
What this means is that currently there is no way of asserting implementation conformance to the OASIS BPEL4WS 1.1 committee draft.
In another words, even if the implementors wanted to guarantee that their implementation is portable and fully compliant, there is no obvious way of doing so.

In spite of this, there are several vendors that do offer BPEL engine implementations. Wikipedia alone lists over 20 providers. How many of these are really full-fledged BPEL engines? Actually, how many of these even provide a minimum level of portability and QoS? It is very hard to tell.

Even worse, currently the onus of ascertaining conformance is on the client. And vendors are not facilitating it. Vendors do not provide a compatibility issue list, or even document the features that they support.

To confirm this, I wrote two scenarios that test significant but hidden BPEL features and executed these scenarios in a couple of commercial and open-source implementations. The BPEL processes for these scenarios are included for reference.

The first one has to do with isolated scopes. When a scope is marked as isolated (variableAccessSerialized), access to its variables must follow a serialization schedule, so that data consistency is preserved. To force the engine into yielding while running within a isolated scope, I used a receive activity and delayed the dispatch of its message.

The second scenario has to do with dead-path-elimination. Paths that will not (ever) be executed, e.g. the unselected case of a switch statement, must be considered as having a negative link status and this negative status must be propagated to all of its target links. Otherwise the flow may just block indefinitely, or until the transaction, if present, times-out.

None of the implementations I tried were able to cope with either of these scenarios. I was not particularly surprised about this. Granted, the BPEL 1.1 specification is not very clear in respect to these particular features, but they are very important nonetheless. So it seems there is a urgent need for a BPEL TCK!

]]>

Isolated scope test-case:

     partnerLinkType="client:plt" myRole="Provider"/>

DPE test-case:

xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:client="http://bea.com/bpeltck/dpe" >

JBI vocabulary

2005-10-10T18:49:41Z

JBI is relatively new as a Java standard, and its deliberation is still going on.
In spite of this, there is at least one aspect of JBI that has already become popular, and that is the vocabulary and patterns that it uses and defines.

Binding Components: Software components that understand specific protocols and are able to convert to a normalized or common system-wide protocol. They function as the entry and exit point of the system. Also commonly known as adapters.
Service Engines: Software components responsible for servicing requests, generally by means of transformation. Examples are XSLT transformers, BPEL engines, rule engines, etc.
Message Exchange: Message interchanging protocol, common exchange patterns are request-reply, in-only, etc.
Component Installation: Static or dynamic addition of a executable software component onto the runtime environment.
Service Deployment: Static or dynamic addition of services (or applications) onto a installed component.
Service Assemblies: A set of services.

Standards are used for achieving interoperability and portability, however we should not overlook their importance on facilitating communication.

What problems does BPEL help to solve?

2005-09-16T20:47:33Z

There has been a lot of talk about BPEL, but mostly it is being focused on its technical features, such as how compensation handling works.

Particularly, I have not seen a lot of emphasis on the use-cases that BPEL helps to solve.

So, as an attempt to understand where one can use BPEL (in the context of integration) and what are the most valuable BPEL features, I've tried to come up with a (incomplete) list of scenarios where BPEL is able to help with:

Intelligent dynamic routing based upon message content and process state;

Compensation of non-transactional work and long-running processes;

Sequential and concurrent splitter and aggregation of messages;

Content enrichment and message filtering;

Support for process instances with complex exception/fault paths;

Support for process instances with multiple on-going conversations;

I would be very interested in knowing if anyone else has had experience implementing integration scenarios using BPEL. What were you trying to solve? What was easy to do and what was hard to do? How was it better (or worse) than using some other technology, such as XSLT?

Web Services Messages for BPEL, JBI, and JAX-RPC

2005-09-07T21:53:06Z

It is interesting how applications differ when modeling WSDL messages.

WS-BPEL 2.0:

For instance, BPEL 2.0 represents a WSDL (1.1) message by conceptually materializing each WSDL message part into a separate Xml document. In this case, the document element corresponds to either a synthesized element whose type is equal to the part's type attribute, or the document element is the element referenced by the part's element attribute itself (in summary).

For example, consider the following WSDL definition:

    
        
            
        
    

    
        
        
    

Note that we are not worried about a particular binding in the context of this scenario. For example, a SOAP literal binding would only allow messages to have one part if it uses the type attribute.

One example of a message instance for this definition is the following set of two document instances:

first value!

and

second value!

JBI:

As for JBI, WSDL (1.1) messages are materialized into a single Xml document whose document element 'wraps' each message part as a child element.

So, for the previous WSDL definition, one example of a message instance is:


    first value!
    
        second value!

JAXRPC 2.0:

JAXRPC approach is slightly different, as JAXRPC binds the WSDL message to Java instead of representing it in a Xml document. Still, it’s approach is somewhat similar to that of BPEL, as it binds each WSDL message part into a separate Java method argument.

In this case, lets consider a slightly modification of the previous WSDL definition, which is more appropriate for RPC:

    
        
            
            
        
    

    
        
        
    

    
        
            
        
    

The corresponding Java binding would be:

void sampleOper(java.lang.String part1, java.lang.String part2)
    throws RemoteException

WSDL 2.0:

Finally, WSDL 2.0 solves this problem by getting rid of the WSDL message part concept and hence specifying WSDL messages using W3C Schema element, which already has a obvious mapping when materialized into a document instance.

Conclusion:

The result of these differences is that one would have to transform/adapt the same WSDL (1.1) message when routing it within a JBI implementation through a BPEL service engine, JAXRPC applications, etc.