Re: [soa-rm-ra] Groups - Modification of Policy_Contract_Business diagram (OASIS_Policy-Contract_Diagram.JPG) uploaded

[Danny Thornton <danny_thornton2@yahoo.com>]

To 2, the SOA RA Service Description model is not Web
Service/WSDL driven.  It is a model of information
that is useful for describing distributed capabilities
in an SOA.

To 4, In one sentence you say

> in my interpretation Service Contract does
> not equal Service Description or Service Interface
> as well.

and in another sentence you say

> It is interesting point: it is also true that
> service interfaces may
> not be part of a service contract. How a service
> might be engaged other than via its interface? 

Your assertion is that a service interface is not a
contract but must be referenced from a contract for an
SOA.  A counter example to this is all the web
services out there with the one contractual obligation
of use at your own risk.  The OASIS SOA RA Service
Description has a good resting spot for capturing
contractual obligations.  You could mix up the Service
Description model in many ways to capture the general
information useful for distrubuted capabilities in an
SOA. However, the Service Description is based on the
OASIS SOA RM and there has been a lot of thought by
several IT professionals for extending and organizing
the Service Description information the way that it
has been organized.  The Service Description will
undergo some changes over the next few months, but I
think we've captured  major pieces and relationships
at this point in time.

We seem to all be in agreement about SLAs.

Danny

--- michael.poulin@uk.fid-intl.com wrote:

> Danny,
> I am glad we are getting closer and closer to each
> other understanding. Here a few responses to your
> comments.
> 
> To 1. Frank said A service has one  
> interface that includes all the actions that you may
> perform against  
> the service and also includes any behavioral models
> associated with  
> those actions (a.k.a. choreographies) versus mine
> where I say that a SOA service can have multiple
> interfaces and service behavior is implemented in
> the service implementation/component (I am not aware
> of IBMs model, sorry)
> 
> 
> To 2. I do not argue with the behavioral model could
> be referenced through the service description.
> However, the statement the service description of
> which the service interface is a part of which the
> behavioral model is a part in its part which points
> to the behavioral model as a part of service
> interface seems to me too much Web Service/WSDL
> driven. I have cases where this is not true. That
> is, the standard is not true to my organisation
> (exactly what you want to avoid in SOA RA)[a million
> examples cannot proof a theory while one example can
> disproof it]
> 
> Service Description is a form of declaration of the
> requirements the service component/implementation
> meets. That is, I do not see any contradiction
> between service component and service description.
> 
> To 4. In my interpretation, a Service has one
> Service Description, which can include multiple
> service interfaces. One Service may be associated
> with many Service Contracts, which content partially
> based on the Service Description. The Contract can
> include references to one or many Service Interfaces
> described in the Service Description. There may be
> no contracts between the client and the service
> provider, one per client or many per client. So, as
> you see, in my interpretation Service Contract does
> not equal Service Description or Service Interface
> as well.
> 
> It is interesting point: it is also true that
> service interfaces may
> not be part of a service contract. How a service
> might be engaged other than via its interface? If
> the service has only one interface today, you can
> say it is obvious extra to put it into the Contract.
> I would say that this is quite IT-type style of
> assumption. To me, the main power of SOA is in its
> ability to accept changes in the business with
> minimal changes in the implementation (not necessary
> based on the reusability but rather on
> change-ability and extendibility). From this
> perspective, I would put even single interface into
> the Contract and allow myself to introduce another
> interface tomorrow without a necessity to
> re-Contract with my old consumers. 
> 
> To 5. Steve Jones, in his message in this thread,
> gave a good explanation of necessity having more
> than one SLA per SOA service (I do not see any
> problems with SOA principles here, please, give me
> more details on this). If SOA Service models real
> world business service, my example is objective. In
> my favorite example with Laundry, one can compare
> the laundry Reception Service which is based on
> clerk/manual items check-in with a self-service
> machine check-in. The throughput of the Reception
> Service will differ through the clerk- and
> machine-based interfaces, will not it?
> 
> Finally, to the There are some generalities about
> SLAs that can be
> described in relation to contracts, but there are an
> infinite number of templates that can be created for
> SLAs  I propose to recommend just a reference in the
> Contract to the SLA and define the latter separately
> (or not define it all except it must be measurable).
> 
> Thank you,
> -	Michael
> 
> 



 
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html