SCI-Flex Assists SOA Governance

SOA governance is related to any activity that is used as means of exercising control over an SOA infrastructure. This concept is based on IT governance which is based on corporate governance. A more detailed explanation is available here. SOA governance thus incorporate two main workflows, imposing policies and monitoring activities.

SCI-Flex which integrates Complex Event Processing capabilities to SOA is an ideal fit for workflows related to monitoring activities. Business Activity Monitoring can easily be done using SCI-Flex which also can be configured as an intemediatory in making sure that certain policies are enforced. SCI-Flex also makes it possible to validate the presence of SOA policies given that a proper event generation mechanism is in place.

SCI-Flex however does only provide the infrastructure for Business Activity Monitoring, and thus a suitable protocol is required. This can be one of many options such as WS-Eventing, XMPP pub/sub, or even JMS. Therefore, what SCI-Flex provides is immense:

• Service lifecycle management
• Service performance analysis
• Service coordination monitoring
• Business process monitoring
• Notification services
• Managed policy enforcement

Thus, SCI-Flex becomes an ideal entity that serves the purpose of a complete Event Management System in a typical SOA Governance Application.

Registry Integration of SCI-Flex mediator

The SCI-Flex mediator supports static configuration of XML as well as AXIOM message reception and mediation through Esper CEP system as of today. Obviously, the mediator requires some bits of configuration that it needs in order to make proper use of Esper and the routing of messages through Synapse. Classically, the mediator is backed with a configuration XML object which is embedded in the Synapse configuration (synapse.xml) used by the Synapse ESB. According to how Synapse is implemented, the configuration is statically loaded and the ESB continues to use the same bits of information through out an active lifetime.

By analyzing the nature of the configuration information provided to the Synapse-Esper mediator, we discovered that whilst certain portions of the configuration seems static and used over and over, certain portions need not necessarily be so. Thus, it was obviously needed to have some way that one could dynamically configure the mediator according to his/her requirement.

Synapse facilitates the option of dynamically configuring parameters of the ESB by the use of a remote back-end Registry. The WSO2ESB uses this model of Synapse and provides two models of back-end Registries, the ESB Registry and the WSO2 Registry (using the WSO2 Registry project).

We have made it possible for a user of SCI-Flex to be able to dynamically configure the endpoint to which the responses should be delivered as well as, provide the EPL queries through either of the back-end Registries implemented by the WSO2 ESB.

More information on how to use the SCI-Flex interface to store EPL queries, and endpoints on a back-end Registry will be added shortly.

WSDL and Web Services

As we are in the process of SCI-Flex we always met WSDL(Web Service Descriptive Language) everywhere, Hence I ll do some explanation about WSDL in brief. Since I have already blogged about SOAP, it may be helpful to you as there is an essential interconnectivity between SOAP and WSDL.

WSDL (Web Services Description Language) is an XML-based language for describing Web services and how to access them.As the name implies the WSDL is used to describe the web services, how it is happening is like WSDL is a document written in XML.

The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes.The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.

It is happy to say that The WSDL 2.0 specification was published as a W3C Recommendation on June 26, 2007.

WSDL Document Structure

A WSDL document is simply a set of definitions. There is a definitions element at the root, and definitions inside. The grammar is as follows:

• types, which provides data type definitions used to describe the messages exchanged.

• message, which represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system.

• portType, which is a set of abstract operations. Each operation refers to an input message and output messages.

• binding, which specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType.

• port, which specifies an address for a binding, thus defining a single communication endpoint.

• service, which is used to aggregate a set of related ports.

See an example of WSDL document just to clarify more on what I have told above.

Service Oriented Architecture

Greetings everyone,

As Harsha has already given the introduction to CEP, one major aspect of our venture; allow me to drop a few words on the other aspect : Service Oriented Architecture or SOA. Chances are, if you are reading this blog, you'd be well aware of SOA already, so let me sum up on a few important points only.

SOA 101 >>>

Rather than a totally revolutionary concept, SOA can be described as an evolutionary step (and a pretty important one at that) in the path of achieving better reuse in software components. It is a step above from component based software that is geared towards handling more complex issues rising in the world of software systems such as distributed systems, the internet with its multitude of platforms and protocols. 

SOA therefore, in a nutshell is an architecture compromising of different interacting software services, characterized by their loose coupling. The promise of SOA is that the marginal cost involved in the creation of a certain eventual software application will be zero. This is because all the software needed for the functionality of this particular solution already exist (currently servicing other applications) and to make this work, all that is required will be a certain amount of linking and ordering of different services. 

