[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]