Next generation SOA solution Elements

In this article i like to highlight the most commonly used software elements i have come across my experience.

1. Application servers:
Application servers are the most essential piece of software that is responsible for providing a scalable, reliable, per formant, deploy able and manageable platform for running application which provide the core business services. The application servers are the key engines behind the services that are made available. It is a better practice to host the services along with the application and hence it becomes wise to have all the application hosted on the application server. The application server in turn has the responsibility to be standards oriented and adopt a open architecture approach with a broader enterprise dimension. I can provide more information on the Application adaptability parameters.

2. Business Process Management (BPM):
As we already understand BPM is evolved into a serious enables of SOA from a business perspective. The SOA platform of choice must have a strong and reliable BPM engine which supports the orchestration abilities between the inter and intranet organization services. The BPM engine must enable certain key features not limiting to Business Rules, Process Optimization, Process monitoring etc. The modern BPM is also required to enable human interactions by providing interfaces including services, API, portals and adapters. The next gen of BPM's are also required to have the ability to integrate with the BI systems and must have the ability to dynamically reach to situations in predictable manner. Interested in Building a BPM with ability to be dynamically adaptable.

3. Enterprise Service Bus (ESB):
The need for contract management and policy enforcement between partners is a key in a successful SOA implementation. This brings in the most needed loose coupling into the architecture. ESB is the component which is highly recommended for this aspect. ESB is generally the first recipient of the message and using an ESB the policies are applied to the received messages and any breach of policies will be checked at the entry. ESB will also enrich the outgoing message to be complaint with the response policies.

4. Run-time Governance Layer:
This is the most important piece of the SOA architecture with the increasing complexity in the SOA implementations. The Run-time governance layer must be the layer above all the other pieces of the SOA infrastructure. The Governance layer will primarily ensure the service vision is being realized. This is achieved with a reactive layer over the aspects that get monitored. The violation in any Service Level agreement must be responded both at a tactical level and a strategic level. The next genration of the Governance layer can bring in the ability to dynamically assign resources on the task and can notify the respective stake holders of the situation. Working on the specifications of the Governance tool on resource allocation.

5. Business Activity Monitoring:
BAM is the one of the key for the SOA governance at a strategic level. BAM will allow the appropriate sensors for the Services or the BP's. The BAM will capture the inetersting dat and will render the captured data in a manner which will indicate the KPI adherence. The Next generation of the BAM's will provide a analysis layer which not just captures and renders but also will help the decision makers by contextualizing and recommending options.

6. Portal / Presentation layer:
The presentation Layer is the key for the SOA architecture. This becomes an important aspect because of the very nature of SOA that is distribution of the information and the processes/logic. The presentation layer in the SOA must have the adaptability to build interfaces on the fly and must provide the humans to intervene into the process under certain situations. the portal and presentation layer must enable the back office to deal with the situations which occur with multiple factors including unforeseen situations. The SOA must respect the ability and freedom that was existing before IT and must provide the similar flexibility to the decision makers to participate in the organization business behavior.

7. SOA Registry:
SOA Registry is the key component in the SOA architecture which provides a window for the Services to be registered and inturn looked up by the consumers to use. SOA service registry provides the service enabler governance, i term it (provision governance) because it neither Design, Nor Development, Nor Deployment and Nor Runtime . The registry will provide the organization established meta-data placeholder for the service to be registered. In the process of registering the Registry can evaluate if the service adheres to the KPI for the service which is being provisioned to be consumed.

8. SOA repository:
SOA repository is an essential element of the SOA solution. It is a best practice to publish all the supporting artifacts like policies, rules, Schema s, Transformation schema s etc., Please follow http://sw-architect.blogspot.com/2009/10/need-for-soa-repository.html.

9. SOA development environment: SOA platform must have a complimentary development environment which enable to develop on all the above said tools.

Need for SOA Repository

Need For SOA Repository:
Governance is the contextual area in which the repository is used. The repository with registry provides a complete and comprehensive solution towards SOA governance.

What does repository do:
SOA repository is the Services asset repository which stores the assets in a central manner avoiding the need for the scattered locations to save the Service assets which includes
a. WSDL
b. XSD
c. Message Structures.
d. SLA policies.
e. Partner Agreements
f. Business rules
g. XSLT

