Inside scoop on Oracle SOA Suite, BPM and EDA

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 ..