Usually in an SOA collaboration, registry provides the consumer with the interface contract and end point address. Policy (QoS) is a set of rules under which a service provider makes the service available to consumers. There are aspect of the policy that is functional too. The SOA artifacts is service and service description. Service description specifies the way a service consumer will interact with the service provider. It specifies the format of the request and response from the service. This description may specify a set of preconditions, post conditions and/or quality of service (QoS) levels. This is why I consider contract as an interface as they are covered in the architecture as one unit, As I think. Composite service is possible too but I think all interfaces must be covered by one contract.
Michael Poulin <[EMAIL PROTECTED]> wrote: I guess, Ash means that the contract includes an interface. I think a contract may contain more than one interface of a SOA service. The question is: What are "all of this aspect"? Does contract include execution context or it exists on its own and just influences the contract? Does execution context include: a) policies only (different conditions may be expressed as policies) b) policies and message models (message formats and message exchange scenarios) c) everything which affects consumer-provider interactions d) conditions of the service execution (on the provider's side) and/or the context of the consumer's request ? - Michael ash galal <[EMAIL PROTECTED]> wrote: This is also support my short SOA defintion " SOA is about an environment that allows a contract to be made between the provider of the service and a consumer." The contract (interface) should cover all of this aspect in both case of interactions, computer interaction or human interaction the environment should cover the defintion, publishing, finding goverance, invocation,..etc. Joost <[EMAIL PROTECTED]> wrote: Interesting question. The semantics of the messaging depend on the business transaction. That is; the business negotiation that would take place if computers were not involved. Essentially it's in the form: if you do this i promise to do that So it's a protocol of requests, promises and obligations. So a pizza order service would involve probably some services that represent these promise and obligation steps. But the meaning of these steps are in the real world; not in the IT. It's very similar to buying something on the web; amazon could be lying about the order I made. Or could change the page after I ordered. You'll doctor the protocol to minimize these risks; for instance only use a provider who has an api that let's you pay after receipt. But that's not always feasible. So then you're left with legislation and social reputation mechanisms. To conclude; the semantics of the 'order pizza' service can be expressed as pre- and post conditions: Pre: the client has to have credit, the pizza should be available etc. Post: the clients credit will be charged, the pizza will be delivered within 30 minutes. These semantics will have to be stated in a contract. And there will have to be some recourse if obligations are not fulfilled; legislatory or by a reputation system. Note that these things can not be expressed with REST. REST-semantics are imo. not suitable for business services, only for data oriented backend services. groeten, Joost de Vries --- In [email protected], Jan Algermissen <[EMAIL PROTECTED]> wrote: > > Hi, > > if have SOA-ordered a pizza the other day but yesterday I learned I > sold my house..... > > How do I prove in court that my digitally signed pizza order was > indeed a pizza order and not (as the recipient claims) a house sale? > > Jan > --------------------------------- Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
