[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] SOA System
It is fair to say that there is a general consensus (within the IT community) that a standard SOA definition is required. If that is within the charter then great, I see doing this as a great opportunity. I would agree that changing the charter without extremely compelling reasons is senseless. Otherwise without a standard definition of SOA/SO/whatever, I see a large risk of wasting time on irrelevant efforts. On 5/19/05, Don Flinn <flinn@alum.mit.edu> wrote: > Duane > > IMO the TC including myself are convinced that an SOA is different from > previous distributed system, e.g. CORBA, OO, IBD, CBA etc. The question > that I was raising was: Are we abstracting away or ignoring those > qualities that make an SOA different from previous distributed systems? > (Note: I peeked ahead at some of your mail. There is no intent by > myself or anyone, I believe, to change the charter. It's what we signed > up to do and want to do to the best of our ability.) > > The core of my concern is that we have not delineated, or at least > agreed on, the essential qualities that make an SOA different from the > previous distributed models so that we can assure ourselves that our > reference model contains these essential qualities. Without including > an abstraction of these qualities we don't satisfy our requirement of > developing a reference model that architects can use to develop > architectural specifications for an *SOA*. > > Some self-promotion :-) I tried to approach this in Appendix B, in an > non-normative way. > > Don > > On Thu, 2005-05-19 at 19:46 -0700, Duane Nickull wrote: > > 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 > > > > > > > > > > > > -- > 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]