OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm] Service Contract


I understand what you are saying.

My concern is that when people see metadata expressed using UML, they will 
then proceed to use UML for the rest of the analysis.

I also fully agree that the RM should not constrain ones choice. I only 
picked SOAD because it illustrated the limits of UML for understanding 
service orientation.

I also share your concern about being careful about what we mean with the 
term loose-coupling.

Michael

At 04:52 AM 4/27/2005, George Ntinolazos wrote:
>The diagrams represent the abstract elements of the Service
>Contract(operations, data types/messages etc). They try to capture the
>metadata associated with Platform Independent contracts, to use an MDA term.
>
>
>The example model defines the abstract syntax and semantics for the service.
>It does not specify how the contract is realized; it can be
>mapped/transformed to a specification language like WSDL, Java or IDL. Based
>on the choice of a specification language one can achieve different levels
>of loose-coupling. (yet another subject is what do we mean by loose
>coupling: loose-coupling at technology, protocol, application, semantic
>level to name a few different types)
>
>How one identifies the services, the architectural layers etc is a
>development process question. IMHO, the RM should not attempt to constraint
>the choice here. IBM's SOAD might be one example. I would also point you to
>existing methodologies like Business Component Factory (Herzum, Sims),
>Convergent Architecture (Hubert) and UML Components (Cheesman, Daniels).
>Although these methodologies emphasize Component based provisioning, their
>specification (or analysis) steps focus on large grain software services
>that represent 'business elements' (a process, a resource, or an
>organization unit).
>
>Cheers
>
>George
>
>
>
>-----Original Message-----
>From: Michael Stiefel [mailto:development@reliablesoftware.com]
>Sent: 27 April 2005 02:12
>To: Don Flinn; George Ntinolazos
>Cc: 'SOA-RM'; 'Duane Nickull'
>Subject: Re: [soa-rm] Service Contract
>
>I agree with this.
>
>The limitations of object modelling for service orientation is the reason
>that IBM is trying to develop SOAD (Service Oriented Analysis and Design).
>Their initial paper on this concept
>(http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/)
>discusses how to group loosely coupled services on the basis of their
>related behavior and processes instead of the encapsulated behavior and
>data of tightly coupled business objects.
>
>Michael
>
>At 11:58 AM 4/26/2005, Don Flinn wrote:
> >George
> >
> >The diagrams in your attachment depict services and semantics in terms
> >of operations and parameters.  IMHO this is a carry over from the
> >original OO orientation of UML, which implies rigid, inflexible API
> >based services.  Such an approach goes against the spirit of SOA, which
> >IMO should be based on loosely coupled principals.   While one could
> >design an SOA based on rigid APIs, I for one would not do so.  I also
> >question whether the RM should encourage the API model.  I, personally,
> >would go further and discourage the API based approach in a Service
> >Oriented Architecture.
> >
> >Don
> >
> >IMHO this is the legacy from UML and does
> >
> >On Tue, 2005-04-26 at 12:52 +0100, George Ntinolazos wrote:
> > > Hi all
> > >
> > > Please find attached a document with notes re: Service Contracts
> > >
> > > Cheers
> > >
> > > George
> > >
> > > ___________________________________________
> > > George Ntinolazos BSc(Hons), MSc, MBCS
> > >
> > > Product Director
> > > Strata Software Ltd.
> > > Office: +44 (0)1483 422515
> > > Mobile: +44 (0)7966 652063
> > > www.stratasoftware.com
> > > Best Practice for Service-Oriented Architectures
> > >
> >--
> >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]