With this promise of low cost, easy solution deployment which is well suited for handling today's complex systems, its not surprising that SOA has become quite popular of late.

SOA & Web Services >>>

If you're thinking now that SOA is just another fancy name for Web Services, well, you're not the only one. While there are many arguments and debates over the theory of Web Services itself or Web Services and SOA; it is generally accepted that Web Services lie at the core of SOA. 

To make things a bit clearer, a Web Service needs two particular conditions to be met; 

1. All interfaces must be based upon internet protocols (HTTP, SMTP, UDDI)
2. Messages are passed in XML

Now this is interesting when you consider that in SOA it is required that a service to have a certain platform-independence. This requirement can be fulfilled by XML. Also adding onto this is the fact that protocols such as UDDI, HTML and WSDL are what makes SOA what it is basically. Its therefore not too hard to see the connection between SOA and Web Services and that Web Services can in fact be used to implement a SOA.  

A final word >>>

In today's world of increasing software complexity, SOA rocks! Promoting interconnections among existing IT services, SOA enables a building-block approach to creating cost-effective complex solutions with ease.

Any more questions as to why we are so interested in working with SOA? :)

SCI-Flex and Open Source

When planning SCI-Flex, we had to decide on one major factor. That is the development model that we are going to use. We chose Open Source as we believe that it would benefit a larger audience. The SOA and CEP combination being a novel idea is another fact that we believe Open Source will be the best possible way to unleash it's true potential.

The level of research we are expecting to put into this project is immense. However, this doesn't guarantee that the SOA+CEP combination is a true success and does not confirm whether it meets the requirements of a potential user. The Open Source approach gives the SCI-Flex project the ability to be used and utilized in an efficient manner to uncover the true power of CEP systems in the presence of a well organized SOA environment.

Still at the beginning of the project, we have not yet planned about distributions and deployment alternates. Thus, the prime focus remains still in rather What should be done? rather than How should it be done?. As a starting point we've made the source code for SCI-Flex available @ Google Code. You are free to go ahead and give it a try. Further involvement with the project development activities are made possible through the project's mailing lists. Discussions are welcome on the SCI-Flex developer mailing list.

Several Open Source projects such as Apache HTTP Server, Linux Kernel, and Mozilla Firefox have made it the forefront as globally renowned software. We the SCI-Flex project team would like to see someday, our project being a globally renowned software in the SOA+CEP sphere.

Open Source Licensing

Yesterday we had a meeting with Dr. Sanjiva Weerawarana founder/CEO of WSO2 where we were in a position to know lot about open source licensing. We happened to know lot about how a particular license would obtain and how to donate to a particular project having different license like Apache2 and GPL V3 etc. With having GPL license a particular project is like a gift from the inventors to the community which serves for further improvement. If they add new stuff or modify some code they have to give it back the inventor. Those are the main stuff we focused yesterday.

I will explain bit about open source licensing a bit further. An open source license is a copyright license for computer software that makes the source code available under terms that allow for modification and redistribution without having to pay the original author. Such licenses may have additional restrictions such as a requirement to preserve the name of the authors and the copyright statement within the code. One popular (and sometimes considered normative) set of open source software licenses are those approved by the Open Source Initiative (OSI) based on their Open Source Definition (OSD).

Licensing is more critical for developers. The beauty of the open source license is its assignment of copyright (and patents, if held by the author) to the end user and re-distributor without compensation. Thus, for example, the Web professional can leverage an application at no cost, use it in the course of commercial business, and profit by it in interactions with their customers.

Often, in the course of their work, developers discover that the software doesn't quite meet their needs: it lacks a given capability. To resolve the problem, the developers may decide to build new functionality. This is the epitome of the open source license: there are no strings attached! The new, modified solution can be redistributed under the original license (or separate from it, as we will see shortly) depending on the license selection. The result of this exercise is that hundreds of new open source software packages are available at large.

Why we chose Esper

Esper, is an open source CEP implementation, developed by EsperTech. Prior to building an SOA infrastructure that would utilize the true power of CEP systems in an SOA environment, we did a great deal of research into existing products. We identified two streams of possible candidates,

1. Commercial
2. Open Source

When talking about Open Source CEP systems, Esper and Nesper are two popular projects that outrun many others by both capability and portability. The portability of Esper was a major concern since the CEP system itself will be worthless if it can't easily be ported into an SOA environment. Our decision to use the Apache Synapse ESB was another reason to what made us consider Esper the most likely candidate for the CEP system that we are going to use in our project.

