<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:]
> Sent: Tuesday, March 29, 2005 12:13 PM
> To: Duane Nickull;
> 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
> > ***********
> >
>
>
