RE: [soa-rm] SOA System

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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

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