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

[Matthew MacKenzie <mattm@adobe.com>]

Some QE on my message: Should be "...cannot be as rigid as some people 
on this list may be imagining."

Sorry, I'm hopped up on flu medicine.

-Matt

Matthew MacKenzie wrote:

> I think that you *can* be compliant with an abstract model, but that 
> the definition of compliancy cannot be as rigid as I imagine some 
> people on this list as imagining.
>
> When you deal in the abstract, there is no such thing as black & white 
> / cut & dried.
>
> -matt
> Chiusano Joseph wrote:
>
>> That is one single opinion - I would like to hear the opinion of 
>> others on this TC as well.
>> Joe
>>
>> ------------------------------------------------------------------------
>> *From:* Duane Nickull [mailto:dnickull@adobe.com]
>> *Sent:* Fri 5/27/2005 1:30 PM
>> *Cc:* soa-rm@lists.oasis-open.org
>> *Subject:* Re: [soa-rm] What is SOA (Really???)
>>
>> Joseph:
>>
>> How can someone be compliant with an abstract model? Did you mean
>> "conform" to? The latter means "in alignment with. To be compliant in
>> the software industry, you have to implement a set of specific
>> technology(s)..
>>
>> I think what you are really talking about is profiles, which belong in a
>> group that works with concrete specifications (WS-I is a good example).
>> That is where the real tests of inter-operability are done.
>>
>> It is nothing to do with a reference model.
>>
>> Duane
>>
>>
>>
>> Chiusano Joseph wrote:
>>
>> > Or let the industry comply with it at different levels (i.e. give them
>> > the choice). So we can have "OASIS SOA-RM Level 0 Compliance", "OASIS
>> > SOA-RM Level 1 Compliance", etc. 2 organizations that wish to
>> > interoperate using the OASIS SOA-RM can ask each other the question
>> > "what is the highest level of the OASIS SOA-RM at which you are
>> > compliant?".
>> > If the answer of Org1 is "I am compliant only at Level 0" while the
>> > answer of Org2 is "I am compliant at Level 1", then there is
>> > definitely some value in being compliant at a certain common level. If
>> > the answer of Org1 is "I am at Level 1" and the answer of Org2 is also
>> > "I am compliant at Level 1", then there is even more value, etc.
>> > Joe
>> >
>> > 
>> ------------------------------------------------------------------------
>> > *From:* Vikas Deolaliker [mailto:vikas@sonoasystems.com]
>> > *Sent:* Fri 5/27/2005 12:56 PM
>> > *To:* Chiusano Joseph; soa-rm@lists.oasis-open.org
>> > *Subject:* RE: [soa-rm] What is SOA (Really???)
>> >
>> >>“In fact, if we believe that we might be a microcosm of SOA
>> > understanding, then I would assert that it would be highly valuable
>> > for us to acknowledge that yes, >there are different understandings of
>> > SOA out there, and to contruct a reference model that both reflects
>> > reality and adds clarity at the same time. Our ability to >reflect the
>> > multi-layer thinking that is out there, and still be able to say -
>> > "this is what we believe SOA is" - would be (IMHO) the most valuable
>> > representation we >could offer.”
>> >
>> > +1 on above.
>> >
>> > To add my 2cents, we need to define a RM to leverage the creativity
>> > out there. Instead of saying “this is what is an SOA” the RM should
>> > answer the make the statement “This is what SOA can be” and let the
>> > industry do the rest.
>> >
>> > Vikas
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > *From:* Chiusano Joseph [mailto:chiusano_joseph@bah.com]
>> > *Sent:* Friday, May 27, 2005 8:49 AM
>> > *To:* soa-rm@lists.oasis-open.org
>> > *Subject:* RE: [soa-rm] What is SOA (Really???)
>> >
>> > We should all keep in mind that there is nothing that says a reference
>> > model has to be single-layer. So there is nothing precluding us from
>> > creating a reference model that has as its lowest level (call it Level
>> > 0) the notion of service orientation, with the next level up (Level 1)
>> > depicting multiple services, and the next level up (Level 2) perhaps
>> > introducing more complex service interactions, or perhaps security can
>> > be introduced at this level and the next level higher can introduce
>> > more complex service interactions, etc.
>> >
>> > Then, we can contruct a reference architecture for each layer, in a
>> > parallel fasion to the right. Each RA would extend the RA just beneath
>> > it, just as each RM extends the RM just beneath it. So we can have an
>> > "RM Stack" and an "RA Stack". Like so: (more text follows figure)
>> >
>> > RM RA
>> >
>> > ----------------- -----------------
>> >
>> > | Level 2 | -------> | Level 2 |
>> > ----------------- -----------------
>> >
>> > | Level 1 | -------> | Level 1 |
>> > ----------------- -----------------
>> >
>> > | Level 0 | -------> | Level 0 |
>> > ----------------- -----------------
>> >
>> > Then to the right of the RA Stack, one would put their concrete
>> > architectures.
>> >
>> > In fact, if we believe that we might be a microcosm of SOA
>> > understanding, then I would assert that it would be highly valuable
>> > for us to acknowledge that yes, there are different understandings of
>> > SOA out there, and to contruct a reference model that both reflects
>> > reality and adds clarity at the same time. Our ability to reflect the
>> > multi-layer thinking that is out there, and still be able to say -
>> > "this is what we believe SOA is" - would be (IMHO) the most valuable
>> > representation we could offer.
>> >
>> > Joe
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > *From:* Rex Brooks [mailto:rexb@starbourne.com]
>> > *Sent:* Fri 5/27/2005 11:09 AM
>> > *To:* Gregory A. Kohring; Don Flinn
>> > *Cc:* SOA-RM
>> > *Subject:* Re: [soa-rm] What is SOA (Really???)
>> >
>> > The most simple level, the atomic level, for me is one service and
>> > one service consumer. That also defines a community and it allows a
>> > full description of both service and service consumer, which together
>> > form the architecture. It is possible to model a service in
>> > isolation, but I would say that that case is not the one that
>> > interests us. It is not why we are here doing this. We are here to
>> > take the existing community and abstract it's most basic fundamental
>> > components in order to refine a reference model for SOA, As for who
>> > does the orienting, it is the community, which is well beyond clearly
>> > needing a model to guide future development of SOA which already
>> > exists in overabundance.
>> >
>> > By building the set of basic components that will allow the more
>> > complete set of features Ken described yesterday in response to what
>> > makes SOA different from Distributed AD, we are really just taking
>> > what already exists and abstracting from that, regardless of the fact
>> > that we are attempting a top-down modeling effort. To some extent, we
>> > are also missing the argument about whether or not a model-driven
>> > architecture is the best direction for organizing this effort going
>> > forward. I think it is, but our socratic methodology insists we
>> > answer the question of why is a MDA better than, say Agile
>> > Methodology or Extreme Programming where everything is a special case
>> > and ought to be built around the specific existing situation.
>> >
>> > Ciao,
>> > Rex
>> >
>> > At 4:30 PM +0200 5/27/05, Gregory A. Kohring wrote:
>> >>You have not quite captured the debate. It is not that I feel features
>> >>needed to make multiple services function are superfluous, it is just
>> >>that no one has ever clearly said what those features are.
>> >>
>> >>At the abstract level, what concepts do you think are required?
>> >>
>> >>
>> >>Take your community example and suppose its communication model is
>> >>the Internet. Would apply such a model to a village of 3 houses,
>> >>where people could just walk across the grass to talk with each
>> >>other? The concept of a community is obviously more fundamental
>> >>than such a communication model would allow, so do you need to mention
>> >>it all? While the communication model is important, in my opinion it
>> >>does not enter until you are ready to create a reference architecture
>> >>for a particular type of community.
>> >>
>> >>As I see it, that is the problem we face. How to make a reference
>> >>model simple enough that it applies to simple situations.
>> >>
>> >>
>> >>-- Greg
>> >>
>> >>
>> >>
>> >>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
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >>
>> >>--
>> >>======================================================================
>> >>G.A. Kohring
>> >>C&C Research Laboratories, NEC Europe Ltd.
>> >>======================================================================
>> >
>> >
>> > --
>> > Rex Brooks
>> > President, CEO
>> > Starbourne Communications Design
>> > GeoAddress: 1361-A Addison
>> > Berkeley, CA 94702
>> > Tel: 510-849-2309
>> >
>>
>
>