Re: [soa-rm] What is SOA (Really???)

[Duane Nickull <dnickull@adobe.com>]

I feel it is a bit worse that this depiction Don.  I think that if you 
pose one question, people run to different sides of the room, but on the 
next question, the divisions are different.

I suspect if we get detailed enough, we may have 98 definitions of SOA

;-)

We'll get there.

D

Don Flinn wrote:

>IMO the TC is spit into two camps and many times the two contingents are
>speaking past each other, enumerating their own view.  Rebekah's
>variation of the house analogy captured the difference: 
>
>A- One side looks at a Service Oriented Architecture from the viewpoint
>of the community whereas the architecture describes the houses
>(services) and their relationship to each other (coordination,
>choreography, etc.) and constructs their model from that viewpoint.
>B- The other side looks at a Service Oriented Architecture from the
>viewpoint of a single house (service) and constructs their model from
>that viewpoint.
>
>Until and unless each viewpoint addresses the concerns of the other
>viewpoint we will never reach consensus. One can not understand another
>until you walk a mile in their shoes.
>
>Following my suggestion, being of the (A) viewpoint, let me attempt an
>explanation of the (B) viewpoint.  B's contention is that the essence of
>what should be modeled is a service, where a service subsumes the
>service itself, Metadata and Discovery, Presence and Availability
>(Figure 1).  Once we have fully modeled a service, our customer, the
>specification writer, can develop a specification for any SOA
>architecture, including the complex scenario in Appendix B, by using the
>concepts of a single service multiple times, as needed.  Thus, features,
>which are exogenous to the service, that are needed to make multiple
>services function as a unit are superfluous to the model.  
>
>Does this capture the (B) view of what our RM should be?
>
>Could a (B) viewpointer summarize the (A) viewpoints?
>
>Don
>
>
>
>On Fri, 2005-05-27 at 11:41 +0200, Gregory A. Kohring wrote:
>  
>
>><quote>
>>Make an example of something that is not conformant to the SOA RM and
>>explain why.
>></quote>
>>
>>
>>One of the problems we are having in this respect is
>>generalizing from the wrong basis model. Or more to the point,
>>have we reached agreement upon what basis model SOA is generalizing
>>from?
>>
>>In my opinion, SOA RM generalizes Client-Server; whereby
>>the "client" is generalized to "consumer" and the "server" is
>>generalized to "service". (In this sense, SOA is a fundamental model
>>and we should try to keep it simple.)
>>
>>Seen from this viewpoint, we should ask what is the difference
>>between client and consumer, server and service and the relationship
>>between the respective pairs.
>>
>>A "client" has the server's description hard-wired. The policy,
>>contract, data model and processing model are all hard coded into both
>>the client and the server.
>>
>>A "consumer" on the other hand has some goal to achieve and must
>>first discover a service which can achieve this goal, understand
>>the service's policy and contract to see if the service's policy is
>>in alignment with its own policy and constraints, examine the
>>processing model to determine whether a session needs to be
>>established before the request can be submitted and examine the
>>data model to determine what format is needed for the input data;
>>only then can the consumer submit a request to the service.
>>
>>If you accept this scenario (which I know is a big "IF" ;-), then
>>an example of something which is Client-Server, but not SOA is
>>FTP.  With FTP the policy (username-password authentication),
>>contract (list of allowed commands), data model (byte order of the
>>ftp packet) and processing model (control channel, data channel)
>>are all hard-coded in both the client and the server, there is no room
>>for dynamic inspection and negotiation.
>>
>>In my opinion, it is this inflexibility which forms the main
>>demarcation between the Client-Server model and the SOA model.
>>
>>
>>-- Greg
>>
>>
>>
>>
>>    
>>