[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:[email protected]]
> Sent: Monday, March 28, 2005 5:37 PM
> Cc: [email protected]
> 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]