[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] What is SOA (Really???)
I tend to think of compliance as having strict legal meaning. So in that sense, even if we have conformance statements, which I do not endorse, I don't think we can expect or ask for compliance per se. However, we may want to list a set of factors or components which denote alignment with or which can be said to take the reference model as the model being used in applications or services. Ciao, Rex At 11:54 AM -0700 5/27/05, Duane Nickull wrote: >In order to facilitate such, we should at least ensure we have the >same views on the semantics. > >Reference Model >A structure which allows the modules and interfaces of a system to >be described in a consistent manner. > >Conform: >be similar, be in line with > >Compliant: >Hardware and software capable of satisfying a particular >requirement, such as manipulation of four-digit dates, is deemed >''compliant.'' > > >I think I understand what you mean, just want to make sure we are in >agreeance on these terms. As Matt has stated, the degree of which >one could conform to an abstract model can not be as strict as >conforming or complying with other specifications. > >Comments from others?? > >Duane > > >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 >>> -- 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]