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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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