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

[Ken Laskey <klaskey@mitre.org>]

Not meaning to beat an old horse but what are the capabilities  
exhibited by an SOA?  How do these differ from other architectures,  
i.e. why do we care about SOAs in the first place?  This should give us  
a hint about how a notional class hierarchy would look.

Ken

On Mar 29, 2005, at 12:12 PM, Frank McCabe wrote:

> It seems to me that service architectures should not be confused with  
> message oriented architecture. That is confusing the messenger with  
> the message :)
>
> I would suggest that the essence of service is task delegation: I  
> offer you a service means I offer to perform a task for you.
>
> Is that passing the semantic buck? No, because a task can be further  
> broken down to an action and an effect: the effect of performing the  
> action is often also the reason for invoking the service.
>
> In a public environment, the actions performed by service providers  
> are inherently *private*; but the effect is inherently *public*.
>
> Can you realize such a model using messages? Absolutely. One of the  
> interesting constraints that comes out of the Web services area is the  
> document-centric processing model. It seems not to be core/essential  
> to the concept of services; but does seem to facilitate scalability  
> and service composition. We might wish to go so far as to state that  
> all good SOAs are based on a document-centric model.
>
> Can you realize services in C/C++? Absolutely, although you might  
> loose some of the nice scalability properties of specs like SOAP.
>
> An aside: I explain the DCM (document centric model) to my bosses in  
> terms of old-fashioned purchase orders sent by snail mail: the letter  
> coming in to the office has to have everything needed to specify the  
> order. On the other hand, the letter is also a token that may be  
> passed between the different departments: the credit department might  
> mark the order letter as being OK from a customer credit PoV, and the  
> warehouse might mark it as being problematic because inventory for a  
> particular item is low, etc. By the time the order is shipped, that  
> original order letter may have become a folder and be full of pencil  
> marks.
>
> Frank
>
>
>
> On Mar 29, 2005, at 8:54 AM, Duane Nickull wrote:
>
>> Gregory:
>>
>> I would never dispute that a message is required during runtime in a  
>> concrete architecture, but still do not concur that it is a necessary  
>> part of the reference model.  If I build something and want to say it  
>> is "service oriented", it must have a service.  That service has a  
>> binding implicit by its existence.  The question we should probably  
>> answer is "if it is architected with X ( X is a placeholder for the  
>> elements of the reference model), is it service oriented"?   Our job  
>> should then be to figure out what X is.  If I am an application  
>> builder (not infrastructure), and I build one application and I want  
>> it to be service oriented, it should have an ability to receive a  
>> service invocation (probably via a message), but do I have to have a  
>> message present for me to state my application is built using service  
>> oriented architecture?
>>
>> In the coffee shop example, writing an architecture for a coffee shop  
>> that is oriented towards providing services makes it service  
>> oriented, even if no one has entered the coffee shop and started the  
>> dialog.  More comments inline:
>>
>> Gregory A. Kohring wrote:
>>
>>>
>>> I think you have your analogy a little bit confused here. It is not a
>>> question of whether a car has to be driven before it is called a car,
>>> but whether a car without wheels is called a car. It would seem to me
>>> that a service without "message" is not a service.
>>
>> The concept of service includes the ability to be bound to and  
>> invoked, but the message itself is an instance object doing such.   
>> The binding  capability is a core part of a service.  Perhaps we are  
>> stuck on semantics?
>>
>>>
>>> Go back to the coffee shop example. The service a coffee shop offers
>>> has a well defined  message exchange protocol which works the same  
>>> the
>>> world over. Basically it involves the consumer placing an order, the
>>> server  confirming the order, then the server requesting payment.
>>> This is a very generic message exchange protocol which has also been
>>> taken up by many online shops.
>>
>> But for the coffee shop architect to state "this coffee shop is  
>> service oriented WRT its architecture, does that conversation need to  
>> actually take place?  IMO - the answer is no.  It "offers" the well  
>> defined message exchange - this is akin to the binding IMO.
>>
>>> This is not the only possible protocol, you could demand a down
>>> payment before the consumer orders the service, in which case you
>>> probably want to rearrange your coffee shop so that people have to  
>>> pay
>>> before entering. (Or you make people put a down payment before
>>> browsing your online store.) Hence, the choice of protocol has an
>>> impact on how the service is designed.
>>
>> There are still services with bindings.  Even if no one enters the  
>> coffee shop, one could still assert the shops architecture is  
>> oriented towards services.
>>
>> Messaging protocols are definitely a part of any concrete SOA and  
>> messages need to be present at runtime.  I am not convinced that the  
>> concepts belong in a reference model however.
>>
>> Would like to hear other points of view on this.
>>
>> Duane
>>
>> --  
>> ***********
>> 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
>> ***********
>>
>
>
------------------------------------------------------------------------ 
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-883-7934
7515 Colshire Drive                        fax:        703-883-1379
McLean VA 22102-7508