Practical AgileSOA - The emerging infrastructure

Vendors would like us to believe that there will be no SOA without their products.

Nothing is further from the truth.

However, an emerging SOA is supported by an emerging SO infrastructure.

Here we talk about which pieces may be needed at which level of SOA maturity.

If you are starting with synchronous request-reply services using XML to exchange data, you do not need anything but standard development environments. Java and .Net come packed with parts to create and parse XML documents and send and respond to requests.

If you want to start with Web services (SOAP over HTTP) then you can decide to use the basic parts of your development platform or use what's called a SOAP stack. This is a collection of libraries and code generators that take care of the transformation of your objects to SOAP XML and back, and take care of the request and reply formatting.

The beauty of these SOAP stacks is that they make building Web Services a snap. The main drawback is that they rely on generated code, which is notorious for quality and performance problems. (A friend of mine was even working around a bug in his code generator without blinking)

Using SOAP has many advantages. For one, there are some great products out there that support the testing, running and management of SOAP-based Web services.
The disadvantage of SOAP is that it has an unwieldy XML format, which makes its application limited to situations that do not have sub-second response time requirements.

The next step in your SOA infrastructure must be monitoring. After all, with measuring request volume, response times and latencies, you can prove that:

1. your services are used
2. who uses them
3. what your average performance is

This is a critical step in your emerging SOA, since at this point you can demonstrate that your existing services are indeed being used and to what extent.

Depending on the level and type of security required by your organization, you may have to think about that from the get-go. But this is not the case in every organization. Make sure that you define the authentication and authorization requirements for each service that is being launched. Sometimes, an access control list will do. In other cases, you will want to have full authorization, authentication and audit trail.

Whatever the detailed security requirements are, you will want to have a central security management facility, such as a federated identity management service that hands out certificates upon successful authentication. That way, new services can simply reuse (there's that word again) what has already been fleshed out and capitalize on security improvements as they become available. Making services use certificates to request from or subscribe to services works like a daypass to an amusement park: whatever type of pass you bought determines to which rides you can get in.

A whole string of posts could be dedicated to BPM, BPEL, orchestration and choreography. Let me just note that some type of business process monitoring should be baked in to your services from the start. How you use that will become apparent as your SOA matures. Hold off on buying even more SOA products, now those that purport to do modeling and monitoring out of the box for you. Yes, they may have great demos and user interfaces. But think about what you are trying to accomplish. Evaluate later on whether the number of BPM-enabled services are becoming hard to manage and if a commercial product will help you grow.

Next post: How to promote and incentivise reuse