Ash, I am afraid you dd not get my questions and started explain SOA
substituting it by Web Services.
If speak about SOA as defined in SOA-RM standard, "Usually in an SOA" there
is no such thing as "end point address" and service contract is described
independently from service interface.
Policies and QoS are different animals, plus, policies may be exposed by the
consumer as well, not only by a service provider (I know that WS-Policy does
not deal with consumer's policies but it is Web Services, not SOA, standard
again).
SOA-RM defines much more artifacts than just service and service description.
In particular, "Service description specifies the way a service consumer"
may, not will, "interact with the service provider", because not all
interaction attributes may be used for actual interaction by certain consumer.
I doubt that service description explicitly "specifies the format of the
request and response from the service." - it is the part of service interface
definition. A composit service defines its own interface(s) that may be not
among interfaces of composed services and the composit service definition
(and its subset - contract) contain only service own interfaces, not all
others.
Sorry, but it looks to me I have not get answers to MY questions yet.
- Michael
ash galal <[EMAIL PROTECTED]> wrote:
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.
---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.
