SOA-Reference Model

Read SOA-RM from OASIS

If you are the one who likes to understand the very basics and the core concepts associated with the Service Oriented Architecture you will find the above document one real treat to read, rest assured you can go with absolute clean slate, you actually learn a lot.

Web Services Platforms: Composition and Philosophy

Not surprisingly, contrary to common knowledge SOAP today stands for nothing... some one must be seariously embarassed to refer to it as 'Simple' :) There are so many specifications heard some one saying here are 105 of them!! That very moment I found it over zealous to study and all of them and considering my feeble mindedness, I'm sure to get lost in them. But then, what next?!! I just can't give up like that, after all I have a stiff nose to save ;) They say 'you are what you abstract it from' and may be that's right... may be I need to understand the 'big picture' and then drill down to details subject to interest and need. Here, today a first attempt is made to understand web service as a platform architecture and defining philosophies of some of its more popular implementations.

Web Services Platform Architecture

Web service technology provides a uniform usage model for components/services, especially within the context of heterogeneous distributed environments. It also virtualizes resources by shielding idiosyncrasies of the different environments that host those components. This shielding can occur by dynamically selecting and binding those components and by hiding the communication details to properly access those components. Put simply, these web services technologies serves as a toolset which can primarily be divided into three core subsystems:

1. Invocation: Upon receiving a service invocation request over a supported transport protocol (HTTP[S], JMS, SNMP etc) a set of handlers need to to pre-process the message as per the QoS (quality of service) requirement (like reliability, security etc.) and then the target Java class (call it first language interference, I'm told something similar happens in other languages too...) is idenified. But before delegating the message for processing it needs to be de-serialized to Java objects and later the response is serialized back to XML documents, which are further handed over to transport layer for onward message delivery. Roughly the same happens on client side albeit in the reverse order.
2. Serialization: is the process of transforming a Java object into XML element and the reverse process is called De-Serialization. Arguably, this is the most important step as it determines performance and flexibility of the web services platform, among other things. To accomplish this the serialization engine needs a set of 'mapping strategies' to serialize an instance of Java class into instances of XML Schema components. A 'mapping strategy' associates a Java class its target XML Schema type and a description of serializer that will transform an instance of Java into an instance of the Schema type (or vice versa). It should be noted that, Objects are serialized through a 'serialization context' and that the serialized form of object may differ based upon the "context", i.e. what object have been serialized before. Thus a 'Serialization Context' is set of 'Mapping Strategies' that can be used by serialization subsystem to implement the type mapping used by a particular Web Service deployment. Common type mapping mechanism are Standard Binding, Annotations, Algorithmic and Rule Based (need to explore further...)
3. Deployment: This subsystem supports invocation of a Java target as a Web Service, which includes publishing he WSDL, configuring the end-point listeners and SOAP handlers, mapping WSDL operation to Java method calls and defining the Serialization Context for binding the WSDl operations to Java targets.

Having understood the central concepts associated with a Web Service Platform, it should now give us some basic parameters using which we can compare and contrast different web services implementations. Primary, among them are;

• JAX-WS 2.0: Assumes a uniformly available Java Universe and thus makes all efforts to make it increasingly simple for a Java Developer to rexpose their applications as web services with annotations and tool support to generate real robust WSDL. Java Interfaces forms the starting point.
• Apache Axis2: Backed by strong community support this implementation makes it easy to start from either a WSDL or a Java interface and Axis2 with new object model in place boasts of improved performance and flexibility.
• Apache CXF: Boasts of ease of use and very high performance because of using the new 'pull' parsing technique and the object model.

Hopefully, this article helps us understand the composition of different WS implementations and make an informed decision in their selection for our projects at hand.

BPMN in a nutshell

Business Process Modeling Notation (BPMN) is a standard specification created by Business Process Management Initiative Organization (BPMI) intended to provide a notation that is readily understood by Business Analyst (who creates the business process), Process Developer (who implements the business process into executables) and Business Owner (who manages and monitors he process). Thus, BPMN standardizes the bridge for the gap between process design and process implementation.

BPMN defines a Business Process Diagram (BPD), which is a specialized flow-charting technique to create graphical model for business process operations. The graphical model so generated is a network of directed graphical objects representing activities.

BPMN can be classified in to following four categories;
1. Flow Objects
a] Event - Events effect the flow of the process and usually have a cause(trigger) or an impact (result). Types {start, intermediate event, end}
b] Activity - The work done and can be further classified as Task(atomic), sub-processes(non-atomic or compund)
c] Gateway - They are used to model the convergence or divergence of sequence flow and can thus be used to model decision making, fork or joins.

