An Abstract SOA Reference Model

RSS It All — Fri, 13 Apr 2007 03:34:02 GMT

A fluffy draft on a fluffy topic - feedback and flames encouraged... ---- While a well planned and executed

SOA Reference model

Jesus Rodriguez's WebLog — Fri, 13 Apr 2007 05:29:51 GMT

My friend John Evdemon has been writing about the different components of a SOA Reference model. Check

re: An Abstract SOA Reference Model

ehoff — Fri, 20 Apr 2007 08:10:39 GMT

Being an intro, I expected this to be short of details. I think, however, a few topics should at least be mentioned (if not introduced) in the beginning.

First, I saw several places in your post reference "web services." I assume this corresponds directly with SOAP over HTTP/HTTPS. Does this mean you would exclude SOAP over MSMQ (or any other protocol) as a SOA communication mechanism? Clarification of this would be good.

I think the following paragraph could probably make a decent book when explained:

"While the architectures described within Expose / Compose / Consume may be interdependent, they are designed to be loosely coupled. This enables services to be managed, versioned and configured independently of how they are exposed"

Versioning, location independence, eventing, and scalability are a few of my core concerns at work right now in regards to our current Web Service architecture.

I also love to see you address the topic of passive vs active services. In terms of reuse, do you envision building many small services which can be composed into larger services? How do you deal with chattiness and semantic dissonance between services.

The topic of RPC vs Message integration is another huge concern (both are possible with Webservices, but most people do RPC without realizing the difference).

Would you define an enterprise data model for your services (the one customer format to rule them all)? If so, how do you deal with data stuffing when one application does not know all the fields of the enterprise data model.

Transactions are another huge topic. Do you forsee the use of cross-service transactions in this reference model? How will you deal with high-traffic applications and the locking issues that will entail?

Will your reference model allow for any type of eventing model?

Finally, how do you test and monitor the ecosystem to ensure the business SLA's are met (and issues are identified quickly).

I don't expect you to address many of these items in your "introduction," but maybe a few key points would be helpful to see what direction you are taking your SOA reference model (at which point I could give more directed questions/feedback).

re: An Abstract SOA Reference Model

Frank Krasicki — Fri, 20 Apr 2007 22:25:39 GMT

John,

Your first paragraph is full of assertions that are dubious. SOA, IMO, is not about responsiveness but about extending the object-oriented paradigm to include enterprise policy and business rule capabilities. And SOA initiatives are in such infant states that to pronounce that any have failed misses the scope and dedication that will be required to see a true project through.

I'm guessing that a few misguided and misunderstood attempts at building SOA prototypes have failed,that much may be true.

By introducing top-down and bottom-up development contentions, again you miss the point because you miss the scope. SOA is about enterprise wide service capabilities. That means multiple lines of business are affected. SOA cannot be driven by a single line of business unless that business is the enterprise itself.

Therefore, top-down and bottom-up strategies except in the case cited are doomed to misrepresent whatever their final by-product comes out to be. The mission accomplished will turn out to be SOA-coated business as usual. This is already happening in the financial services industry. Old habits are hard to break.

The monumental challenge of SOA is to disengage industries who have been politically married to exclusive vendors by last generation's bureaucracy to realize the ability to decouple from those staggering legacy dependencies. In other words, the client developers need to ween themselves from needing to care where the data comes from.

SOA also means data is no longer repository dependent. Data exists in time in motion. Services deliver what's on the wire, not what's in a location.

SOA is about business context in motion as well. That's why businesses who think you just need BA's running around gathering opinions about GUI designs will fail.

Client targets will be chameleons to the business of the moment, the business on the wire. SOA empowers that, it doesn't conform to stagnant templates. And SOA empowers collaborate, spontaneous business. End-users can't be pumpkins, they have to know something.

Your arguments are otherwise interesting and I'll think about them.

Frank Krasicki

re: An Abstract SOA Reference Model

