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

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

<Quote>
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.
</Quote>

This sounds very much like the model that OWL-S (Semantic Web Services)
is using, which is a good thing: IOPE, or
Input/Output/Preconditions/Effects. 

For example, if a book is purchased via a Web Service using a credit
card after having been discovered through browsing, we would have:

- Input: All of the obvious information (quantity, ISBN, purchaser
name/address, credit card #, etc.);

- Output: A confirmation of purchase (or error message as applicable);

- Preconditions: Credit card must be valid, book must be in stock, etc.

- Effects: Credit card is charged the amount, inventory of that book is
decreased by quantity purchased, etc.

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] 
> Sent: Tuesday, March 29, 2005 12:13 PM
> To: Duane Nickull; soa-rm@lists.oasis-open.org
> Cc: Gregory A. Kohring
> Subject: Re: [soa-rm] Groups - Rough notes taken during the 
> last ebSOA meeting. (ebSOA-Elements.pdf) uploaded
> 
> 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
> > ***********
> >
> 
>