[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram
Duane: I believe Appendix B already discusses multiple services in the Intermediate and Complex SOA Scenarios. Michael At 07:42 PM 5/18/2005, Duane Nickull wrote: >Michael: > >Concur. I think we all agree that a reference architecture (or two) is a >logical next step. > >For the RM however, if I have only one service, is it not SOA yet if I >have two of them it is SOA? That is the key question we have to answer >for the RM. > >Perhaps a way to facilitate the usefulness of the RM is to illustrate this >concept as part of appendix B. > >Duane > >Christopher Bashioum wrote: > >>Well said - I agree >> >>-----Original Message----- >>From: Michael Stiefel [mailto:development@reliablesoftware.com] Sent: >>Wednesday, May 18, 2005 3:02 PM >>To: soa-rm@lists.oasis-open.org >>Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram >> >>I agree that " The essence of a SOA is multiple services coming together >>to satisfy a set of needs." >> >>I believe that to be useful to our audience we need to discuss how >>multiple services work together. Even if there is just one service, that >>service has to be designed in a certain way if it is to potentially >>participate in a SOA. Another way of looking at it is that one service >>is just the degenerate case. >> >>It seems to me what we are working on right now is a Service Orientation >>Reference Model which is the necessary first step. You can call the next >>step a SOA Reference Model, or a SOA Reference Architecture, but without >>that next step I do not think we will produce something that will be of >>lasting value to the larger community. >> >>I do not see how discussing how services can be connected together is any >>more concrete that discussing the nature of a single service. Abstraction >>is always relative to the level of discourse. >> >>Take the ISO stack as an example, the idea of connection is implicit in >>the abstraction. The whole point is to describe how two layers in the >>stack in different processes in different systems can communicate without >>having to understand the lower level protocols. The reason the >>communication is not shown (although I have seen pictures of it with the >>communications shown as in Tannenbaum's Computer Networks) is because the >>abstraction being shown is how the protocols are organized in one of the >>processes. If that is the level of discourse, there is no need to show a >>connection. >> >>Incidentally, I too do not like the use of the word architecture in the >>term SOA. Maybe we should propose what the SOAP 1.2 specification did and >>make the acronym the name. >> >>Michael >> >> >>At 02:06 PM 5/18/2005, Duane Nickull wrote: >> >> >> >> >>>Ken Laskey wrote: >>> >>> >>> >>>>The essence of a SOA is multiple services coming together to satisfy a >>>>set of needs. >>>> >>>This is the core point we have not reached consensus on yet. This is a >>>well worded as can be so I would like to use this assertion as a basis >>>for the discussion. >>> >>>Thoughts: >>> >>>I would agree that "The essence of a SOA infrastructure is multiple >>>services coming together to satisfy a set of needs. I do have >>>reservations about the concept of multiplicity of services being used as >>>a key metric to define SOA. >>> >>>Questions: >>>1. Is it necessary that there be more than one service in order that SOA >>>be SOA? 2. If yes to #1, is it necessary to call services only in sequence? >>> >>>My gut feeling is that having multiple services is probably a given for >>>any specific implementation of SOA, however it is not a requirements for >>>something to be service oriented. If I architect one application and >>>build it with a single service, service description, policy set, (+ >>>whateverElseGetsInTheReferenceModel), is that service oriented >>>architecture? I think yes. >>> >>>I would fully support a reference architecture depicting multiple >>>services being used either sequentially or in parallel, however think >>>that is a sub project best left for a dedicated sub committee. >>> >>>Duane >>> >>> >> >> >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]