[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] SOA System
Guys - - I'm great with seeing what we can map to the SOA-RM, but it might be interesting & fun to see if we can agree that something does NOT map to it. A model that anything can map to may not be very meaningful. Martin -----Original Message----- From: Francis McCabe [mailto:fgm@fla.fujitsu.com] Sent: Thursday, May 19, 2005 5:43 PM To: Don Flinn Cc: SOA-RM Subject: Re: [soa-rm] SOA System Well, I wasn't aware that CORBA name servers had anything other than IDLs in them; but be that as it may ... Is there a problem in recasting CORBA as an SOA? Or casting SOA as distributed computing? There will be many factors that affect scalability in the design of an architecture. The service-orientedness is just one of those factors. To paraphrase an old maxim, there are few ways to be scalable and many ways to be fragile:) I.e., SOA is one property of an architecture - the focus on public interactions etc. etc. To model that we need descriptions, semantics etc. To build a high-class SOA, we will need to consider other things; and we will need to apply the SOA RM to the architecture. Clear as mud, I guess, as my 'ole pappy used to say. Frank On May 19, 2005, at 2:30 PM, Don Flinn wrote: > Hi Frank > > My point was not to discuss CORBA's problems or lack of such. (I was > one of the OMG/CORBA specification chairs during CORBA'S hay-days :-) > But to ask at what level of abstraction does our RM specify that which > makes it a reference model for an SOA. I know that an SOA is > different > from previous distributed models, but what qualities in our abstract > model do we discuss that makes it different from a specification of a > generic distributed model. > > You mentioned "the focus on the public description of things". Is > this > the only thing that makes an SOA different and what our reference > model > should discuss? Even there, again using poor old CORBA, at an > abstract > level the CORBA naming service is a public description of things. > > What I'm driving at and what we all are trying to grapple with is > where > on the abstract spectrum should we be. At one extreme, one enters the > world of metaphysics and the question become "What is the meaning of > life :-)" My question is simpler, maybe. Where on the abstract > spectrum > should we be to model an SOA as opposed to any distributed model? I > don't believe that we can produce a usable specification if the > model is > abstracted to such a high level that we are delivering a reference > model > for any distributed computing model. Specifically, what are the > abstract qualities that distinguish an SOA from a generic distributed > model? > > Don > > On Thu, 2005-05-19 at 10:57 -0700, Francis McCabe wrote: > >> And the problem is ... >> >> I think that CORBA's problems did not come at this level of >> abstraction, but in the low-level realization. E.g., IDL is C++ in a >> different syntax. It is rigid, and not capable of incorporating >> descriptions of policies, etc. >> >> SOA *is* different from random distributed computing, because of the >> focus on public descriptions of things. >> >> Frank >> >> >> On May 19, 2005, at 10:20 AM, Don Flinn wrote: >> >> >>> To All >>> >>> As we abstract and restrict our reference model, I begin to wonder >>> what >>> makes this reference model a SOA reference model as opposed to say a >>> CORBA reference model. CORBA had interfaces as one of its primary >>> constructs and had a specific language, IDL, to define the >>> interfaces. >>> The interfaces were the external front-end to Impls, which at our >>> level >>> of abstraction were the same as services and CORBA had the notion of >>> metadata. It also had a Discovery & Advertise entity, the naming >>> service. This comparison is not limited to CORBA, but could include >>> DCE, DCOM, J2EE, etc. to a greater or lesser extent. So my >>> question is; >>> At the level of abstraction that we are going, what makes our >>> reference >>> model a SOA reference model and not a generic distributed computing >>> model? If the answer is the latter, is this what the world is >>> expecting >>> from us? >>> >>> Don >>> >>> On Thu, 2005-05-19 at 09:10 -0700, Francis McCabe wrote: >>> >>> >>>> Matt, et. al. >>>> In case this thought has not been raised in future emails ... :) >>>> >>>> I believe that I am correct in stating that, in practice, the >>>> best >>>> aspects of languages like Java is not features such as inheritance >>>> but the ease with which applications can be slotted together. >>>> The key >>>> feature that enables this Lego(r)-style assembly is the >>>> *interface*. It >>>> turns out that interfaces make the task of programming large >>>> systems >>>> significantly easier. >>>> >>>> The logical development of the type-only interface is the >>>> *semantic* interface. But in any case, modern SOAs represent one >>>> aspect of the trend towards focusing on interfaces as a way of >>>> controlling complexity and enabling rapid development/deployment >>>> etc. >>>> >>>> So, at one level of abstraction, it may be useful to think of >>>> SOAs >>>> as a system of interfaces that allow architectures to be crossed, >>>> ownership domains to be crossed, different implementation languages >>>> to be used, different versions to coexists, etc. etc. >>>> >>>> Our task is to try to pick out the keystones that bear the SOA >>>> hallmark; which seem to me to be what we have: services as *action >>>> boundaries*(tm), semantic interfaces, tons of descriptions. >>>> >>>> Frank >>>> >>>> On May 18, 2005, at 7:22 PM, Matthew MacKenzie wrote: >>>> >>>> >>>> >>>>> Michael, >>>>> >>>>> On 18-May-05, at 5:55 PM, Michael Stiefel wrote: >>>>> >>>>> >>>>> >>>>>> Matt, re your comment that "SO is OO, basically, with some value- >>>>>> add infrastructure such as discovery and description." >>>>>> >>>>>> Now this raises an interesting point in our definition of service >>>>>> abstraction. Normally people cite as one of the differences >>>>>> between SO and OO the fact that the former is more loosely >>>>>> coupled. >>>>>> >>>>>> Would you maintain that OO systems that can work with wire >>>>>> formats >>>>>> of object systems (such as COM and CORBA) that allowed runtime >>>>>> dynamic binding of heterogenous systems fall into the SO >>>>>> category? >>>>>> >>>>>> >>>>> >>>>> I maintain that in certain situations that they *could* fall into >>>>> the SO category. I think that the "loosely coupled" argument is >>>>> sort of weak, because I am not completely certain that even things >>>>> like web services end up creating loosely coupled systems! >>>>> >>>>> >>>>> >>>>>> >>>>>> Or do you see looser coupling as a useful feature that is much >>>>>> more easily achieved with newer implementation technologies such >>>>>> as Web services, and therefore have nothing to do with SO. >>>>>> >>>>>> >>>>> >>>>> I love loose coupling...but yeah, I do just view it as "a good >>>>> thing", and not a necessary element of SOA. >>>>> >>>>> -matt >>>>> >>>>> >>>> >>>> >>>> >>>> >>> -- >>> Don Flinn >>> President, Flint Security LLC >>> Tel: 781-856-7230 >>> Fax: 781-631-7693 >>> e-mail: flinn@alum.mit.edu >>> http://flintsecurity.com >>> >>> >>> >> >> >> > -- > Don Flinn > President, Flint Security LLC > Tel: 781-856-7230 > Fax: 781-631-7693 > e-mail: flinn@alum.mit.edu > http://flintsecurity.com > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]