Intrinsic interoperability - what it is, and what it's not ..

The soa manifesto notes amongst other values
Intrinsic interoperability over custom integration

While the REST gang (and that's meant nicely) demands this one as the justification why every service should be based on REST (read architectural style) I would argue that this is at the very best a small part of the whole puzzle. Yet an important one (arguably HTTP is by far the widest understood protocol, with implied transport, security, and lastly CRUD type operations [create / update / delete & find] syntax)

Anne Thomas Manes (Burton Group, fellow co-author) for example noted in her blog post "Intrinsic interoperability is a function of semantic compatibility more than anything else. If you have to stick a transformation function into a communication path, you don't have intrinsic interoperability" - I like that, a lot actually ..

So here are my thoughts ...
a) Interoperability comes in multiple facets (protocol, transport & semantics [of data and shape])
b) REST as architectural style covers at the first two, yet being forced into 4 verbs (GET, PUT, DELETE, POST) is forced protocol interoperability, as opposed to intrinsic interop. IMHO
c) The key to interoperability, intrinsic that is, is first and foremost a widely accepted [readable/discoverable/interpretable] description of capability and a common understanding of the exposed data that is offered / consumed [that is the semantics]. Syntax comes second in my world.

So with all that said, yes it's pretty darn hard to "create" intrinsic interoperability, if you don't start on a green field (I think a putting green; nice, clean, and a little bumpy), or put a lot of thought into your incarnation (instance) of SOA in the first place

The key to enable real intrinsic interoperability is likely to be found in semantic / syntactic mapping that happens transparently at runtime (inside the connecting infrastructure) that powers services. Mapping MEPs / protocols / transports - is [unfortunately] the real world, and how systems (will) likely communicate over the next centuries.

However to really save cost in the long term [refer to "sustainable value" / "strategic goals"] - as opposed to the "stick a transformation in every communication path [courtesy of Anne T. Manes]" you gotta design your service landscape with intrinsic interoperability in mind.

a-1) Each service MUST describe its capabilities, in a commonly accepted [for your consumers] format. That includes [yet is not limited to] security, QOS, structure, responsibility, contact and pricing model, version (and change history)
a) Employ a [domain based] common data model
b) Use async' MEP patterns wherever possible
c) Expose services via multiple bindings [e.g. SOAP [jms/http], POX/HTTP, Java, JSON]
d) Offer forward based - as well as a backward based - compensation handling facilities
e) Employ REST-like concepts where it makes sense (data driven, CRUD type services)
and f) even with all that you'll possibly still need some sort of mapping / transformation [call it ESB, call it whatever else you like..] that allows all the not-so-intrinsic-interoperable pieces to participate happily ..

Comments:

Interesting article, Clemens. I liked especially the pragmatic way of going step by step. The only issue I see currently, when I take a look at the WS Service world with statement "b) Use async' MEP patterns wherever possible". As I am a supporter of asynchronous technologies, I am still missing some async messaging style techniques in the WS Basic Profile. But it seems, that no movement will come across within that area. Cheers, Christoph

Posted by Christoph on November 30, 2009 at 10:29 PM PST #

Interoperability refers to the sharing of data. The more interoperable software programs are, the easier it is for them to exchange information. Software programs that are not interoperable need to be integrated.

Posted by frauenmantel on December 09, 2009 at 09:41 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Tips and tricks straight from the SOA / BPM development team at Oracle HQ

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today