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

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

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