RE: Use case

RE: Use caseExactly.

arkin
  -----Original Message-----
  From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
  Sent: Tuesday, March 18, 2003 1:35 PM
  To: 'Assaf Arkin'; 'Burdett, David'; public-ws-chor@w3.org
  Subject: RE: Use case


  Assaf:



  I agree with you that this is pure choreography. This also illustrate the
point that I made in my previous email that a given message of the
choreography may either come from outside or inside. Specifying a model (a
la BPSS) that puts an arbitrary company boundary might be too limiting to
handle a large set of use cases.



  If I understand you correctly, this use case suggests that one could
develop an "internal" service component that complies with the choreography
that was specified in the partner-to-partner case. Hence the Order Entry
component should only work with one choreography specification, it is only
the technical binding that will ultimately specify whether this choreography
occurs beyond company boundaries or within company boundary (via a service
component proxy representing each customer that are using this service).



  JJ-



  -----Original Message-----
  From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Assaf Arkin
  Sent: Tuesday, March 18, 2003 3:53 PM
  To: Burdett, David; public-ws-chor@w3.org
  Subject: RE: Use case



  I am talking purely about choreography between supplier role and customer
role, which is expressed in terms of service types, where one of the service
can be located on the customer side, but another service may be located not
on the customer side but acting as a proxy. Since the choreography talks in
terms or roles, responsibilities, etc it is location agnostic.



  arkin

    -----Original Message-----
    From: Burdett, David [mailto:david.burdett@commerceone.com]
    Sent: Tuesday, March 18, 2003 12:36 PM
    To: Assaf Arkin; public-ws-chor@w3.org
    Subject: RE: Use case

    Assaf

    I like your use case, but I think you are describing an orchestration
rather than a choreography. Is that correct?

    David

    -----Original Message-----
    From: Assaf Arkin [mailto:arkin@intalio.com]
    Sent: Tuesday, March 18, 2003 1:03 AM
    To: public-ws-chor@w3.org
    Subject: Use case



    I would like to submit a use case based on one of the implementations I
    have reviewed. This use case is interesting since it highlights how one
    would use Web services technologies like WSDL, WS-Policy, SAML and
    WS-Choreography even for interactions that are not SOAP enabled.



    Supply Acme Co. has an automated system for fulfilling orders. The
    supplier works with some customers that have an automated procurement
    system and both use SOAP to conduct transactions electronically.
    However, some customers have not automated their system. Acme Co. would
    like to conduct business with these customers and do so in an automated
    fashion.

    Acme Co. develops a Web-based front end system for these customers using
    HTTP and HTML technologies. Customers log into the system using their
    customer identifier and are able to place orders, track their status and
    print out invoices. Acme Co. also has a helpdesk which allows customers
    to conduct transactions offline. A customer may send an order by fax, or
    call to check the order status, and an Acme Co representative would use
    the Web-based front end system to perform an online operation on their
    behalf.

    Acme Co would like to have one definition for all transactions involving
    its customers regardless of technology. The business semantics are
    identical whether information is exchanged using SOAP, through the
    Web-based front-end or with the help of a representative. Acme Co
    realizes that reducing the number of business processes it needs to
    support would improve its efficiency.

    Acme Co choses the proxy approach. It defines a single choreography that
    would be used for all transactions with its customers. The choreography
    is expressed in the form of WSDL operations that are performed by its
    order fulfillment service and the customer's procurement service.
    Protocol bindings and service end-points are defined for those customers
    that use SOAP. The Web-based front end and helpdesk systems are defined
    as services that implement the role of a procurement system as defined
    by the customer process in that choreography. In this particular case it
    uses SOAP to communicate with fulfillment system.

    Although the Web-based front end is running in the same environment as
    the order fulfillment service, it is considered to be a customer
    service. When it exchanges messages it uses the security credentials
    given to the customer and not those of Acme Co to prevent one customer
    from learning about orders belonging to other customers.

    This distinction is important. From a technological perspective both
    Acme Co's and the customer's service run in the same domain of control.
    However, from a business perspective these are two different domains of
    controls, and customers are identified as different non-overlapping
    domains of control. Acme Co manages its policy with regards to each
    customer in a uniform manner regardless of which technology is used to
    conduct the transaction or how far SOAP messages have to travel.

    Once completed, Acme Co has:

    - A uniform representation of the choreography between its fulfillment
    service the the customer procurement service
    - A single business process to maintain
    - The means to support customers that do not have automated processes
    using the uniform model
    - A mechanism to support its security policies regardless of "location"
    of the customer service

    arkin

    --
    "Those who can, do; those who can't, make screenshots"

    ----------------------------------------------------------------------
    Assaf Arkin                                          arkin@intalio.com
    Intalio Inc.                                           www.intalio.com
    The Business Process Management Company                 (650) 577 4700