Paul Fremantle, who's one of the mentors of this project has done some initial research on connecting Synapse and Esper which was perhaps one of the major reasons behind our choice.

AXIOM support
AXIOM or Axis Object Model is an object oriented mechanism of handling XML which is proven to be much faster than the traditional marshelling of textual data. Esper's support for AXIOM and especially capabilities in processing AXIOM based events is another fact that makes Esper one of the very likely candidates to work in an environment driven by the Apache Axis2 architecture.

Java APIs
Esper's Java APIs have been well tailored making portability very easy and least complicated. This makes it easier for us to use it in our venture of creating an SOA infrastructure which exposes a CEP system.

Popularity
Our decison to go ahead with an Open Source project was another reason to why we chose Esper, since it is perhaps the most popular Open Source CEP system which is available as of today. Popularity introduces many plus points as our target audience will be more familiar with Esper and it's API compared to another Open Source CEP implementation.

SOAP

I just focused to let you all know some key technical aspect of our project.SOAP would play everywhere in our project.CEP usable in SOA.

SOAP (see below for name and origins) is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the web services protocol stack providing a basic messaging framework upon which abstract layers can be built.

SOAP stands for.....

* SOAP stands for Simple Object Access Protocol
* SOAP is a communication protocol
* SOAP is for communication between applications
* SOAP is a format for sending messages
* SOAP is designed to communicate via Internet
* SOAP is platform independent
* SOAP is language independent
* SOAP is based on XML
* SOAP is simple and extensible
* SOAP allows you to get around firewalls
* SOAP will be developed as a W3C standard

There are several different types of messaging patterns in SOAP, but by far the most common is the Remote Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to another node (the server) and the server immediately sends a response message to the client. SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere.

CEP vs. Traditional Databases

Complex Event Processing systems and Databases have many things in common. Both CEP systems and Databases are used to retrieve useful information from a large set of data. CEP systems and Databases use query languages in order to perform various operations on data. Each CEP or Database query defines an operation on a subset of relations within the Database or the CEP system.

However, the two paradigms are quite different in their implementation and usefulness. First of all, a CEP acts upon transient data whereas a Database acts upon persistent data. A CEP system performs operations on a specific time interval whereas a Database performs an operation which does not depend on time. Also, a CEP system operates on a fixed query whereas a Database operates on querys that vary according to the transaction performed.

The CEP system can therefore be thought of as an inversion of concept of Database system. And, the final outcome is rather more or less the same. The benefit of having a CEP system in certain situations is very high when compared to a Database system, and thus the popularity of the CEP concept.

Situations in which a CEP plays a better role compared to databases are occasions in which large volumes of transient data are present and require real-time processing, which most modern Databases can't afford unless otherwise expensive hardware is being used. Others are situations such as deriving useful events from an event cloud, or tagging events as they pass by.

Complex Event Processing

Currently we are involving in a project which is mainly responsible for making CEP usable in SOA. In case of achieving this stuff we first need to clarify what CEP is and what SOA is. Here I am going to emphasize what CEP is and for what it is standing and further how it serve the business world etc.

What is CEP….

Complex event processing (CEP) is a new technology. It can be applied to extracting and analyzing information from any kind of distributed message-based system. It is developed from the Rapid concepts of (1) causal event modeling, (2) event patterns and pattern matching, and (3) event pattern maps and constraints. Complex event processing can be applied to a wide variety of Enterprise monitoring and management problems, from low level network management to high level enterprise intelligence gathering.

Applications of Complex Event Processing:

• Business Activity Monitoring
• Business Process Management
• Enterprise Application Integration
• Event-Driven Architectures
• Network and business level Security
• Real time conformance to regulations and policies.

CEP embodies principles for building applications that enable enterprises to keep pace with the information flowing through their IT systems. The goal of CEP is to enable the information contained in the events flowing through all of the layers of the enterprise IT infrastructure to be discovered, understood in terms of its impact on high level management goals and business processes, and acted upon in real time. This includes the events created by technologies such as RFID. CEP employs techniques such as detection of complex patterns of many events, event streams processing, event correlation and abstraction, event hierarchies, and relationships between events such as causality, membership, and timing. CEP can complement and contribute to technologies such as service oriented architecture (SOA), event driven architecture (EDA) and business process management (BPM).

ESB as an SOA component

