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