[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Groups - Rough notes taken during the last ebSOA meeting. (ebSOA-Elements.pdf) uploaded
I wonder if we should give more thought to our use of the term "Data Model" in the context of SOA. It seems that we might be using it here in a bit of a different sense than it is used apart from SOA. I believe that in the context of SOA we are speaking of leveraging a data model for input/output usage, which implies some sort of messaging model (using this term loosely - I know that "messaging" has been a subject of other threads). I would assert that given a data model, there can be multiple such messaging models based on that data model, and even multiple messages defined within a messaging model that leverage the same data model. So perhaps we might think of another term to describe this rather than overloading the term "data model", as I believe a data model can exist separately from any attempt to base messages on that model. Kind Regards, Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Monday, March 28, 2005 5:37 PM > Cc: soa-rm@lists.oasis-open.org > 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]