Benefits of SOA repository:
SOA/Oracle repository provides the base framework for governance throughout the SOA service lifecycle by being the central store. Oracle repository has mature integration mechanism to collaborate with other SOA tools. SOA repository controls the mechanism and process to publish the artifacts. The publishing is governed by the predefined rules defined in the repository which ensures the policy adherence before publishing the documents which can be looked up by the interested parties.

The features of the SOA repository include

a. Controlled access to assets based on the authorization policy
b. Easy access to the related artifacts of the Service.
c. Asset publish and acceptance process to ensure only quality artifacts are published.
d. Integrate with Service registry which will provide the interface for repository navigation.
e. Policy can be defined and adhered. Generally comes with the predefined set of best practices.

SOA Reference Architecture

Presentation Layer

The applications in this layer provide the user interface. The user interface applications in this document are broadly categorized based on the type of the use case.

This layer will provide a composite view by integration the application built on J2EE technologies, BAM dashboards and Documentum based applications.

a.     J2EE applications shall be implemented based on the spring development and design guidelines. These application will interact with database using hibernate. In exceptional cases the data services can be implemented using jdbc. Documentum provided UCF may be used for Content Transfer for faster file transfer.

b.    BAM Dashboards: BAM dashboards can be provided by various sources not limiting AL BPM, AL SB. Some of these dashboards may have to be displayed to the users on the web applications. In these scenarios the screens are required to be displayed as inline application without having to open a new site by entering URL.

c.     Admin Applications: Admin application shall be a J2EE application but this application must provide the admin with the reports required and to configure the applications wherever possible. This should also link to other out of the box admin application provided by Documentum.

d.    Autoviewer: Autoviewer will be at the presentation layer which will provide access to the documents and provides the ability to annotate on the documents. The Autoviewer shall be a pop up window which will open the document in just read or read / write mode.

e.     Email client plug-in for documentum: EMC Documentum Client for Outlook and lotus notes will be a plug-in installed on the email client to store email contents on Documentum Repository. This is out of the box product installation.


Business Logic Applications

Workflow Applications

Workflow applications are AL-BPM studio developed workflow applications that will manage the flow of the process within the AL-BPM server without having the need to access the external services. These workflow applications will implement all the business rules and the routing decisions for the flow between users and roles.
BPEL Processes

BPEL processes implement the business processes where there is an integration with external services. This layer has the applications that are implemented following the standards of BPEL.
Business Services

Business services are the custom business components which are reused across process. These can be regular java objects (pojo) or these components can be exposed using the JEE Spring WS framework. The webservices that will be exposed in this layer will be consumed from external systems.
Technical Services

Technical services are the custom technical service components which are reused across processes or activities. These can be regular java objects (pojo) or these components can be exposed using the JEE Spring WS framework. This also includes out of the box services for rendering and archival from Documentum. The webservices that will be exposed in this layer will be consumed from external systems.

Data Access Services

Data Access services are the custom developed data access mechanisms on top of the data access components that are provided such as the hibernate framework, JDBC, DFS, DFC or any other document specific access components. The out of the product’s or Jar’s will be deployed as the shared library.

Data Stores

Integration Services

Enterprise service Bus

Enterprise service bus will provide the access across layers and across boundaries. The business logic layer will be exposed wherever possible as proxy services on the ESB. The Proxy services must be accessed using the piplines with mediations. The pipelines are configured for specific SLA’s governing the process or service.

Service Registry

Service Registry allows the interface for publishing and discovering the services. The Service published will go through a review cycle and made available / accessible after being approved by the reviewer. The interface to review the service must be provided on the Admin web application.
Security Service

TBD.
Shared Services

TBD

NFR attributes to be identified for the system from integration perspective

	Attribute	Description	Required
