[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Reference Model References (Was RE: [soa-rm] Groups- Rough notes taken during the last ebSOA meeting.(ebSOA-Elements.pdf)uploaded)
Comments inline: At 7:25 AM -0500 3/31/05, Chiusano Joseph wrote: > > 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."" (1) is very useful when considered along with the Reference Model Examples Duane recently posted, for a direct comparison of "abstract" v. "concrete" where the Massachusetts example above demonstrates existing work in the production of a "concrete" specification or application while ITA Reference Model demonstrates a relatively short and concise demonstration of an "abstract" foundation and the RCS Reference Model demonstrates a more thorough, and in that sense a more domain-specific (Revision/Version Control) example of RM abstraction in the extent that it requires greater depth and specifically introduces one of several choices we will have to consider in regard to Architecture Description Languages (ADLs) beyond others such as OWL versions and UML modeling techniques, but those are other threads. > >(2) SCORM: http://xml.coverpages.org/scorm.html (2) is also useful as another domain-specific RM, in this case a significantly narrow, content-specific domain RM (Shareable Courseware). >Kind Regards, >Joseph Chiusano >Booz Allen Hamilton >Visit us online@ http://www.boozallen.com Ciao, Rex > > >> -----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 >> > *********** >> > >> >> >> -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]