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

[Matthew MacKenzie <mattm@adobe.com>]

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
> >
>