1	Message Transformation	Message Transformation is the ability to transform the message into different forms and support for XML-java serialization.
2	Multi Channel/protocol Support	The system can use multiple transport channels to communicate between different systems. Ex: Http/Https/JMS/FTP/SMTP etc
3	Attachment Handling	Support for attachments across soap calls.
4	Multi channel/protocol support	The system can use multiple transport channels to communicate between different systems. Ex: Http/Https/JMS/FTP/SMTP etc
5	Attachment Handling	Support for attachments across soap calls.
6	Reliability	The reliable delivery of messages ensures the delivery of messages by supporting multiple retries both is synch and asynch mode and correlating messages once response is received.
7	Once and Only Once delivery	This ensures that the message is not redelivered again based on the uniqueness attributes of the message
8	Security	The need for WS-Security and support for XML signatures and XML-encryption
9	Auditing	The synchronous auditing if required within the scope of the transaction
10	Routing	The ability of the integration layer to route the message to the appropriate endpoint based on the rules or availability.
11	Transactions support	Transaction co-ordination that needs to be propagated and coordinated between multiple systems.
12	Mediations	Mediations to be supported if there any business/interaction specific pre or post processing required. Such as adding application specific headers which will be used for integration.
13	Versioning	Versioning will be used when there are multiple versions of the same service may be to address certain regulatory change in progress.
14	Sequencing	Sequencing will be used when we are to split a batch message and send the split message along with sequence so the aggregator to aggregate the batch based on the sequence.
15	Splitting	Splitting will be required if the batch sizes or message size is going beyond the message limits defined.
16	Business Rules	Business rules will be applied at the integration layer for reasons such as message validation.
17	Asynchronous Invocation	Asynchronous invocations would be required when we have batch uploads and nightly jobs.
18	Event Handling	Event handling can be used for event based processing. Event handling can be used to handle specific events such as permanent failure of delivery and to notify back office of the same.
19	Content Based Logic	Content based logic can used to validate and execute the business process based on the value contents of the message.
20	Store and Forward	Store and Forward can be a mechanism for non-repudiation or for reliability at the process level.
21	Intermediaries	Intermediaries will be used when there are interactions that will require the pre-post processing of the request or response by the other service. The intermediaries can be systems such as payment gateways and so on.
22	Policy management	Policies that define the interaction patterns between systems and services. The policy management provides repositories and interfaces to save and retrieve the policies.
23	Logging	Logging will be required in the on the integration points to monitor the behavior of the invocation process.
24	Metering	Metering will provide mechanisms to meter the invocations, response times and other behaviors of the invocation.
25	Monitoring	Monitoring provides a mechanism to monitor the invocations and the component behavior at the runtime.
26	Correlations	Correlations will be used to manage the relationships between 2 messages with different contexts but that would belong to the process.

Spring Web Services Step by Step Guide

Web Service Design Principles
The focus of the proposed methodology is on design of service interfaces based on the design principles derived from the Design experience and the lessons learnt from the earlier implementations. Following is the brief description of each of the design principle that is considered, debated and accepted.
Completeness: Application Domain Functionality should be fully covered by the specific set of services. Cross functional services necessitates additional development and maintenance efforts.
Granularity: Services should be designed and developed for common functions that encourage opportunity to reuse. Additional services are implemented using the composition of core services and operations.
Coupling: The services implementations must be loosly coupled. This must be achieved by adopting the code to interface technique.
Clarity, Uniformity and Elegance: Services should have well defined semantics and should be easily understood to improve usability. Web Service interface should explicitly describe operations that the service performs, including the semantics of the parameters. Clarity can be improved using a suitable naming convention, and by including additional documentation that describes the semantics of each service and its operations. Uniformity of naming services, operations and parameters can significantly improve usability of interfaces and at the same time minimize ambiguity.
Design Methodology
Overview
The Service design methodology comes from the principle of Contract First approach. With Contract First approach the Service contracts are defined by covering the following aspects.
Interface Information Security Information Service Level Information Service Access Point
Service Description
Semantic Model
Data Types
Operations Security Mechanisms
Access Criteria and Restrictions
Information Security Marking Service Level Specifications
Network Requirements Service Access Point

Web Service Design Methodology
The Services Design methodology comprises of following steps.
A. Requirements Gathering
B. Domain Definition
C. Interface Definition
D. Interface Governance
E. SLA Governance


Development Methodology

Web Service Development Methodology
The Services development methodology comprises of following steps.
A. Create Reusable Project Template
B. Create Schema
C. Create Service Components
D. Create Service End Points

Setup Maven
Copy the Settings.xml attached into the following folders
.m2 folder.
Conf folder of the maven install folder.

How to Create a Project template?
This section helps you in creating the Spring WS project template. The command downloads the spring project template from the maven repository and installs it in the services folder.

C:\Projects\ANF\Services>mvn archetype:generate -DarchetypeGroupId=org.anfcorp.service -DarchetypeArtifactId=service-archetype -DarchetypeVersion=1.0-SNAPSHOT

