[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
Adding to Duane's list below of concepts we might consider in our work - please note that I am simply presenting these "for the record" while they are fresh in my mind, not asking that they necessarily be discussed now (please excuse any overlap with things discussed so far): - Objects/Components (Duane mentions these below in another sense) - Composite Applications (think OASIS WS-CAF, WS-Transaction*, WS-Coordination) - Synchronous vs. Asynchronous communications - Orchestration - Choreography - Legacy Applications - Events (EDA - Event-Driven Architecture) Please note that I am not suggesting that these be components in our RM - just that thinking about them may/may not spark ideas of components. *segmented into WS-BA and WS-AT 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]