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.
