[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] SOA System
Rex, Thanks - this helps. Would you be willing to help define a non-SOA type CORBA implementation in a little more detail, as well as an SOA one? We can then use these to test-drive the RM to make sure it "works" -----Original Message----- From: Rex Brooks [mailto:rexb@starbourne.com] Sent: Friday, May 20, 2005 4:47 PM To: Christopher Bashioum; soa-rm@lists.oasis-open.org Subject: RE: [soa-rm] SOA System I am catching up on threads since this morning, so I may end up skipping some later ones if I would be repeating myself. CORBA is not SOA when it isn't being used to process or deliver a service. Not all given CORBA implementations are SOA but any given CORBA implementation may be an SOA. Ciao, Rex At 9:09 AM -0400 5/20/05, Christopher Bashioum wrote: > 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 >> >> >> -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]