OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Title: Re: [soa-rm] What is SOA (Really???)
<Quote>
IMO the TC is spit into two camps and many times the two contingents are
speaking past each other, enumerating their own view. 
</Quote>
 
And have been for some time:
 
http://lists.oasis-open.org/archives/soa-rm/200504/msg00247.html
(search on "polarized")

Joe
(snuck this in on my brother-in-law's PC while away)
 

From: Don Flinn [mailto:flinn@alum.mit.edu]
Sent: Fri 5/27/2005 9:36 AM
To: SOA-RM
Subject: Re: [soa-rm] What is SOA (Really???)

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
>
>
>
>
--
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]