SCI-Flex goes live !!!

Greetings everyone...
After reaching successful completion, Project SCI-Flex is going through its last days as a Final Year Project of the University. Today (28th January), the SCI-Flex team successfully completed the final project Presentations to the panel of University Staff from the Dept. of Computer Science & Engineering.

The final presentation is embedded below..

The team will be running through the final demonstrations tomorrow! This then, may be the end of the final year project for the team, but we have no doubt that this will NOT be the end for SCI-Flex. It is a project standing upon successful completion, and we look towards integration of SCI-Flex into real world applications presently.

Project SCI-Flex

View more presentations or upload your own. (tags: soa cep)

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? :)