An Enterprise Service Bus (or ESB) is a device operating as an enterprise messaging middleware which provides capabilities of providing an array primitive services and thereby interconnecting a number of complex applications that thrive through event driven or service oriented architectures. An ESB is not essentially a component of an SOA but has increasingly become one of the most popular components of an SOA. It is also important to understand that an ESB itself cannot implement an SOA.

In an SOA environment, an ESB sits in the right middle or at the very edge of a cloud of messages having vested with the capabilities of managing and routing them to their relevant destinations. The capabilities of an ESB puts it in the place of a simple multi-point connector which is capable of serving many types of requirements that may arise in an SOA world of communication with the help of several interconnected resources.

Another major advantage of an ESB is the no-code approach it uses. Most modern ESB developers introduce a concept of plug & play adaptors to which you simply can connect one or more distinct resources capable of servicing incoming requirements. Thus, an ESB makes an SOA easy to implement.

Analogous to a bus found inside a computing system, an ESB serves as a medium through which resources are exposed. Thus, in an SOA environment, the most traditional use of an ESB will be to provide a front-end to a specific resource which then can be accessed via multiple mechanisms over a number of different transports.

In a modern SOA environment the most important aspects of an ESB are it's

1. Speed
2. Ease of use
3. Features
4. Maintenance & Support

Multiple Mediator Example

SCI-Flex provides an extension that connects the Open Source CEP System, Esper with the Apache Synapse ESB. Due to various possible formats of messages being exchanged between the two components, SCI-Flex extensions for Synapse-Esper mediation comes in several flavors. As of now, we have two mediators, namely the XMLMediator, which operates on XML DOM information, and the AxiomMediator, which operates on Axiom based Tree representations of XML.

Necessarily, XML and Axiom are two different ways one could look into the same problem, but, depending on the scenario, one is always better than the other. There can also be situations where the ESB and CEP communicate with information flowing from various sources. This leads to situation which would perhaps reqire both the mediators in action rather than one.

Each SCI-Flex mediator communicates with a specific instance of Esper CEP system, and adding two mediators would necessarily add two instances of Esper unless otherwise explicitly stated. This can be challenging as there can be queries that span across data handled by both the mediators. The solution is simple. It requires us to share a single instance of the CEP engine.

How it is done is what is important. Each instance of the CEP engine needs to be configured before it being used. According to how the mediator is being implemented, each mediator has the capability of configuring the CEP engine. Thus, it is important to decide on who configures the CEP engine. We have used a standard way of configuring the CEP engine in the first mediator lying in the mediation path.

Once configured, a unique instance URI can be used to access the shared CEP instance. A more detailed example that uses two event sources, a web service and a timer, is found in here.

Role of a CEP System in Cloud Computing

Cloud Computing is a concept in where various services are made available through a cloud ( a network of resources which is a part of the internet), to users, without any knowledge, control, or privileged access to the underlying infrastructure that provides services. The services are necessarily IT related business applications that are more or less extensions to the traditional computing systems.

Clouds that provide services are backed by huge infrastructures of resources and handle large number of clients or users to which it provides services. The number of clients serviced by a particular cloud at any given instance can be in the magnitude of millions to billions depending on the type of service provided. This gives rise to the importance of a proper event management system in order to track usage and assist workflows.

Complex Event Processing Systems are vested with the capability of handling large streams of events and identifying useful patterns and trigger events based on them. Thus, it is clearly evident that a CEP system is perhaps the ultimate event manager or synchronizer demanded by a cloud. But, the biggest question is how to integrate a CEP system to the cloud with minimal effort.

SCI-Flex is a good example of how one could leverage the capabilities of a CEP system in event management in cloud computing. The infrastructure provided by SCI-Flex easily blends to the infrastructure of a cloud that provides services. The system can in fact be positioned as a central hub or a cluster of nodes and still have the same experience due to the way in which it being implemented.

We are hoping to add more information on integrating SCI-Flex to your cloud. Join the SCI-Flex developer list to learn more.

Internet Relay Chat Discussion Channel

SCI-Flex being an Open Source project from its inception works primarily around a developer mailing list. However, in order to speed up the development activities and to have real time chat between developers, we decided that it would be better to have a public discussion channel on our behalf. Do to the immense popularity and guaranteed stability and 24/7 service found in the freenode IRC network we decided that it would be great to host the SCI-Flex discussion channel on freenode.

Since SCI-Flex is an Open Source project and since we need to reveal all forms of communication and important project related discussions to all the members of the community, it would invariably be good to have the channel publicly logged and also available to anyone interested in seeing it. Due to limitations we experience, so far there isn't a public chat log in place. We are at present working on this feature and expect to have this in place by the end of August 2008.

