For the past several years people have been hearing about Service Oriented Architecture through various mediums across the internet. Most of what you would read would be academic material that was difficult to think about in concrete terms.
Still today there are numerous articles and books on the subject that talk so much in theory that there isn’t enough good direction on where to go. For Joe Developer at Company XYZ, how can he take advantage of these seemingly great ideas on his next .NET (or whatever) project?
Unfortunately, this lack of good direction has led to a misconception about what SOA is and how it should be implemented.
At its heart, SOA is the next evolution of development. Just as we had objects to encapsulate our behavior and compose applications of objects, we now can encapsulate core functionality as services so that they are reusable across the enterprise, or even to our customers.
We can also take these services and compose them to create more complex services, and this can be taken to the extreme where you model every process that the business performs as a service. The idea is that new applications can be built without the need to deal with implementation, it can be done completely by composing services. Want to change the way the business functions? Rewire the business process services in a way that better suits the business.
Unfortunately, when you talk this high level, you often gloss over the technical guidance and people take the advice and run in any direction. It’s like a scavenger hunt where the treasure map is handed out and it contains details about the glorious treasure, but not the direction on how to get there.
This also leads to the misconception that SOA == Web Services, which is not the case. More on this in a minute.
So back at Company XYZ, Joe Developer is implementing his next project with an SOA. His management has also read about SOA and knows that it’s the right thing to do. In fact, they may even be pushing him in this direction. He creates his business logic, he creates his UI. Next comes the service layer. Joe thinks to himself, what better way to implement services than to be the first consumer! It will be perfect! Then any new application can access the functionality and everything will be great. I’ll have an SOA Seal of Approval on my app because I used web services and my management will be happy. And my application will be unnecessarily SLOW. And complicated. For no reason.
The reality is that Web Services are meant for interoperability. They are meant to be accessed across a variety of mediums and ports. They are great for platform interoperability and cross-political communication between applications. They are not suitable for inter-company, .NET to .NET interaction. The overhead of WSDL, SOAP, XML, etc is wasted in this scenario. Consuming a web service is not efficient. To combat this overhead, it is advised to make your remote calls as coarse-grained as possible. Chatty remote calls will kill an applications performance. So now we are designing our (!) application around the limitation of a heavyweight service layer.
This is something that I see all too often.
UI
SERVICE AGENTS
WEB SERVICE LAYER
BUSINESS LOGIC LAYER
DATA ACCESS LAYER
A better solution would be to design your application the way that good software engineering principles have taught you. Separate responsibilities. Create a domain model that represents your problem domain. Speak in terms of your domain. Leverage object oriented programming.
Then, when management decides that the functionality that you have created would be suitable to expose outside the company, or to their Java project that is currently underway, you can introduce a service layer. The service layer consumes your existing business logic layer. The idea is to introduce a more coarse-grained interface suitable for remote calls. You create Data Transfer Objects that aggregate your domain objects and are more stable for a service contract.
This is a much better approach, because we take into account the fact that we can expose the functionality of services, but we should not shoot ourselves in the foot to do so.
Now getting back to the misconception of SOA == Web Services. Why is this so common to see? First, the term Web Services is probably partially to blame. A service can be native .NET code, it can be a remoting interface, it can be SOAP over HTTP. A more effective service oriented architecture (especially one within an application) is achieved by choosing the best medium for the circumstances.
I think it’s time for an example. Say we are writing an application that calculates massive financial data for our enterprise. One component of this will calculate the exchange rate for many currencies. Ignoring the specifics of the implementation, how should we reuse this component so that the entire enterprise can access it? We want to take advantage of a plain .NET to .NET inter-process call because it’s the fastest. We’d also like to expose this to other .NET applications within our corporation. Finally we want to use this service in our Java system as well. How can we accomplish all of these without just resorting to the lowest common denominator?
One of the great things that I learned while studying Enterprise SOA in Paris was what the IBM guys call a Service Component Architecture, or SCA. This architecture is enables services to be composable. The WebSphere Integration Developer emphasizes modeling all of your business processes as composable services. Most of these will be Java to Java calls, but some may not. What they do is have you design your interface using a GUI, which spits out the WSDL interfaced and the Java interface. The best flavor of interface is chosen depending on the circumstances.
So we can solve the above problem by having one single interface, with both a .NET and WSDL versions. The configuration can determine which is used to achieve the best results.
Hopefully I’m not leaving out some core SOA concepts (I’m sure I am). What about you? Do you see too many mis-uses of SOA like I do? What other techniques can help bring the industry back to reality?
(I also must apologize for such a long-winded post. My bus is stuck on an HOV lane (one single lane with walls) in rush hour traffic. I’ve been here for over an hour already.)