/* Google Analytics ----------------------------------------------- */

Sunday, February 3, 2013

SOA for real - Part 2 - Let's talk about service

Lets talk about service. The most difficult part of SOA is to find the right services. Here several schools are fighting:
  1. Software engineering: Design a service in order to reuse it as much as possible
  2. Business Process Management: Design a service in order to manage all its lifecycle states from a business objects
  3. Interface Management: Design a service in order to offer CRUD services in a uniform way
Of course this is highly depending on your SOA program objectives. Anyway, the apporach we followed was the following one:
  1. Define and describe semantically each business objects and its relationships with other business objects (static and dynamic vision). This job could be done for internal and/or external usage (in order to protect Intellectual Property or to comply to security / privacy regulations). Do not forget to define error management, and impact of end of life on a business objects (do we need to archive, destroy physically, etc.).
  2. Then describe each object lifecycle. Each transition in the lifecycle will become a service. Pre and post condition are described using Business rules (OMG provided new standards in this area since several months). All Business event should be clearly described, since talking about SOA, most people think request/reply. But today dynamic architecture require to support intelligent and complex information/process flow break-up or exception handling. So, sometimes a full conversation using message exchange patterns (MEP) should be described instead of a list of stateless request replies. That's where WSDL 2.0 supporting several MEP is providing a definitive improvement. Of course, this is also true for REST based communications.
  3. Map each business object to one or more XML schema format. Make all Web service use this schema.
  4. Build a service catalog. Define the cost, SLA, monitoring of each service created and propose a clear an concise documentation (with examples and client code snippet). When possible implement the service catalog on line.
  5. Virtualize services in order to meet customers needs and to reuse existing services. Another way to do it is to use orchestration of existing services.
  6. Review the service catalog every month. Services could be then deprecated, extended, merged, ant it pricing could evolve.
  7. Protect your IP. Every asset can be protect as IP from XSD to WSDL or services name.
This is the first part of your work: the design time part. Try to be technology agnostic when doing this work. So, if you create your WSDL, do not generate it. The recommended practice here is contract first approach.

Then you can move to the realization of the planned services. What is needed now is:
  1. Implement the service with the technology you want, but do care since the beginning that today access to the data is the main bottleneck. So, do not forget to evaluate caching data in memory (Memcached, terracotta) or using new kind of DBMS adapted to high volume (couchDB, etc.)
  2. Define where the services will be deployed (internally, cloud, etc?).
  3. Developing the service and deploying it in production.
  4. Using your web service management platform to deploy the service policies and provide reporting on Key Performance Indicator, usage statistics, errors and SLA.