Jaa

Service Oriented Architecture Conceptual Model

  • Artikkeli

Almost two years ago, I described some of the key concepts of service oriented architecture, including the distinction between a canonical model and a canonical message schema.  Since that time, I worked on a wide array of models, including Microsoft IT’s Common Conceptual Model.  That model (CCM for short) is the metamodel for IT concepts in Enterprise Architecture.

I received a note recently about that old post, and how valuable it was to the reader.  It occurred to me that those concepts were part of our Common Conceptual Model, and that a “SOA-Specific View” of the metamodel may prove interesting.  It was. 

I’ve attached the SOA view of our Common Conceptual Model for this post.

SV - SOA Concepts

A quick set of notes on my conceptual models.  

  1. Two terms separated by a slash (Application / Installable Software) are distinct terms for the same concept. 
  2. The associations are all “arrows with verbs”.  Read the associations along the direction of the arrow.  (e.g. “Application Component implements a Shared Service”).  I intentionally avoided using UML notations like “Composition” and “Aggregation” because they are difficult for non-technical people to read.
  3. Many verbs on an arrow – The stakeholders couldn’t agree on which verb best described the relationship, so we used multiple distinct verbs. 
  4. In my prior post, I used the term “Canonical Schema.”  Our stakeholders preferred “Shared Message Data Contract.” 

 

The key relationships to notice in this model are the ones that may be the least expected ones: the connection between the obvious SOA concepts like “Contract” and “Canonical Entity” and the not-so-obvious SOA concepts, like Business Process and Business Event. 

When SOA is done well, it is part of a seamless ecosystem between the processes that people perform and the systems that support them.  Being able to see the parts of the system and how they connect is key to understanding how to build a truly effective service oriented architecture.

Comments

  • Anonymous
    April 23, 2010
    Nick, We use similar meta-model. I have only two comments:
  1. I like the idea to model concept Capability explicitly (I saw this in SoaML). ServiceInterface is exposed Capability. It is great, because Capability and catalogue of capabilities are really important for change management (more important than ServiceInterface and service catalogue). Don't you need it?
  2. How do you generate service catalogue? Is it list of instances of meta-class ServiceInterface? What about bi-directional interfaces?
  3. Do you model Service? Or ServiceInterface is enough for you? Thanks

  • Anonymous
    April 24, 2010
    Nick, I am not quite sure why in 2010 people continue propagating ideas as flawed as this diagram can be. Though I am not surprised this the prevalent view of how Business Entities, Business Events, Business Services and Business Processes Relate @ Microsoft. So (again), I'd like to point to you that your diagram does not express the most fundamental behavior of information. Regardless of what work/activity is performed on an information entity, its lifecycle defines a series of operations (I.e. A contract) that correspond to the transitions from one state to another. An event being the occurrence of a state, has therefore a a direct relationship to a business entity, unlike what your diagram seems to imply. And all together, a process, is the mere observation of all the activities performed on business entities. In particular, the lifecycle of a business entity is independent of any process definition. Again, in 2010, I am not quite sure why "message" would be at the center such conceptual model. A message is just a technical artifact that conveys semantics such as event or intent to request a transition from one stare to another. As Udi, pointed out recently, confusion seems to be only constant at Microsoft in the SOA/BPM space.

  • Anonymous
    April 26, 2010
    Hi JJ, Long time, no see.  I always enjoy your comments. First off, as you know, my opinions do NOT represent the product groups in Microsoft.  None of our product group folks are consulted when I write a blog post! Secondly, I have literally two dozen views on the metamodel, with different entities in the "center."  The fact that this view happens to have the message entity in the center is because I chose this view to illustrate a point related to my prior post.  No single concept is more important than another from an EA standpoint.  Clearly, any single stakeholder will care more about some entities than another. Third, I make a point in my metamodels to avoid "transitive" relationships.  What that means is that any relationship that occurs in both "as-is" and "to-be" models takes priority, in the metamodel, over relationships that reflect only "to-be" thinking.  After all, the metamodel reflects how we will store both types of EA models.  You point out that the relationship between event and entity is indirect in the model, but that is a reality in "as-is" systems that we wish to improve.   The additional constraint that you suggest is a good one for consideration during architectural review, to insure that new systems are delivering against that practice.  It is, however, not a good one for a metamodel that represents both the good and the bad. I'm amazed at your references to 2010.  I believe that your frustration may come from the fact that you are intensely focused on modeling "Ideal State" architectural practices, while my focus is on the "Next State" architectural metamodel.  Different birds.   I welcome you to an offline discussion if you'd prefer.  Let's leave the invective off of the public forum, OK?

  • Anonymous
    April 26, 2010
    Hi Peter, I will follow up this post with another post that clarifies where I view Capability to fit in with Services.  I believe that there are two types of services: Business services (where a capability is offered to many different business units as a service) and SOA services (where information can pass into or out of an interface in a manner that minimizes coupling).   The confusion comes from the fact that both concepts use the term "services."   Based on your message, I believe that I will need to differentiate the two in order to provide a clear idea of what I mean. Follow-up post is coming soon.

  • Anonymous
    April 26, 2010
    Hi JJ... one more thing, We are using two different definitions of the term "Event."  I am using the definition preferred by both the BPMN and BPEL language standards, where an event occurs in the context of a business process. I have no doubt that there may be a different kind of temporal occurance that triggers changes in state for an entity.  You are free to refer to those occurances as "events."  Just understand that such a concept is NOT modeled in the view presented in this post. Abraham Lincoln is frequently quoted as saying: “How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn't make it a leg.” One word.  Two concepts.