This section creates the transforms the Spring project created using the archetype into an eclipse project. Run the following command from the folder created by the archtype command. In this case it is anfservice.
mvn eclipse:eclispe
Import the created projects into eclipse by selecting the “Existing Projects into workspace”.

The imported eclipse project must look similar to the following image.

The projects that require to be imported are:
a. Service Project
This is the parent project containing all the other folders. This project has the folders representing all the other folders such as DAO, Domain, Service and SpringWS. Importing this one project is sufficient if there is no requirement to build the other projects individually.
b. Service DAO
This project has all the DOA classes that are required to be used by the service implementation. This classes in the folder must ideally not contain any business logic and must only have the data access, data persistence and data mapper code.
c. Service Domain
This project will contain domain specific classes. This can be the service interface and the domain objects. The Service interface represents the business operations that will be made available as web services. The domain classes can fall in two categories which are the Schema generated classes and or Or the domain objects that are to be used in the service implementations.
d. Service-Service
This project will contain the Service implementations for the interfaces defined in the service interface. These service implementations are referred by the spring WS configuration file. There can be more than one implementation for the service interface which can be releasing the same interface for different business processes.
e. Service-SpringWS
This project will contain all the spring specific classes and all the spring framework supporting classes. The Endpoints are to be realized in this project.

Updating the POM files

Service Project
Replace the parent element of the pom as follows.

bootstrap
com.anfcorp
2.0

Service DAO
Replace the parent element of the pom as follows.

bootstrap-jar
com.anfcorp
2.0

Service Domain
Replace the parent element of the pom as follows.

bootstrap-jar
com.anfcorp
2.0

Service Service
Replace the parent element of the pom as follows.

bootstrap-jar
com.anfcorp
2.0

Service SpringWS
Replace the parent element of the pom as follows.

bootstrap-war
com.anfcorp
2.0

Import the Schema.
Schema is created using the Modelling tool, in this case it is Enterprise Architect. The creation of Schema is described in the other document.
The class files are generated are generated by the build process
Configure the Web.xml
Web.xml is required to be configured for the message dispatcher servlet. The Message Dispatcher Servlet is the first point to receive the service request and then delegates the request to the appropriate endpoint. The message dispatcher servlet is logic is declared using the *-servlet.xml which is explained in the next section.
The important section in the web.xml is:

spring-ws
org.springframework.ws.transport.http.MessageDispatcherServlet
transformWsdlLocations
true


Servlet-name element assigns the name to the Message dispatcher servlet. The name is an important attribute as the *-servlet.xml is prefixed with the name assigned here.
Servlet-class element maps the MessageDisptcherServlet to the servlet-name. This can be the spring framework specific class or can be extended and implemented for any reason.
The initialization Parameters in this case assigns to transform the WSDL location to the application context path.

Configure the Spring-ws-servlet
Spring-ws-servlet.xml is required to be configured for the message dispatcher servlet. The Message Dispatcher Servlet is the first point to receive the service request and then delegates the request to the appropriate endpoint. The Message Dispatcher servlet behaves as configured in this file.
The Elements that are configured in this file are:
a. End Point
b. Type of End Point Mapping
c. Service Class
d. WSDL generation
e. Schema
f. Marshalling Framework
EndPoint
Endpoints are the central concept in Spring-ws. Endpoint provides the access to business service interfaces. An Endpoint is responsible for interpreting the XML Request message and send the XML Response to the requestor. Spring-WS provides variety of endpoints and various ways to handle the XML request and response.
The most commonly used endpoint base class is PayloadEndpoint, Which provides an invoke operation to be extended.
The variants of the PayloadEndpoint’s are as listed below.
a. AbstractDomPayloadEndpoint: By extending this class to implement the endpoint, we can use the w3c dom Element hierarchy to handle the request and response.
b. AbstractMrashallingPayloadEndpoint: By using this type of Endpoint, a Marshalling framework can be used to handle the request and response XML.
c. AbstractValidatingMarshallingPayloadEndpoint: the subclasses of this can implement the validation error handling logic by implementing onValidationErrors
d. AbstractFaultCreatingValidatingMarshallingPayloadEndpoint: The subclasses of this type generate a SOAP fault whenever a validation error occurs. The error codes are resolved using the application Context message source.










Following is the GetBrandByIdEndpoint and GetBrandsEndpoint for Reference:

package com.anfcorp.rms.organisation.ws;


import javax.xml.bind.JAXBElement;