Duane Nickull — Sun, 22 Apr 2007 18:06:29 GMT

If it is meant to be truly abstract, there should be no specific technologies or protocols, cardinalities or specializations of components. From the graphic above, this effort fails dismally on all counts.

Data, legacy, packaged app, etc. are all specializations of somethings. In the OASIS SOA RM, this was referred to as capabilities. An abstract architectural artifact should not be specializing one artifact in many ways.

Is security something that is really there in SOA? The concept is really a policy. A policy can be a security policy but the security policy can also be that there is no security.

Sorry - but this fails the litmus test for me. Why not just use http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

as the basis for this work and make changes where you think there need to be changes. The OASIS work was never intended to the "the" (ie - singular) RM for SOA, just "one" RM. You may easily use it to point out differences where your SOA disagrees with the RM. That is the purpose.

Duane Nickull

re: An Abstract SOA Reference Model

Rishi — Mon, 23 Apr 2007 01:11:14 GMT

Some practical considerations that should be addressed:

- Stand against fine grained v/s coarse grained services?

- Handling of services dependencies?

- Handling of reference data across autonomous services (eg. customer's industry in relation to a customer entity)?

- Handling of data integrity across autonomous services (eg. customer reference in say Order Proccess Service)?

- SOA with (or in the face of) ADO-ERD,DLINQ, LINQ??

- EDA (Event Driven Architecture) with SOA?

- Loosely Coupled Integration of Services? Consideration for Enterprise Service Bus (ESB) therein?

- Exposing of Database as Services, and applicability of CRUDy Services (See MS CRM 3.0 Web Service)?

When can we expect the final document? And lastly, perhaps you should consider following it up a real-world code sample - walk the talk?

Good Luck..

re: An Abstract SOA Reference Model

Duane Nickull — Mon, 23 Apr 2007 05:45:13 GMT

Look - an RM has been done. What would really be helpful is a reference architecture to map the RM to WS-*. Rishi's comments above are very relevant to a lot of people. Making another abstract model is not going to help much. Making a reference architecture that maps the RM to WS-* will be very useful.

The RA team is meeting in San Diego this week to work on a first draft of an RA based on the last 9 months of their work on their Wiki. It would be great to get great minds like John's behind this work (or helping steer it).

Duane

re: An Abstract SOA Reference Model

Rashed Iqbal — Tue, 24 Apr 2007 01:00:21 GMT

John,

This is a great topic to get addressed but as such your fluffy draft does not have much content:

- Building systems (no matter SOA based or not) requires addressing strategic needs of the organization involved. This is really nothing new. We know this for eternity. Corollary: What Microsoft advocates as per your introduction is nothing new. You can use Microsoft tools and technologies (or for that matter any other stack) to build great or clumsy systems depending upon taking a good or bad approach.

- I would be too careful to say that the graphics of Fig. 6 represents any kind of reference model.

- What you have described apropos of Expose, Compose, and Consume are not architectures at all as you have claimed. Just asserting something being an architecture normally does not render it so.

- You might not have wanted to sound it so but it feels that you want to run Expose, Compose, and Consume in a serial fashion which contradicts to your basic thesis that SOA projects should be driven by strategic business needs.

I am sure you shall come up with a great paper finally.

Kind Regards,

rashed_iqbal@ieee.org

Microsoft Abstract SOA Reference Model and SOI codenamed Alchemy

Dave Oliver's Blog — Fri, 04 May 2007 00:14:07 GMT

Microsoft Abstract SOA Reference Model and SOI codenamed Alchemy

Loosely Coupled Thinking : An Abstract SOA Reference Model

Dating — Sun, 01 Jun 2008 21:42:27 GMT

A fluffy draft on a fluffy topic - feedback and flames encouraged... ---- While a well planned and executed SOA undertaking can help organizations realize greater responsiveness in a changing marketplace, not all service-oriented efforts have been successful