[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] SOA System
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®-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*™, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]