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

[michael.poulin@uk.fid-intl.com]

Thank you, Frank, you answer is quite clear to me and it helps me to find where my model does not match yours, precisely. I will describe the differences and offer you to look into them  may be you find something useful for the standard in my views

I totally share your definition of the SOA service. And the differences are:

1.	A SOA service can have multiple interfaces but the same service component(s)/implementation
2.	A SOA service interface includes all the actions that you may perform against  the service  while the service component(s) includes any behavioral models associated with  hose actions. That is, I have clear separation between the service interface and the service component. It is the same separation as between business interface (user activities associated with the services) and the business service itself.
3.	A SOA service interface includes access/communication mechanism/protocol and detailed definitions of the exposed operations, related data models (not the service data models but only interface specific ones), message exchange or communication pattern(s) and physical definition of the point of the service contact/access
4.	One SOA service can have none or many Service Contracts. A Service Contract may include a subset of the service interfaces exposed to particular client. For example, if a service have HTTP-, HTTPS- and IIOP-based interfaces, a concrete client may be contracted to use HTTP- and HTTPS-based interfaces only, i.e. if this client tries to access the service via IIOB-based interface, the request may be legally denied.
5.	Due to differences in the interface usability characteristics, the sane service may have many SLA depending on the interface used/agreed. For example, a throughput of the service accessed via HTTP may be 10 times higher than via HTTPS. The nature of the service does not change.
6.	A SOA service (especially business service) may have certain behavior that is not visible through its interface. Variations of this behavior may be specified in the different service contracts. Since many people consider that SLA are run-time measurable characteristics only, and the service behavior may last much further than the run-time (long-running business transactions), I am afraid to merge SLA with Contract.
7.	Finally, I used terms explicit and implicit with regard to Contract itself, not to the acts described in the contract (The act of agreement may be implicit or explicit). Notice how difficult it can be at the level of IT to distinguish  implicit from explicit agreement.  -  I disagree because explicit agreement just requires preliminary sign-off from the participants ( and following posting/publishing of the Contract in the Service Contract Repository) while an  implicit agreement takes place when a client or provider accepts constraints of another party without any additional actions; this is how Policy works. Please, believe me  that in my IT such things happen every day, in development and at run-time.

- Michael