import org.springframework.oxm.Marshaller;
import org.springframework.ws.server.endpoint.AbstractMarshallingPayloadEndpoint;

import com.anfcorp.rms.service.OrganizationService;
import com.anfcorp.rms.service.domain.Brand;
import com.anfcorp.rms.service.jaxb.GetBrandByIdRequest;
import com.anfcorp.rms.service.jaxb.GetBrandByIdResponse;
import com.anfcorp.rms.service.jaxb.ObjectFactory;
import com.anfcorp.rms.service.jaxb.conversion.OrganizationJAXBDomainToSchemaConverter;
import com.anfcorp.rms.service.jaxb.conversion.OrganizationJAXBResponseCreator;

public class GetBrandByIdEndpoint extends AbstractMarshallingPayloadEndpoint {

private OrganizationService organizationService;
private OrganizationJAXBResponseCreator responseCreator = new OrganizationJAXBResponseCreator();

public GetBrandByIdEndpoint(OrganizationService organizationService, Marshaller marshaller) throws Exception {
super(marshaller);
this.organizationService = organizationService;
}

protected Object invokeInternal(Object unmarshalledPayload) throws Exception {
System.out.println("getBrandByIdEndpoint start");

// get data needed for service call parameters
JAXBElement getBrandByIdRequestJAXB = (JAXBElement)unmarshalledPayload;
GetBrandByIdRequest getBrandByIdRequest = getBrandByIdRequestJAXB.getValue();
Long id = getBrandByIdRequest.getId();

// call service
Brand brand = this.organizationService.getBrandById(id);

// convert the service response into schema objects and return
return responseCreator.createGetBrandByIdResponse(brand);
}
}




package com.anfcorp.rms.service.endpoints;

import java.util.List;

import org.springframework.oxm.Marshaller;
import org.springframework.ws.server.endpoint.AbstractMarshallingPayloadEndpoint;

import com.anfcorp.rms.service.OrganizationService;
import com.anfcorp.rms.service.domain.Brand;
import com.anfcorp.rms.service.jaxb.GetBrandByIdResponse;
import com.anfcorp.rms.service.jaxb.GetBrandsResponse;
import com.anfcorp.rms.service.jaxb.ObjectFactory;
import com.anfcorp.rms.service.jaxb.conversion.OrganizationJAXBDomainToSchemaConverter;
import com.anfcorp.rms.service.jaxb.conversion.OrganizationJAXBResponseCreator;

public class GetBrandsEndpoint extends AbstractMarshallingPayloadEndpoint {

private OrganizationService organizationService;
private OrganizationJAXBResponseCreator responseCreator = new OrganizationJAXBResponseCreator();

public GetBrandsEndpoint(OrganizationService organizationService,
Marshaller marshaller) throws Exception {
super(marshaller);
System.out.println("I am in the constructor");
this.organizationService = organizationService;
System.out.println("I am done here");
}

protected Object invokeInternal(Object unmarshalledPayload) throws Exception {
System.out.println("getBrandByIdEndpoint start");

// call service
List brands = this.organizationService.getBrands();

return responseCreator.createGetBrandsResponse(brands);
}

}


EndPoint Mapping
The EndpointMapping configures the chain of invocation when the request is received by the message dispatcher servlet. When the request is received by the MessageDispatcher servlet it will hand it over to the endpoint mapping to create an instance of the EndpointInvocationChain. The MessageDisptacher will invoke the endpoint and any interceptor configured in the chain as show in the sequence diagram above.
Endpoint mappings generally inherit from the AbstractEndpointMapping. This offers an interceptor property.
The types of Endpoint mapping’s are:
a. PayloadRootQNameEndpointmapping: The PayloadRootQNameEndpointMapping will use the qualified name of the root element of the request payload to determine the endpoint that handles it.
b. SOAPActionEndpointMapping: You can use the SOAPAction HTTP header to route the messages.
c. MethodEndpointMapping: This Endpoint allows you to Handle multiple requests to one Endpoint class.
a. PayloadAnnotationMethodEndpointMapping: uses the @payloadRoot annotation with localpart and namespace element.
b. SoapActionAnnotationMethodEndpointMapping: uses the @SoapAction annotation to mark methods with a particular SOAPAction.




getBrandByIdEndpoint
getBrandsEndpoint