We invite all those who are interested in SCI-Flex to join ##sci-flex @ chat.freenode.net. More information on freenode can be found here. You can learn about IRC in here. Pidgin and Mibbit (web based) are some of the IRC clients I use.

SCI-Flex introduced in webinar By Paul

SCI-Flex was featured on "Complex Event Processing with Esper and WSO2 ESB" - Webinar by Paul Fremantle which was held on 29th July 2008. Paul Fremantle, Co-Founder and CTO of WSO2, spoke about Complex Event processing capabilities of the WSO2 ESB, in the fourth and final part of the webinar series on the WSO2 ESB. WSO2 ESB is a enterprise grade lightweight ESB based on the popular Apache Synapse ESB, and is presently at version 1.7.

Paul discussed about how the WSO2 ESB can easily be configured to listen and monitor various events flowing through the WSO2 ESB using the Esper open source complex event processing system, and identify patterns and useful events. As a mechanism of integrating Esper into the WSO2 ESB, Paul introduced SCI-Flex which is project focused on maximizing the use of Complex Event Processing in the field of Service Oriented Architecture through a flexible integration.

The SCI-Flex team is now working on further improving the Synapse-Esper mediator which serves as the primary medium for connecting Synapse and Esper which can infact be used with the WSO2 ESB as well. We are very much thankful to Paul for mentioning about SCI-Flex in his discussion. More information on the webinar and subject matter can be found here.

SCI-Flex Milestone 1 Plan

The SCI-Flex team is at present working on the 1st milestone of SCI-Flex due in early September 2008. The development of SCI-Flex was broken down in to several parts so that basic functionality will be made available from early stages of development. It was decided that we would primarily focus on the development of the Synapse-Esper mediator at the beginning and focus on other aspects afterwards.

The requirements for the 1st Milestone as agreed by our team can be expressed as,

1. Make it possible for Synapse to talk to Esper. All messages that go through Synapse will be routed to Esper during this stage of our research. By achieving this, we need not worry about what messages would go to the CEP and what wouldn't.
2. Attach registry support to our SOA+CEP infrastructure. We will be making it possible for someone to store a CEP query, EQL/EPL in a back-end registry, which will then be fetched by Synapse by default and then applied upon the event stream that will be flushed through the CEP. We will not worry about how we will be fetching various queries, or fetching a particular query on demand for this milestone.
3. Make it possible for someone to specify a Endpoint Reference (EPR) along with the query, so that Synapse will redirect the response obtained through the CEP to the specified EPR. The EPR will also be made available through the registry.

The development activities related to Milestone 1, is carried on the SCI-Flex M1 branch. We'll be merging it to the trunk once we've finished work, most probably in early September.

CEP Enhances SOA's Eventing Capabilities

Eventing in a SOA environment is crucial for enterprise applications. According to the WS-Eventing specification, web services are capable of monitoring and notifying status and also performing a defined operation when a certain event is triggered. However, like any other specification that explains web based extensions to event driven architectures, this lacks the true power of making decisions on events based on a stream of events itself.

The combination of CEP and SOA unleashes the true potential of a complete event driven architecture implemented over a web based or any similar network communication protocol based architecture that is supported by existing SOA networks. Thus, one could describe CEP over SOA as a universal replacement to existing Publisher-Subscriber systems such as,

1. JMS Topics
2. XMPP
3. WS-Eventing
4. Atom Pub/Sub

Decisions made through CEP systems involve identifying meaningful events from a number of events, extracting the product of a reaction between several events, understanding event patterns etc. The possibilities in handling bulky event sources are immense. Thus, the positive addition to an SOA environment through a CEP system is limitless.

It is clearly understood that CEP enhances SOA's eventing capabilities. In addition to these marginal gains, a complete CEP installation over an SOA network makes you more productive. We are looking forward to introduce such other benefits.

Unified Support for Events

This time I would like to mention a few words about another phase of our project - Unified support for events on the Synapse ESB.

This will probably be one of a few postings which will describe this matter. This particular posting simply is intended to lay down some initial background to this concept and introduce a few key terms. It will not be describing the process of unified support, but rather the different types of requests handled by Synapse which results in event formulation.

Some of the different types supported are;

• XMPP Pub/sub
• Atom Feeds
• JMS Topics
• WS-Eventing

Looking at these in a bit more detail;

