Background
In my childhood, I had heard the story of 'the sky is falling'. In my adulthood, in my profession (software services), I usually see this story in action.
Service Oriented Architecture (SOA) belongs to this category. I see lot of enterprises going hyper-enthusiastic over SOA but at the heart people seem to have a fundamental question 'the thing that we are doing, is it really SOA?'.
It is our general tendency to get approval of what we are doing. Sometime we ask experts, seniors and knowledgeable people and other times we have a criteria to decide for ourselves. With SOA, both seem to fall short because SOA is described in such abstract terms. Hence, we end up with this nagging question all the time.
In this article, let us define a new term 'Web services based architecture' (wesba) that represents implementing SOA using web services. We would also come up with a checklist that would help enterprises to be clear of abstraction and clearly know whether they are doing wesba or not.
Why another acronym?
At this point, you might have several questions. I will answer these one by one.
1. Why do we need one more term and architecture?
There are several reasons why we need a new term and architecture. 'SOA' is an overloaded term. Many people define/implement SOA in various ways and each one thinks theirs is the correct one. If you visit any SOA forum, you will see people arguing SOA for a style or an architecture or an implementation. This is because SOA is defined in abstract terms and people are not able to relate these to things in real life.
We need an architectural instance of SOA (considering SOA is a style) which people can recognize instantaneously, relate to it in real life with existing technologies and answer in clear terms whether they are following it or not.
2. How is new architecture different from SOA?
wesba is not different from SOA. It is more like an architectural instance of SOA. wesba will outline technological constraints and provide concrete technology dimension to abstract SOA principles. An example would be, wesba mandates the use of SOAP based web services where as SOA defines the service in abstract terms.
3. What are the benefits of the new architecture compared against SOA?
Clearly defining the technology components of an architecture helps in better communication. It also helps people avoid the unanswered question of 'is what I am doing SOA?'. Apart from this, since wesba is an architectural instance of SOA, it has the same advantages that SOA has.
What is wesba?
wesba is an implementation of SOA using web service technologies. It makes use of open specifications/technologies like HTTP, XML, SOAP, WSDL and XML Schema. The actual products used to implement wesba might vary. This is analogous to implementing a client-server architecture using various technologies/products.
wesba (1.0 version) is different from plain vanilla web services because it places few more constraints. Let us see these constraints.
0. All services are web services
All services exposed to consumers are web services. i.e. they make use of SOAP protocol over HTTP or HTTPS. SOAP message carries XML payload optionally attachments. The schema for XML payload is defined using XML schema. The service itself is described using WSDL.
1. WS-I Basic Profile Compliance
All services are WS-I basic profile compliant. This would place further restrictions on what specifications are used along with their versions.
2. Custom SOAP headers
The services and service consumers must support use of custom SOAP headers. Adding a new SOAP header element must not cause problems to existing consumers as well as services.
The services and service consumers must support use of custom SOAP headers. Adding a new SOAP header element must not cause problems to existing consumers as well as services.
3. Standardized fault code formats
All services must conform to a specific fault code format. SOAP only mandates the structure of SOAP fault code but an enterprise must use a standardized fault code formats for all its services.
It must be simpler for a consumer to understand whether the request could be retried. The format should make this simpler.
4. Standardized fault codes
There are some common fault scenarios in web services, e.g. time outs, destination unreachable, invalid input etc. An enterprise must have standard fault codes for these common fault scenarios.
All services must conform to a specific fault code format. SOAP only mandates the structure of SOAP fault code but an enterprise must use a standardized fault code formats for all its services.
It must be simpler for a consumer to understand whether the request could be retried. The format should make this simpler.
4. Standardized fault codes
There are some common fault scenarios in web services, e.g. time outs, destination unreachable, invalid input etc. An enterprise must have standard fault codes for these common fault scenarios.
5. Service information repository
The enterprise must have a centralized service information repository. It must at least contain the following information about the service.
The enterprise must have a centralized service information repository. It must at least contain the following information about the service.
- Service overview
- Overview of each service operation
- Fault codes returned by each operation
- Availability of each service operation (i.e. uptime and downtime)
- Performance characteristics of each service operation (avg response time, max response time etc)
- WSDL URL
- Service endpoints in various environments like dev, test and production
6. Standardized security model
All services that require security, must support a standardized security model based on WS-Security. There should be a common mechanism to identify the consuming application and apply authentication and authorization policies.
7. Service versions
The enterprise must support a common model for service versions. The service versioning strategy must state the approach for handling different kinds of changes, e.g. non-backward compatible changes, backward compatible changes, service interface changes, service implementation changes etc.
8. Standardized encryption model
All services that require message security (signing and encryption of messages or message parts), must support a standardized based on WS-Security.
All services that require security, must support a standardized security model based on WS-Security. There should be a common mechanism to identify the consuming application and apply authentication and authorization policies.
7. Service versions
The enterprise must support a common model for service versions. The service versioning strategy must state the approach for handling different kinds of changes, e.g. non-backward compatible changes, backward compatible changes, service interface changes, service implementation changes etc.
8. Standardized encryption model
All services that require message security (signing and encryption of messages or message parts), must support a standardized based on WS-Security.
9. Agreements between service provider and consumer
There must be agreements between service provider and consumer about certain behaviour. e.g. how should the consuming application behave in case of timeouts, when the response header contains additional SOAP elements, or additional response elements etc.
The above list could be used as a simple checklist to figure out whether an enterprise is following wesba standard. The constraints mentioned above are based on real life experience of working on so-called SOA project and learning from our mistakes. Hope the list would be useful for you too.
We will expand on some of the above constraints in the later articles.
There must be agreements between service provider and consumer about certain behaviour. e.g. how should the consuming application behave in case of timeouts, when the response header contains additional SOAP elements, or additional response elements etc.
The above list could be used as a simple checklist to figure out whether an enterprise is following wesba standard. The constraints mentioned above are based on real life experience of working on so-called SOA project and learning from our mistakes. Hope the list would be useful for you too.
We will expand on some of the above constraints in the later articles.
