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.

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.

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.

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

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.

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.