• XMPP -
  If you usually do a considerable amount of chatting over the internet, chances are you have used this technology at least once... it is the backbone of some popular systems such as Google Talk. XMPP is essentially an XML-based protocol which enables real-time and extensible Instant Messaging feature core (e.g. it is the base of Jabber IM as well as Presence Technology.

• Atom -
  The Atom format was developed as an alternative to RSS. It is a data format used for providing users with frequently updated content.
  
  
• JMS Topics -
  API is a Java Message Oriented Middleware API for sending messages between two or more clients.
  
  
• WS-Eventing -
  a protocol that allows Web services to subscribe to or accept subscriptions for event notification messages.
  

Our goal therefore in brief is giving Synapse the ability to interpret as well as handle these different types of events in unified manner. More on this soon...:-)

Message Mediation

Moving a bit interior....................

This is one of a keys to drive our project to it's successiveness and effectiveness.Hence have the underlying concept of message mediation as a prerequisite to SCI-Flex.

Message mediation is one of the new capabilities of some components like synapse. Mediation is a programmable extension to the messaging capabilities of services that can simplify connecting systems, other services, applications, or components that use messaging. Mediation is used to process in-flight (I just mean the messages on the fly) messages. The types of processing mediation can perform include:

• Modifying or transforming a message.


• Routing messages (or cloned messages) to other or additional destinations.


• Allowing or disallowing a message to be delivered based on some conditional logic in the mediation.
  
  Why use mediations?
  

There are a number of considerations when deciding if mediations are the right solution for your task. It is already possible to write a message-driven bean (MDB) to transform messages between different formats, so why choose mediation?

The most obvious reason for using mediations is that they preserve message identities. If your MDB resends the message after you had manipulated its body, you are actually sending a new message. As a result, the message ID of the new message would be different than that of the original message. This would cause problems if you tried to correlate sent and received messages. Other message properties, such as the expiry or message timestamp will be reset or overwritten when the new message is sent.

Another reason for choosing a mediation over a message-driven bean is that mediations are not tied to a specific messaging technology

However, the mediation programming model provides a Service Data Object (SDO) interface to all messages and a common API for accessing properties and metadata.

Below I have attached a figure for further understanding of how mediation would take place. Here the mediation handler is invoked and passed message context when a incoming message needs mediation

In summary, mediation should be used when you need to transparently modify or route messages. And since the same mediation can operate on Web services or JMS messages, there are more opportunities for reuse.

Why SOA and CEP

The reason to why we chose SOA and CEP integration grew based on a discussion on writing a CEP system using an Apache license. When thinking of what could be done with the new CEP project, we saw the possibility of extending existing SOA frameworks to be capable of making the most of this new CEP system.

After having a fair amount of reading over the internet, we discovered that it was not only us who were interested in the fact but many other individuals, research teams, companies etc who have paid a reasonable amount of attention on this topic that has gradually gained popularity in early 2008. This gave us enough motivation to discover the potential of converting a simple thought into a project that would benefit many.

Our aim is to make it possible for someone who wishes to make use of a CEP system in a distributed SOA environment, without having to worry much about low-level configuring and interfacing. Unlike many developers who are involved with SOA frameworks, most users are accustomed to simply make use of a pre-built framework and integrate some code of business logic which will route information to/from an SOA network. Thus, a typical SOA user will not be looking forward to extend a framework to support a CEP system, but rather look for another that already has that feature.

Based on this requirement, we are targeting to make life easy for a user who is looking forward to make good use of a CEP system, Esper, in a SOA environment hosted through the popular Apache Synapse Enterprise Service Bus.

Introducing SCI-Flex

Welcome all.

The project SCI-Flex is an attempt to combine the power of a Complex Event Processing system with a Service Oriented Architecture of another. Our attempt is focused mainly in making the CEP experience truly parallel and distributed.

We have already started with some initial research into combining Apache Synapse and Espertech Esper, and the project is located in Google Code at [1]. We also do have a mailing list which is focused towards pre-development discussions. Feel free to join the effort at [2].

As of present the development team includes,

1. Paul Fremantle
2. Harsha Halgaswatte
3. Senaka Fernando
4. Madhumal Gunetileke

The project is as of present just started, and we are hoping to achieve completion in January 2008.

Instructions for downloading source code is found at [1], however, the location should read as, http://sci-flex.googlecode.com/svn/ instead of http://sci-flex.googlecode.com/svn/trunk.

[1] http://code.google.com/p/sci-flex
[2] sci-flex-dev AT googlegroups DOT com

Regards,
Senaka