[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Groups - Rough notes taken during the last ebSOA meeting. (ebSOA-Elements.pdf) uploaded
<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 > > *********** > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]