Share via

Comments on JohnCJ's comments of 3/26/04

  • Article

One of the blog comments I received was:

re: More Discussion of SOA is like the Night Sky... 3/26/2004 5:03 PM John Cavnar-Johnson

 

Re: https://blogs.msdn.com/pathelland/archive/2004/03/22/94000.aspx#97068 

This was a really cool discussion that I thought was insightful. I wanted to make a special blog entry with some summary points (mostly reiterating JohnCJ’s which align a LOT with what I believe). Thanks, JohnCJ!!

----

I agree that everything we talk about in SOA could have been implemented in existing apps by talented people… it’s just really hard! SOA is about teaching these principles and trying to redefine what a successful app is. I believe that the more people understand these principles the easier it is to build successful applications.

I agree with JohnCJ that SOA is really capturing something different than OO and relational models. I believe that it is complementary to both of them and that we need all three. I speak about this in my presentation on “Thoughts on Data and Messaging in a Service Oriented Architecture”. This is not yet easily available on the web but I am working on getting it available soon. When I succeed, I will blog how to get it. I find it interesting to see how the various communities have their own perspective: the OO folks tend not to think much about durable data and the SQL folks think all apps consist of “UPDATE WHERE”.

I absolutely LOVE JohnCJ points out that OO works great for simulation software and GUIs but when building a reporting app you need relational. What we need a more consistent expression of is how to unify all these pieces into a real enterprise application. I hope that we can capture all of these pieces under the rubric of SOA.

JohnCJ does a great job in describing how we transition from a small company to a large company by injecting organization and forms to make the subgroups work together. He also does a great job describing that we don’t care how the other department is implemented. This is a GREAT model for SOA. I love to talk about composite services which look just like a service from the outside but are internally implemented as a set of services. This is analogous to the big company and small company example JohnCJ gives.

One of the most insightful comments that JohnCJ made was about the need to define business documents that have a life of their own separated from their service. I am fascinated by this world between the services and the semantics of data in that environment. He (correctly) points out that documents must have an identity different from the schema for the corresponding data inside of a service. This gets even more interesting when there are multiple services handling the message. As he points out, we can’t let these actions be buried in a web method call or SOAP header. I like to say that these documents represent VERBS not NOUNS. He is correct that these documents sent between services ARE authoritative data. I love it!!!

This whole discussion about the semantics of data INSIDE versus OUTSIDE of a service is one that I am keenly interested in. I will be getting more stuff posted on this soon…

Love,

Pat

Comments

  • Anonymous
    April 07, 2004
    Most of my concerns and questions have been answered by this interesting and insightful discussion. Thanks a lot to all.

    The one issue, which I'm still pondering on, is about transaction boundaries and optimistic locking. I think John got a point, that data consistency is essential to every system. I also like JohnC's idea of a business document. This seems to be the best way, model respectively, of transmitting data between services or services and other clients.

    In my and Pat's opinion the CRUD kind of optimistic concurrency does not apply to SOA. SOA is about integrating systems in a heterogenous environment. Each service within this network may be implemented and backed by totally different approaches and data storages. Although related issues have been addressed by distributed transactions, they do not play well with the SOA paradigm. As Pat pointed out, SOA is about trust or mistrust and loose coupling. Unrelated companies, which communicate by services, will never agree on a tight coupling such as two-phase commits or distributed transactions in general. Nor will there ever be a real chance of relying on services offered by UDDI , which also demands a lot of trust, by the way. Therefore "physical" or CRUD optimistic locking and transactions have to be replaced by "logical" ... transactions.

    One possible solution is to store the original data and changes to these data within the business document (or maybe the original and the current data). Thus, each system, which is involved in a transaction, could check their current view of the data (their glimpse of the night sky) against the original data and decide, if any concurrency issues have been arisen. Logical transaction could be handled likewise. This would also enforce the idea of business documents having a life of their own separated from their services.

    Such an approach may demand a lot of proprietary coding. Maybe a common solution will emerge one day. Whatever the case, these issues are crucial to the service approach and have to be addressed in the future.

    Hartmut