One of the benefits of a SOA style of architecture is reuse of services. It is also one of the more challenging benefits to realize. A lot of people found early on that simply slapping a Web Service out there and calling it a service along with opening the flood gates to use it was not such a good idea. Because of ill defined definitions, wrong service granularity and lack of governance, a big mess was created. Agility and reuse went out the door.
Here are a few thoughts on service design that have helped me achieve a fair amount of effective reuse and agility.
1-Granularity
Coarse grain versus fine grain is the basic decision point. The more coarse grain the service, in other words the more stuff it does, the less likely reuse will occur. What I have found to be effective is to start with a lot of "medium" grain services. These services do something beyond the basic add two numbers together but stop short of containing a lot of business rules. They tend to lend themselves to orchestration by multiple business processes.
These services also make up the core of the composite services. The benefit here is these services can appear both in the higher level composite services as well as be accessed directly.
2-Data Binding
Data type conversion among the platforms is challenging. Simple guideline here is keep it simple. Go here for more detail but I would recommend keeping it even simpler when you can. Remember string is king.
3-Exotic WSDL
Along with the thought on data binding comes exotic WSDL. Same kind of mindset applies here as well. Just because you can put it into a WSDL doesn't mean you should. The more stuff that you put into a WSDL the less likely its going to be compatible with everything that needs to consume it. Agility can take a hit here too.
Key point here is WSDL is just a definition of an interface not the implementation or the consuming service. It's up to physical implementation to actually provide the concrete stuff. That's were things can go astray. Chances are you have a lot of stuff in your enterprise. The chances that each thing you have will support the wide variety of stuff that can be stuffed into an interfaces definition is remote at best.
The other issue is that to much stuff in the definition can create a brittle interface instead of a robust one. Agility suffers and reuse is difficult. I would in most cases steer clear of putting strict business rules in the WSDL.
4-Governance
Some level of governance is required to managed this entire approach to designing systems. It doesn't have to be overly complicated but should include things like: code reviews, interface design reviews, testing polices and change policies. Sometimes when governance is put in place it's at to high of a level. Governance in the SOA world has to be very active and down in the trenches.
Reuse is possible in SOA. But you have to take care not to over engineer your interfaces. If you do that then reuse can be achieved and agility will also magically appear.
6 comments:
Good tips Mark. It is obvious that you are a "man in the trenches." I agree with all your points, learning the hard way with experience.
One thing I do is separate my service interfaces by style of interaction. We have information retrieval (a.k.a. Data Services) that are separate from our action oriented services (a.k.a. Transaction Services). I have found that the rate of change is much higher for the information services than the action services, so separation minimizes impacts to consumers.
Data Binding is indeed still problematic and I tend to stick to string, boolean, int and decimal for my element types. I do simple extensions where practical but not many. I have had many a heated discussion with other architects who try to make the schema behave like they would model it in an OO language. The more complex the schema model the more the tooling breaks down.
Can't say enough about Exotic WSDL issues. I use monolithic WSDL to avoid tooling issues with includes and stick to the basic WS-I profile items where possible. Haven't utilized many of the WS-* standards as there are still tooling issues. WS-Security is the one exception here where most vendors have decent interoperable support.
I think your point about over engineering the interface is key and this is where Governance comes into play. Too strict an interface helps govern interactions, but it is not agile. The days of "build to last" are over. It is "build to change" in today's business world and our interfaces need to be loose and agile to gain reuse. A loose interface requires process and governance to control and understand usage and help manage the inevitable change.
Good post!
Steve
Hi Steve,
Great comments, sounds like we have had similar experiences in the trenches of the service world.
Mark
The concept around basic datatypes ( string boolean etc) is fine. But we are using Global data Types which are consistent with the organisation. Do you have any experience with that? Was curious if you faced any issues etc
Aloha to you Aloha!!,
Global types are a pretty big subject which are probably needing another post all together.
Where as the low level primitive types will cause you grief at the technology level, global types will cause you grief at the service and business level.
It's amazing with all the SOA talk that has gone on, the area of XML schema design has received very little attention. Yet the ability to design these higher level types correctly can really affect your reuse and agility.
I can tell you in a nutshell I like to keep global types confined to business domains when possible. Trying to come up with the ultimate data model for an entire organization is pretty tough and kind of like painting the Golden Gate Bridge, once you are done you start all over.
mg
good tips,i've never find my self designing services,but i am much more involved on SOA Governance measurement and metrics development and one of the measures that was identified was percentage of service reuse and agility. what are the measures that one can look at when measuring service reuse and agility.
Edwin
Edwin,
Good questions. Reuse should be pretty easy assuming you are tracking usage via your governance implementation. Agility is a bit more difficult.
First thing is to define what agility means to your org. Is it an IT measurement for how fast it can respond to changes or how fast it can make changes and/or implement new stuff? Or is it defined as how responsive the business can be to new things? Both are valuable measurements of the value of agility.
I think once those definitions are out there then you have to get some baselines to compare old way versus new way. That's not going to be real easy but if you need hard numbers then that's a way.
Post a Comment