[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
Duane, This may be a chicken-and-egg question. Can we state that any indication of an SOA component should specify the purpose that it serve and the context in which that purpose is required? Ken On Apr 10, 2005, at 3:34 PM, Duane Nickull wrote: > Ken: > > I think that these are getting close to the questions we are asking. > > Sub questions of "What is SOA": > 1.What are the main components of SOA? > 2. How do we describe them in an abstract manner? > 3. What are the relationships amongst those components and their > externally visible properties as abstract things? > > The capabilities exhibited by SOA should be limited to the externally > visible properties of each component or the SOA RM as a whole, but in > described an abstract manner. > > The difference between SOA and other types or architecture is an > important question. What makes SOA unique? If it is not unique, has > the industry perhaps invented a new term for an existing thing? I > believe that the position papers and general perceptions of SOA are > that it is unique, but the questions 1-3 above arise out of that. > > Why we care about SOA's is a question that is probably left unanswered > in a RM. We should not impose that our views on why SOA is important > are omnipotent or even consensual. > > Duane > > Ken Laskey wrote: > >> 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 >> >> > > -- > *********** > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]