[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] FW: [EA Advisor] OASIS SOA Reference Model
Joseph
Chiusano
Associate
Booz
| Allen |
______________________
O:
202-508-6514
C:
202-251-0731
Visit us online@ http://www.boozallen.com
"Finally, on to concrete details. There are none. This is just a set of concepts taken to a high level of abstraction."
A great verification that we have done our job and have created a reference model.
Joe
Joseph
Chiusano
Associate
Booz
| Allen |
______________________
O:
202-508-6514
C:
202-251-0731
Visit us online@ http://www.boozallen.com
FYI ... does anyone here know Mke Rosen? Might be worth discussing with him so he can better understand the model.
From: Cutter Consortium [mailto:webmaster@cutter.com]
Sent: Wednesday, November 01, 2006 7:10 AM
To: webmaster@cutter.com
Subject: [EA Advisor] OASIS SOA Reference Model
Welcome to the Enterprise Architecture E-Mail Advisor , a weekly electronic briefing from Cutter Consortium's Enterprise Architecture Advisory Service.
- Read today's Advisor online <http://www.cutter.com/architecture/fulltext/advisor/2006/ea061101.html> (Online Resource Center clients only)
- See what's new in Enterprise Architecture <http://www.cutter.com/architecture.html>
- Send Feedback <http://www.cutter.com/forms/feedback.html>
Cutter Consortium is your best source for objective advice on SOA
Don't miss this research and analysis on service-oriented architecture in the Enterprise Architecture Resource Center:
To upgrade your license to include to include access to any of these, contact Jack Wainwright <mailto:jwainwright@cutter.com?subject=Enterprise%20Architecture%20Resource%20Center> .
- Doing SOA Right Today: Resolving the Initiative Planning Challenges <http://www.cutter.com/architecture/fulltext/advisor/2006/ea061018.html>
- Service-Oriented Architecture: Awareness and Plans <http://www.cutter.com/architecture/fulltext/updates/2006/eau0618.html>
- Theory and Practice of SOA <http://www.cutter.com/architecture/fulltext/advisor/2006/ea060531.html>
- Service Orientation: The Cultural Dimension <http://www.cutter.com/alignment/fulltext/reports/2006/05/index.html>
- Service-Oriented Integration: A Report from the Trenches <http://www.cutter.com/architecture/fulltext/reports/2006/05/index.html>
- Service Orientation: The Architecture Dimension <http://www.cutter.com/architecture/fulltext/reports/2006/03/index.html>
- SOA: Concepts, Technology, and Design <http://www.cutter.com/architecture/fulltext/advisor/2005/ea051123.html>
Service-Oriented Architecture: Enabling the Service Organization <http://www.cutter.com/workshops/44.html>
Service-oriented architecture (SOA) is an architecture for creating an environment where business services can be independently developed and combined into higher-value business processes. This executive briefing focuses beyond the technology to explore how to achieve the goals of a service-oriented enterprise, the business implications of SOA, the required processes and the planning/strategy necessary, how SOA affects organizational structure; roll-out strategies and how to demonstrate its value. Learn more. <http://www.cutter.com/workshops/44.html>
BPM in Peril: Objects to the Rescue <http://www.cutter.com/bia/fulltext/reports/2006/06/index.html>
This Executive Report by Cutter Senior Consultant John Tibbetts <http://www.cutter.com/meet-our-experts/tibbettsj.html> examines how business process management (BPM) systems and the orchestration function of service-oriented architecture (SOA) are imperiled by the workflow implementation that they have inherited. This report introduces a fundamentally different approach to the process management endeavor and make the case for its superiority. Ultimately, what it proposes is not a different way of doing BPM, but rather a new way of structuring entire applications, one that will greatly improve BPM functions along with many others. Online Resource Center clients can access the report <http://www.cutter.com/bia/fulltext/reports/2006/06/index.html> directly. Purchase a copy. <http://www.cutter.com/cgi-bin/catalog/store.cgi?action=link&sku=RP68BD0606>
1 November 2006
OASIS SOA Reference Model
by Mike Rosen <http://www.cutter.com/meet-our-experts/rosenm.html> , Director, Cutter Consortium Enterprise Architecture Practice
In October, OASIS (Organization for the Advancement of Structured Information Systems) approved the Reference Model for Service Oriented Architecture V1.0 <http://www.oasis-open.org/specs/index.php#soa-rmv1.0> . A lot of people have been asking what it is, what to do with it, and how it will impact their SOA initiative. The reference model document itself states:
a reference model is an abstract framework for understanding significant relationships among the entities of some environment. It enables the development of specific reference or concrete architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms, and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details.That's certainly a mouthful, but let's pick out a few important words: abstract framework, unifying concepts, concrete details. The abstract framework is a set of concepts, definitions, and relationships. These are expressed as "concept maps," which are informal diagrams showing the concepts as ovals and the relationships as arrows between them. Then, the concepts and relationships are defined in text that follows the diagrams. I think this is my biggest problem with the reference model. Why did a standards organization choose to use a nonstandard way of representing these concepts? There are ISO standards (for example, the General Relationship Model) for addressing exactly this issue in a formal and precise manner. If nothing else, a reference model needs to be precise and I think the OASIS model fails in this aspect. However, I think the model gets it right in terms of the unifying concepts. At the highest level, the main concepts are: service, visibility, service description, execution context, real world effect, and contract and policy. A concept map lists the main concepts and more detailed maps introduce additional sets of concepts for each of the main concepts. At the top level, a service is a mechanism to enable access to a set of capabilities. The visibility determines the access, which is provided using a prescribed interface and is exercised consistent with contracts and policies as specified in the service description. A service is invoked within a specific execution context, which causes one or more real world effects to occur. The document is right upfront about its purpose. It is not an architecture, a set of patterns, or any kind of technology. It is a set of concepts that occur in most SOA architectures. So, if you are going to be creating an SOA, you should consider these concepts during that process and integrate the appropriate ones into your architecture. Or if you want to compare different architectures, the reference model provides a set of concepts, or a "common language" that allows them to be objectively compared. So here's another beef I have with the document. I know that the choice of terms is difficult, but it's important in a "common language." I just can't see "real world effect" as standing the test of time. But that is a minor complaint. Finally, on to concrete details. There are none. This is just a set of concepts taken to a high level of abstraction. A good set of concepts, but I think most people will not know what to do with this reference model, which will undoubtedly limit its usefulness. Additionally, I think the common language aspect of the reference model will start to fall apart as people go in different directions to get to the next level of detail. So I've answered the first two questions. What is it? It's a set of fundamental concepts that occur in SOA. What to do with it? Use the concepts to develop or refine your SOA architecture, to compare architectures, or as a basis for a common language to discuss SOA. And for the third question, how will it impact your SOA initiative? I'd say probably not very much. Unfortunately, I think that a very good set of concepts gets lost in the high level of abstraction and the informal, imprecise, and nonstandard presentation. It's really too bad, because it's an important problem that OASIS is trying to solve. You have to start somewhere, so I applaud OASIS for its initial efforts and look forward to a revised version of the reference model in the not-too-distant future. -- Mike Rosen <http://www.cutter.com/meet-our-experts/rosenm.html> , Director, Cutter Consortium Enterprise Architecture Practice
OASIS SOA Reference Model
To update your e-mail address with Cutter Consortium, reply to this message with your old and new address. Or phone +1 781 648 8700. If you do not wish to receive this email newsletter, unsubscribe here <http://www.cutter.com/forms/unsubscribe.html> . Did a colleague forward this Advisor to you? Sign up for your own free 4 week trial <http://www.cutter.com/forms/getEmailTrial.html> . Cutter Consortium | 37 Broadway, Suite 1, Arlington, MA 02474, USA. | Tel: +1 781 648 8700 | Fax: 781 648 1950 | www.cutter.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]