2. Connection Objects: Using them, Flow Objects are connected together to provide basic skeleton structure of business process.
a] Sequence flow - models the 'order' of activity to be performed, it should be noted that 'control flow' is semantically incorrect in the context of business modelling language.
b] Message flow - models the flow of information.
c] Association - models the inputs and outputs of acivities.

3. Swimlanes: The concept of swimlanes is used to organize acivities into seperate visual categories to illustrate different functional capabilities or responsibiliies.
a] Pool: Intra-group activity for e.g. interactions between customer and supplier organizations can be clubbed using Pools.
b] Lanes: Inter-group activity for e.g. interactions between various department of the same organization can be modeled using lanes.

4. Artifacts:
a] Data Objects: Models the input or output form activities such as Rules, Documents for e.g. order
b] Groups: Models the logical grouping of sequence of activities, does not alters the sequence flow.
c] Annotation: Provides documentation.

BPMN can be used to model collaborations between two or more business entities which may be public in nature or business processes internal to an organization, the difference lies in the precision level between the two. The primary value add that BPMN brings to the table are;
1- Standards based.
2- Easily understood by the complete 'spectrum' of people
3- Designed to be easily transformed to the de-facto execution language standard BPEL4WS.

Make your ERP applications SOA compliant

With all the big drum beat about Service Oriented Architecture there are different degree to which people appreciate the value that SOA bring to the business. It might quite well be discarded a new found 'fad' or as the new found 'silver bullet' by the over enthusiastic and that has panacea to almost every type of business problem. Also, often people confuse it with a technology rather than an enterprise architecture design style or merely a label associated with a bulk of technologies. Much in the same way the ERP systems were described a few years back.

The problem with such description is that it makes it difficult for the business users who has stakes in his IT infrastructure difficult to objectively understand the basic need for change and/or understand the short comings with its own application which might be plugged the SOA way. Hence, much of important decisions are taken based on the political affiliation of participating organizations.

In not too distant past, ERP helped the industries control the chaos by establishing industry best practices. They provided those functionalities out-of-the-box. However, they attempted to solve the problems in an 'All-or-Nothing' manner. That is, even though they brought tremendous value to business through standardization of processes but they also required complete over-haul of the organization leading to unrest(to people) as it required a dramatic shift in the organization culture. Also, in case an organization does recognizes a 'particular-process' which differentiates it from the rest of the world and 'want-it-their-way' implementing that would amount to uncontrolled complexities creeping into the system thereby making them costly to maintain and upgrade with time.

SOA allows an organization to mature its IT infrastructure and application to increasing levels at their own pace while keeping them in control of the cost and complexity. It allows organizations to have 'their' processes implemented 'their' way and also allows them the agility to change them as deemed necessary. Again, the idea to drive home is that the SOA based applications are designed to absorb change (which is in turn is constrained by our abstraction of the system). Further, with the advent of new delivery models like SaaS in a multi-tenant scenario you may only pay for the portion of services which you consume which may be very well be monitored by utilities based upon Autonomic computing techniques thus giving you greater visibility and efficiency to your enterprise system.

The crux of the matter is pick the right solution for the right application and when it matters model it the SOA way and stand out from the crowd!