Once you’ve decided to take the SOA plunge, there are a number of things you need to consider. I’m not going to try and address all of these, but one of the things you will eventually confront is how to answer the question: “how am I going to implement my services?”
Two of the main things you need to consider when answering this question are:
- What are my interoperability requirements?
- What are my portability requirements?
As I mentioned in a previous post, the answers to these two questions aren’t necessarily mutually exclusive.
While SOA as an architectural style provides you a way to span platform and organizational boundaries with the ubiquity of HTTP, from a practical point of view, you’re going to have to build and manage an application environment that hosts the services that drive your business. You may be in a position to start from scratch, but chances are this isn’t the case. Whatever you eventually choose, this environment is your service platform.
The focus of this article is how you actually write your service implementations. With advance apologies to the .NET crowd in the audience, I’m going to focus this discussion on the Java world. However, I think that in practice the points raised here are just as relevant, but, at least as far as I know, there are more competing environments and approaches in Java-land.
Specifically, I am going to consider the following specifications and approaches:
These specifications will be discussed and evaluated based on the following criteria:
- Level of support for both synchronous and asynchronous messaging
- Level of support for component configuration at deployment time
- Level of support for location transparency in components
- Level of support for multiple physical transport technologies
- Level of abstraction of the component from transport and transport characteristics
- Level of support for run-time configuration and deployment
- Complexity of the framework API
- Reliability and failover characteristics
- Scalability and deployment considerations
- Support for complex message conversations
- Portability of components between implementations of the specification
Additionally, I’ll make some comments on the following points:
- Overall strengths
- Overall weaknesses
- Implicit assumptions
- Potential “gotchas”
It is important to choose your service delivery platform carefully, because you’re likely to be stuck with it for some time. Generally speaking, there’s always a way to make a particular approach work for the problem you are trying to solve. However, only through a thorough and objective evaluation of the options can you select the approach which is most harmonious with both your business requirements and your organization’s implementation and operational capabilities.
The only guarantee about any software project is change. This means that you need to consider this up-front, before you’ve invested in either time or licenses on something which doesn’t support the types of change you foresee in your environment. Like I said before, it isn’t that a particular approach doesn’t support changing environments; it’s all down to how easy that support is to leverage based on your requirements and your team’s skills. There is already enough stress in most development projects without having to fight your tools and technology to get it to do what you need to do.
Over the last 18 months, I’ve been giving this topic a lot of thought. In that time, the technology landscape and options for service delivery platforms has changed considerably. From experience, the service platform does make a difference–even though it may not be apparent at day one. This discussion is not going to focus on particular vendors. Once you have digested the information here, you can make up your own mind about what you need, and there are currently plenty of vendors out there who can help you. This discussion is about selecting the right pieces of technology to complement your architectural goals. Hopefully, you will find it useful.