[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Reference Model References (Was RE: [soa-rm] Groups - Rough notes taken during the last ebSOA meeting.(ebSOA-Elements.pdf) uploaded)
> It would be helpful if we had abstract reference model > documents of existing architectures in order to answer this > question and to fully explain what distinguishes SOA. Here are 2 that come to mind (note that #1 below is intended to be a SOA RM, according to its description): (1) http://xml.coverpages.org/ni2005-03-25-a.html Announced 03/25/05: "The Commonwealth of Massachusetts has released a review draft Version 3.0 for its Enterprise Technical Reference Model (ETRM). The six-part document introduces Disciplines, Technology Areas, and Technology Specifications for the Information, Application, Integration and Security Domains. The ETRM calls for the development of a SOA model built around interoperable XML specifications, including the adoption of open formats, defined as necessarily "royalty-free."" (2) SCORM: http://xml.coverpages.org/scorm.html Kind Regards, Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Thomas Erl [mailto:terl@serviceorientation.org] > Sent: Tuesday, March 29, 2005 1:39 AM > To: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Groups - Rough notes taken during the > last ebSOA meeting.(ebSOA-Elements.pdf) uploaded > > > "is it sufficiently different from other existing architecture > > reference models to warrant existence as a concept?" > > It would be helpful if we had abstract reference model > documents of existing architectures in order to answer this > question and to fully explain what distinguishes SOA. > > Thomas > > ----- Original Message ----- > From: "Duane Nickull" <dnickull@adobe.com> > Cc: <soa-rm@lists.oasis-open.org> > Sent: Monday, March 28, 2005 2:36 PM > Subject: Re: [soa-rm] Groups - Rough notes taken during the last ebSOA > meeting.(ebSOA-Elements.pdf) uploaded > > > > Martin: > > > > IMO - SOA is potentially a specialization of a combination of many > > things - interface based design (IBD), component > architecture (CA), OO > > methodology etc. It seems to possess some elements of > these things. The > > questions we need to answer are "How can we describe it as > architecture?" > > and "is it sufficiently different from other existing architecture > > reference models to warrant existence as a concept?". If it is > > architecture, then surely it must be describable as architecture. > > > > My $0.02 worth: > > > > Services are core, but not sufficient by themselves to > represent a new > > class of architectural paradigm. What else is needed for > services to > > be bound to in a true P2P environment? Some way for the > services to > > be discoverable (Advertising) and some mechanism to describe all > > aspects of a service (Service Description) that would be > required in > > order to invoke the service. Additionally, knowing what > invoking the > > service meant > > (contract) and knowing the data that is passed in and optionally > > returns from a service invocation (Data Model) are all core. There > > are a lot of questions we need to answer around this > including whether > > or not semantics of the data model is an important aspect. > > > > What is outside the core definition? Messaging, Security, BPM, QoS > > and any other items that is probably present in most SOA's but not > > all. This may seem very controversial at first but follow > the logic. > > > > If I build something and that is "Service Oriented" > architecturally, > > does it have to have a "message"? No - the service itself has a > > mechanism that allows a service consumer to bind to it to > invoke the > > service but it doesn't actually have to be invoked for it to be > > "service oriented architecture". Does a car have to be > driven on a road before it is a car? > > The answer is likewise "no". An application only has to be > > architected to utilize the concepts surrounding a service > in order to > > be utilized by service consumers when it is implemented. The > > reference model therefore would not have a core messaging > component. > > Any architecture developed using the reference model will > likely have > > messaging as a component and over half will likely employ > some form of security. > > > > Summary: > > > > Following this core model, SOA is definable as architecture (as a > > reference model) and is sufficiently distinct to warrant > existence. > > It has a unique combination of components that work together to > > facilitate services being present, discoverable and invokable. > > > > Duane Nickull > > > > *********** > > Senior Standards Strategist - Adobe Systems, Inc. - > > http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - > > http://www.unece.org/cefact/ Adobe Enterprise Developer > Resources - > > http://www.adobe.com/enterprise/developer/main.html > > *********** > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]