04/20/08 :: [SOA] Cohesive Response  [permalink]

|

Well I got a lot of people upset: Stefan, Savas, Jim kept the legendary British cool.

Again, I stand by what I am saying, Jim's position on:

  • cohesion in SOA (beyond the trivial conclusion that any autonomous asset is by default exhibiting a high degree of cohesion)
  • process-to-service relationship
  • MVC as a design pattern for SOA/BPM
  • Business people becoming IT architects (last but not least by far)

is more than questionable.

Savas, about my communication style, I found that it works -indirectly-: these days, I don't read many more people in the REST community bashing WS-*, Tim Bray's BS on "the end of SOA", or Steve's serendipitous crap. Actually people eventually strengthen their arguments or give them up (they don't want to look stupid).  Everybody saves time: you, the reader, me. Now, yes, it hurts me, you are probably not the first one to think that I am rude and unprofessional, but that's ok, if this is the price to pay, this is a very tiny price compared to the end result.

The reality Savas, Stefan, Jim is that SOA is still raising a lot of questions. We can circle around for years if you want to. I offer an alternative: I just ask anybody to answer just two very simple questions:

Have you ever considered factoring the business logic along the lines of a Resource Lifecycle? How does this fit with whatever your recommendations are?

Answering these two questions alone would end the REST/WOA vs SOA, MEST vs WSDL, BPEL vs BPMN (if you want to) and surface how critical representation-friendly data structures, bi-directional interface definitions, orchestration, assemblies are to designing a Service Oriented Architecture (note that I use concepts not technologies, pick your favorite technology).

I would argue that all of the people that are so prompt to be offended by my posts will never answer these questions, they will never drive the discussion to answer these two questions.

An Inter-Action oriented, Asynchronous, Peer-to-Peer programming is here to replace the CRUD-Oriented, Synchronous Client/Server programming model. This is only a matter of time.

The irony here is that MEST is a lot closer to an IAOAP2P than a COSC/S, but Jim does not see it.