RE: [soa-rm] Service Contract

["George Ntinolazos" <georgios.ntinolazos@stratasoftware.com>]

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