RE: [soa-rm] Groups - Rough notes taken during the last ebSOA meeting. (ebSOA-Elements.pdf) uploaded

["Metz Rebekah" <metz_rebekah@bah.com>]

All - 

I have another 25 messages to go before I catch up with all the traffic
on the list, so I apologize if my comments are already outdated.  I am
currently trying to synthesize the mailing list discussions re:
definitions, audience and goals into some documents that we can begin to
chew on.  I hope to have a initial (read *very rough*) cut of those out
later today.

Respecting the service description, contract, and data model from
Duane's message - does you think that "all aspects of the service"
encompasses the service interface and the policy?  I like the use of the
term service contract, but have seen several interpretations of the term
ranging from semantics ("what is meant") to syntax (vis a vis the WSDL)
and also that the WSDL is the data model is the contract.  I would argue
that the contract is the same as the data model.  However, I'd have to
think a bit more to provide a convincing argument rather than simply
positing an idea.

Continuing into the message, I would disagree with the following:
> 
> 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".  

I would argue that conceptually, a message exists.  The mechanism by
which the consumer binds to the service and invokes it constitutes the
message.  Messaging is typically central to the definition of
distributed computing, i.e. entities communicate with one another
through the exchange of messages.  How is that different than something
like IPC or shared memory registers?  I guess one could argue either
way, but I see the dividing line rests on the idea of implicitly shared
state.  If you have to exchange or synchronize state information, you're
heading into the conceptual realm of exchanging messages.  What is
really interesting here is whether or not a SOA is inherently a
distributed architecture or not.  If not, what is the distinguishing
characteristic of a SOA?  I've seen some of the discussion regarding the
central role of service and have not yet fully digested that...

I'm continuing through the recent discussion, but I wanted to get some
initial thoughts out to everyone to stretch my thinking and
understanding.

Rebekah 

> -----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
> ***********
> 
>