Service Class
The Service class is the business service which provides the implementation of the business service. This Business service is invoked by the endpoint class as like a regular java object.
It is declared in the *-servlet.xml as follows:


Following is the Java Service Implementation

package com.anfcorp.rms.service.service;

import java.util.List;

import com.anfcorp.rms.service.OrganizationService;
import com.anfcorp.rms.service.dao.OrganizationDAO;
import com.anfcorp.rms.service.dao.OrganizationDAOImpl;
import com.anfcorp.rms.service.domain.Brand;

public class OrganizationServiceImpl implements OrganizationService{
OrganizationDAO organizationDAO = new OrganizationDAOImpl();

public Brand getBrandById(Long id) {
return organizationDAO.getBrandById(id);
}

public List getBrands() {
return organizationDAO.getBrands();
}
}

WSDL Generation
A service contract is generally expressed as a WSDL file. In Spring-WS, generating the WSDL is based on the XSD and following few standard conventions.








The bean id determines the URL where the WSDL can be retrieved. In this case, the bean id is “organization”, which means that the WSDL can be retrieved as orginisation.wsdl in the servlet context path.
The schema property refers to the Messages.xsd.
We define the PortType to be OrganisationResource.
LocationURI sets the location where the service can be reached “/organisationService”
With TargetNamespace attribute you define the targetNamespace for the WSDL definition.
Schema
The Schema is used by the WSDL generation.




Marshalling Framework
Marshalling Framework serializes object to XML, and an unmarshaller desrializes XML stream to an Object.
Marshallers can be configured using tags from the oxm namespace.
The Marshallers that are supported
a. Jaxb1Marshaller: The Jaxb1Marshaller class implements Marshaller and UnMarshaller interface form the spring framework.




b. Jaxb2Marshaller: The Jaxb2Marshaller class behaves the same as Jaxb1Marsahller except that it supports classesToBeBound Property.





Complete Project File:
Please find the attached zip file which can be used for prototyping.

The Deployable war is as attached.


Appendix

Configuring Marshalling Frameworks
a. Castor: Castor implements Marshaller and UnMarshaller interface form the spring framework.


b. XMLBeans: XMLBeans implements Marshaller and UnMarshaller interface form the spring framework.


c. Jibx: JIBX implements Marshaller and UnMarshaller interface form the spring framework.

com.anfcorp.organisation.schema.Brand


d. XStream: The XStreamMarshaller does not require any configuration, and can be configured in an application context directly. To further customize the XML, you can set an alias map, which consists of string aliases mapped to classes:



com.anfcorp.organisation.schema.Brand

SOA Step by Step guide

Maturity Model

The SOA Methodology defined in the document is designed to achieve the organization wide maturity. The maturity model perceived is 5 Level maturities in terms of Application Design, Application Management and Application Governance.



Level 1- Silo Applications
Level 1 of maturity is the basic level of Application development ability which signifies the ability to Design and Develop application which has a lifecycle of its own. This application will have bare minimum level of integration with other applications. The level of integration even if exists will be using a non standard approach such as datastore integration or through custom data interchange.

Level 2- Standard Interfaces
Level 2 of maturity is the maturity in enterprise Application architecture where the applications are built for integration with other applications within the enterprise. The ability to integrate is brought in with the maturity in the standardization of the definition model of the interfaces.

Level 3- Composite Applications
Level 3 of Maturity is the ability to choreograph or orchestrate the applications by integrating all the functions within and outside the application. In this level of maturity the process flows are defined by mapping the functional elements from across the application portfolio. The organization is benefited with seamless application experience decreasing the “turnaround time” and increasing the ROI.

Level 4- QOS Governed Access
Level 4 of Maturity is the ability to integrate and compose the application from both within and external to the enterprise. The experience of seamless ingratiation with applications external to the department or enterprise requires the application ecosystem / infrastructure to be resilient to the expectations and challenges which are beyond the fine command and control. With level 4 of maturity an organization will have the necessary infrastructure and patterns implemented to handle the QOS requirements but not limited to Security, Reliability, Availability, Non-Repudiation etc.

Level 5- Governance Design Time, Run Time
Level 5 of maturity is the ability to correlate the business and IT. In this level of maturity organisation will be able to translate the organization policies into application rules. These rules will need to be applied to the business processes and regulate the processes to adhere to the rules defined. The Governance is classified into two categories. Design time Governance and Run Time Governance, In the Design Time Governance the organization principles and objectives are mapped to the design time process and design time considerations. In Runtime Governance the organization maps the organization policies to the processes which will govern the operations on a everyday basis and will lead to leaner organization by eliminating redundant checks to be carried out by intelligent personnel.

