[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] SOA System
<Quote> 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? </Quote> +1. Given even a clear sense of the role, value, and characteristics of reference models, I have had the same concern from the get go in our effort. I worry that what we are producing is *so* simplistic and *so* basic and *so* abstract that there will be little or no value realized in implementing it. A not-exactly-perfect analogy might be having 2 people that each speak a different language (say French and English), and one is tasked with enabling them to understand each other. And so instead of bringing in a human translator, the person looks at both of the people and observes the following: - Hmmm...you both have 2 eyes; - You both have one nose; - You both have 2 ears; So you must be able to understand each other! Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Don Flinn [mailto:flinn@alum.mit.edu] > Sent: Thursday, May 19, 2005 5:31 PM > To: Francis McCabe > Cc: SOA-RM > Subject: Re: [soa-rm] SOA System > > 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]