The hot topic in our organization is Service Design Approach.
First Approach – The team wants to design services which essentially have one operation, can take any XML and return response XML message. The operation and the parameters are in the request XML message. Once the message is received the service determines the action/method that is requested. Reasons cited are ease of deployment and flexibility of introducing future operations.
Second Approach – The second group is adamant about well defined service contracts and specific messages. Reasons cited are better performance, message validation and versioning. This is my preferred approach as well.
What are the Pros and Cons? Can there be challenges introducing an ESB later in the architecture if we have chosen the first approach?
2
Design services that are logically required by the application domain, not artificially designated by abstract a priori architecture.
Some will have one simple operation and be stateless, others may be more complex.
As far as choosing an interface mechanism goes, separate the message format from the services and clients using the Adapter pattern, so you don’t knit yourself a straightjacket from the start 😉
Con for generic services:
Generic services are nightmares to maintain. You can’t easily decipher what’s going on. And they are hard to test since there are generic. If the contract is defined, I can use a tool like SOAP UI to create test messages pretty easily. If generic, I have to craft the XML by hand (I could still use SOAP UI to send it). Yuck. Strike 1 for maintainability and 2 for testability.
Everything with generic services comes in as an XML string. Everything that is not a string needs to be cast or converted to the correct type. Because of this they will be slower and consume more resources. Extra XML parsing and dynamically invoking methods from strings has more overhead. Strike 3 for needless XML parsing, cast and conversion, and service performance.
I did a somewhat generic data model and service once where part (not all) of the message was meta data and it was much tougher for people to understand how the data went in and came out. It was flexible but in the end probably a more explicit contract could have been used since there haven’t been too many additions/changes that utilized it’s flexibility since the service inception.
The silver bullet of never having to change a system again because it is generic is never realized. It’s a dream that exists in the astro-architecture head.
Services are better served with explicit contracts. You send me X and I’ll give you back Y as defined in the contract. I can publish my contract to consumers so they can code against it and even mock it prior to service release.
Change happens, so version your services contracts. No big deal to run a few different versions of the service on your web server by having different URLs.
One generic service to rule them all is best served in the fires of Mount Doom.