[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] SOA System
At 9:35 PM -0400 5/19/05, Chiusano Joseph wrote: > > -----Original Message----- >> From: Rex Brooks [mailto:rexb@starbourne.com] >> Sent: Thursday, May 19, 2005 4:12 PM >> To: McGregor.Wesley@tbs-sct.gc.ca; flinn@alum.mit.edu; >> soa-rm@lists.oasis-open.org >> Subject: RE: [soa-rm] SOA System >> > > What makes our reference model a SOA reference model? Services. Understood and agreed (and agreed below as well). I should have qualified that statement better. SOA has a more narrow focus: Services. I'm hoping we can find a useful way to narrow it down to that. And I would also like to add, it seeks the minimum or lightest-weight coupling between Service and Service Consumer as possible for a given circumstance, but that is just my personal preference. Ciao, Rex >"CORBA services": > >http://www.google.com/url?sa=U&start=1&q=http://www.omg.org/technology/d >ocuments/corbaservices_spec_catalog.htm&e=9707 >http://www.google.com/url?sa=U&start=3&q=http://www.jguru.com/faq/view.j >sp%3FEID%3D1023&e=9707 >http://www.google.com/url?sa=U&start=4&q=http://www.unix.org.ua/orelly/j >ava-ent/jenut/ch11_01.htm&e=9707 >http://www.google.com/url?sa=U&start=10&q=http://bdn.borland.com/corba/c >orbaservices/0,1418,10035,00.html&e=9707 >http://www.google.com/url?sa=U&start=9&q=http://www.cs.wustl.edu/~schmid >t/ACE_wrappers/TAO/docs/orbsvcs.html&e=9707 >http://www.google.com/url?sa=U&start=7&q=http://www.prismtechnologies.co >m/&e=9707 >http://www.google.com/url?sa=U&start=11&q=http://www.javaolympus.com/J2S >E/NETWORKING/CORBA/CORBAServices.jsp&e=9707 >http://www.google.com/url?sa=U&start=15&q=http://linuxfinances.info/info >/corbaservices.html&e=9707 >http://www.google.com/url?sa=U&start=19&q=http://www.redhat.com/docs/man >uals/rhaps/jonas-guide/s1-jon-corba.html&e=9707 >....and on and on... > >> 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. > >Yes! This is why one of my submitted issues suggested that "Service >Consumer" and "Service Provider" be added as components in our RM - i.e. >added to Figure 2-1. > >> A service by itself >> is more akin to sound of one hand clapping. > >+1. I believe it (what you describe just above) is "service >orientation", not "SOA". > >> 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. > >I still am 100% confident our TC is divided on the issues of "what are >we trying to represent?" and "what should we be representing?". I >mentioned this on April 12[1], and it appears to have gotten worse >instead of better since then.... > >[1] http://lists.oasis-open.org/archives/soa-rm/200504/msg00247.html > >Joe > >Kind Regards, >Joseph Chiusano >Booz Allen Hamilton >Visit us online@ http://www.boozallen.com > >> 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 >> -- 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]