[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] SOA System
<Quote> A model that anything can map to may not be very meaningful. </Quote> +1. This is the exact point I made as well in a posting I sent a few minutes ago regarding my concern that what we are creating is so (and too) basic. Kind Regards, Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Smith, Martin [mailto:Martin.Smith@DHS.GOV] > Sent: Thursday, May 19, 2005 6:15 PM > To: Francis McCabe; Don Flinn > Cc: SOA-RM > 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]