Level 6- Dynamic Process composition
Level 6 of Maturity gives the organization the state of absolute control and Automation. In this state the business process are self composed and tuned to react to the situation as and how it occurs. In this Level of maturity the organization is run on processes. This level of maturity is attained by a multidimensional maturity including the Infrastructure, processes, Events definitions, Rule definition and Specification definitions.

SOA today and tomorrow.

Today there is no developer who does not talk about SOA. It is a very interesting topic to me as well. I have been involved with SOA related development for quite some time now. There are two interesting aspects of software development that come to the fore front when we think of SOA.

1. Re-Usable.
2. Interoperable.

These are the two things we try to achieve to the best possible limits when we implement an SOA solution.

These are the two aspects that will take SOA to the next level.

Here i will like to collate some of my thoughts on the existing limits and the potential limits.

1. Re-Usable.

Re-usability is commonly confused to be copy-paste by few developers, many developers as of today make the truly re-usable components but couple them to the context they use it in. the coupling may be with the parameters or the output. well, if we sit back and think how different is this from copy-paste. The best example is some of the design patterns that come to our help provided by the IDE's. Few smart developers are matured to truly make re-usable components that are developed once and deploy able in many projects out of the box.

SOA takes re-usability to the next level. SOA preaches true re-usability of the components. In SOA terms re-usability means develop once, deploy once and use it in many projects.

Re-usability tomorrow: according to visionaries, the re-usability has still to go to the next level. The software vendors will develop and deploy the software components pertaining to the specific business needs and will host them and make them usable at a specific price. The consumers will just own the business process built specifically for there business goals. These business processes will be built around the components hosted by the software vendors. This is when truly your fridge can order for milk as envisioned by the XML/SOAP visionaries back in early 2000.

2. Interoperability.

Interoperability is been a concern for over a period. This is the major challenge is true collaboration and enterprise integration. Over a period of time there have been various industry efforts and industry initiatives to address the Interoperability concerns. The evolution of interoperability once was just divided into two layers the network layer and the application layer. Various initiatives that have been revolution start right from the network protocol definitions such as TCP/IP, HTTP, SNMP, SMTP/POP, IMAP and many more. When these network layer was evolving there has been little effort in evolving the application interoperability concerns. The well known once are CORBA and DCOM.

Interoperability at the application layer had a major breakthrough with the introduction of XML. With the introduction of XML enterprises started having self defined (home grown) business protocols, which helped them achieve interoperability at lesser cost between various applications.

This lead the standard body such as OASIS to define business protocols across industries for the participants to inter operate.

There are two classes of interoperability specification evolving hand in hand based on XML.

1. Infrastructure Level.
2. Application Level.

Infrastructure level interoperability specification for example SOAP, ebXML and ws-* are the specification that defines the meta data for the messages which carry the message state such as security, reliability, traceability and non-repudiation. The messages adhering to these specification can be understood and used to invoke the desired/mentioned service.

Infrastructure Interoperability Tomorrow: Interoperability has a very long way to go to reach the maturity of consolidation and universal data formats. SOAP over any network is the defacto transport specification. Based on the wide industry support, flexibility and adoption WS-* specification looks the ideal way further, but the consolidation and maturity ebXML demonstrates is very much appreciable with the current context. The mix of these two set of specification will provide an strong platform for message interoperability in which ebXML addresses the essential requirements of the message communication and WS-* provides optional specification for finer activities such as transactions, large messaging and message transformation.

Application level interoperability specification for example HL7, Rossattenet and OTA-XML are the specifications that defines the meta data for the business message. These specifications define how the business message is structured and what level of information is required for a specific business transaction.

Application interoperability tomorrow: The different specifications for different industries posts a greater challenge towards evolving a universal specification. The challenge is not technical, the challenge is the significant difference in the business process in each industry. The participation of an enterprise with different industry partners in a specific business processes is quite likely to happen. One of the possible options is to have a data model for an enterprise and message adapters to be built to transform the business domain specific message into enterprise domain message. This will be enabled by various tools that business analysts would use to map the domain specific elements to the Enterprise domain as one time configuration activity.

Kalimulla Shariff.