Re: [soa-rm] SOA System

[John Harby <jharby@gmail.com>]

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
> 
>