Doing the business bit has made me really strongly realise how important it is to keep them apart. Right now I've effectively got four different groups who need to interface to this one business service.
Now the core of the service is the same for everyone, they all want basically the same thing. The difference comes in exactly how they want to interact with it and the specifics of the capabilities that they will use. This means four independent sets of external KPIs (remember to always think of the consumer when designing service descriptions) and four semi-independent sets of capabilities. By semi-independent I mean that they are in fact strongly linked but the mode of interaction is slightly different in each case.
Now if you were building the code for this you might be thinking of four independent services that shared information together. The problem is that this means that you have disjoint processes as the reality is that one of the major KPIs for the service is that you are linking properly with all the other groups.
Sometimes you will build the interface as just that, an interface, other times it will be a lightweight façade that might do some process or data manipulation work, on a very few occasions it might be something heavier weight but still using the same underlying base service.
The other technical view would be the "sod the users" and just have one interface. The trouble is that this just means that it will be rubbish to use for everyone and it will in fact be harder to manage because that doesn't represent the way that the world actually operates.
So what I've got is a service description that describes what the service does and then I'm building four service interfaces (which are to all intents and purposes service descriptions) on how it will interact and be measured by the four external parties. This means that from a catalogue perspective I have five services, from a consumer perspective they are all getting the service that they want and from my perspective I'm getting the consistent management and centralised governance that I need.
Everyone ends up happy and the amount of duplicated work is reduced. So keep your interfaces independent of your service.
Technorati Tags: SOA, Service Architecture
9 comments:
ohhh! you finally got REST!
(seriously - it is surprising how many people forget this-the most important part of REST and concentrate on dumb things like having nice URIs and PUTting them and DELETEing them and all that stupidity)
What you are saying could also be called as HATEOAS - just a little more stuff needs to be added (which I am sure you know)
SCA?
I did mention that I'd first implemented this in a working system in 2000?
Its not REST, its just a smart SOA principle. You could then choose to implement it using REST (although of course the service description publication piece is slightly trickier ;), WS, SCA or any other numbers of ways. Personally I'm doing it for a business department with no technology at all.
Multiple Interfaces is the architectural principle, its in one sense a real SOA pattern.
"Multiple Interfaces is the architectural principle, its in one sense a real SOA pattern."
Yep, you'll see this pattern implemented in Jini services too.
SOA Newbie who subscribes to your posts, so keep that in mind...
If you have 4 separate APIs that surround the bigger service, does that not then couple all of the services together? One change in the service and it could affect everyone.
Help me understand what I am missing.
- Sean
Sean,
If you hard-wire the two then yup you will have the issue. What you do therefore is put in place a "facade" (there are a number of patterns out there, Thomas Erl has one in his new book) which provides the abstraction between the "internal" service and the external view.
The objective of the Facade is to provide that layer of indirection which enables the two bits to evolve independently (though clearly they have a degree of coupling based on the fact that the Facade is for a specific service).
Two basic rules I've always used in services project are
1) Always put a Facade between you and the consumer
2) Always put a proxy between you and the producer
This then isolates you from changes in a more controlled manner.
The point to remember is that there is only ONE service from the perspective of actual operations. The four VIEWS on the service might give the impression of four independent services but in reality they are just VIEWS (The SOA version of Database views to use an analogy), you put the Facade in to enable the views to change in a managed way.
Hope that helps.
"So keep your interfaces independent of your service."
"...its just a smart SOA principle."
"...there is only ONE service from the perspective of actual operations. The four VIEWS on the service might give the impression of four independent services..."
All good stuff descibing principle 1.A. of SOA--service interface is separate from service implementation. It's paragraph 1 of principle 1 in the 2003 paper from Gartner.
It's not only "in one sense a real SOA pattern" it is *the most important* SO principle.
Your note about "keep your interfaces independent of your service" prompted me to post about other SO principles that deserve repeating from time to time.
http://reamon.squarespace.com/articles/2009/4/21/so-principles-of-2003.html
architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment