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.