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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

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


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


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



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