[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] SOA System
That's a great book. I believe CORBA *is* a type of SOA. I believe that the basic difference between now and earlier versions of SOA is the presence and usage of the WWW. That changed everything. Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Christopher Bashioum [mailto:cbashioum@mitre.org] > Sent: Friday, May 20, 2005 9:10 AM > To: soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] SOA System > > Duane, > > I find this thread very interesting. I have been of the > opinion that one could implement an SOA using CORBA. In the > book "Understanding SOA with Web Services" but Eric Newcomer > and Greg Lomow - they mention the following: > "Many CORBA deployments are SOAs ..." Taken in context he is > discussing the difference between using CORBA vs. using Web > services to build SOAs - but it is very clear throughout this > book, and in other literature that many people consider CORBA > to be an early implementation of SOA. > > So ... I am not defending this position just yet - but I am > asking the question "how is CORBA not an SOA?" > > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Thursday, May 19, 2005 10:47 PM > Cc: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] SOA System > > Don: > > I am satisfied that SOA is different that CORBA, OO, IBD, CBA etc. > > It would have been very funny however if during our activity > we found it wasn't. I can see the news release now: > > "The OASIS SOA RM TC concluded that SOA is no different from > a bunch of other stuff and recommends everybody just stop > talking about it...." > > ;-) > > This TC was really Matt Mackenzie's brainchild. His thoughts were: > > 1. If SOA is architecture, as the name implies, how do we > define it as architecture? > 2. What is distinctive about SOA when compared to other architectures? > > While the first two hours were a bit scary, we did eventually > conclude that SOA is unique in it's core composition of elements. > > Duane > > Rex Brooks wrote: > > > What makes our reference model a SOA reference model? Services. > > > > Services are fairly specific kinds of objects that do > something. It is > > about as close to an actual verb as we get. We'd like it to be > > something useful, but that is in the eye or infrastructure of the > > beholder. I don't think we can actually stipulate that at > this level > > of abstraction. An SOA needs a Service and a Service > Consumer, in my > > opinion, to become an architecture, with a small a. A service by > > itself is more akin to sound of one hand clapping. > > > > While it may have a lot in common with CORBA, and other OO > constructs, > > I think that is pretty specific. > > > > For an SOA with capital A? Do we even want to consider > that? I thought > > we did at the start, but I don't now. > > > > Rex > > > > > > At 2:51 PM -0400 5/19/05, <McGregor.Wesley@tbs-sct.gc.ca> wrote: > > > >> Don, > >> > >> For my work, the policies, contracts, metadata and > semantics are the > >> key items I require to base a whole of government approach to SOA. > >> > >> Further to this is the governance aspect that, although not > >> considered here, is critical for an enterprise as large as the > >> Government of Canada. > >> > >> Wes > >> -----Original Message----- > >> From: Don Flinn [mailto:flinn@alum.mit.edu] > >> Sent: May 19, 2005 1:20 PM > >> To: SOA-RM > >> 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(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 > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]