Re: [ebxml-bp] BPSS executability and where it ends

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Dick, thanks for these inputs.  I would ask for you to add a few more 
pieces of information in the context of what you would suggest as a use 
case format so we can use this as an input (not to formalize too much 
but ensure we use this as a starting baseline to start to look at 
industry/sector requirements and their business needs - you have 
provided a good baseline from which to start).

    * Actors: Transmission Authority, Auction Participants, other
    * Detailed Description including short summary of flow of events
          o See background and architecture above.
    * If applicable:
          o Triggers: Appears that time, offers and timely purchases may
            apply here.
          o Pre conditions: Offers made.
          o Post conditions
          o Other dependencies
    * Identified issues that are or may be related to BPSS
    * Items outside of the scope of BPSS but may create other
      dependencies or integration points / interfaces:
          o The details of how a service is implemented by the TA is not
            necessary for a market participant to invoke a service and
            indeed the TA may consider the processing steps to be
            sensitive information that it does not wish to disclose. Key
            here is the processing steps may not be externally visible.
            However, we need to quantify what QOS and other attributes
            are exposed in your business collaboration (in order to
            facilitate what occurs at the messaging and business
            process, and to enable other lower level process functions
            that could occur using other technologies or an executable
            process).
          o On your comment, "BPSS appears to provide a description of a
            business process but contains 'too much' information, that
            may be considered sensitive, or perhaps irrelevant given the
            individual nature of 'internal' business processes of each
            trading party,' can you give more specifics here - this I
            believe will expose what happens in BPSS and what is
            delegated to a lower level process.

Thanks.
Dick Brooks wrote:

>Serm's conclusions and observations are in line with my own, with regard to
>what is/is not achievable using BPSS.
>
>I present the actual business cases I'm working on to describe what I
>believe BPSS needs to provide, in order to be beneficial (to me).
>
>First, I'll provide some background about my project areas, this will be
>followed by a description of the Service Oriented Architecture being
>developed in these project areas and lastly I describe the "missing pieces"
>which BPSS may be able to fill, some day.
>
>Background:
>
>Electric markets around the world are deregulating. Utility companies are
>being split into separate legal entities and information exchange which was
>department-to-department within a utility are transformed into
>business-to-business information exchanges. In addition, new competitors are
>entering these markets. A "standard" B2B infrastructure is needed to
>facilitate the "new market". Certain "functions" (e.g. scheduling capacity
>of transmission system resources, balancing power generation with demand,
>etc.) remain regulated and these functions are performed by a central
>"Transmission Authority" (TA). The TA must provide "services" to all market
>participants on a fair and equal basis.
>
>Architecture:
>
>The role of a centralized TA is ideally suited for a Service Oriented
>Architecture B2B infrastructure.
>
>In one sense the TA is managing an auction site where power generators
>submit "offers" to sell power
>and power purchases are made each half hour. All parties are notified of
>auction results on the half hour and specific generators are given operating
>instructions for the period.
>
>A service oriented architecture lets the central Transmission Authority
>"publish" services that are available to all market participants. Each
>service is described in terms of:
>-  its "Service" and "Action" values (used within the ebXML header message
>within ebMS when invoking the service)
>-  the input required to perform the service (e.g. required Manifest
>contents - described as XML Schema documents)
>-  the output produced by the service (e.g. described as an ebXML message
>with Service and Action values that will be returned, along with output data
>described using XML Schema).
>
>For example, the "Offer to Sell Power" service provided to Market
>Participants by the Central TA might be described generically as follows:
>
><serviceDescription>Offer to Sell Power
><Entry-point-url>http://.../URI-to-ebMSH
><Message-Exchange-Pattern synchronous=true
>delivery-ack-requested=true>Request-Response
>
><request-service>PowerSales
><request-action>OffertoSell
><request-payload-required>http://.../OffertoSell.xsd
>
><response-service>PowerSales
><response-action>ResultsofOffertoSell
><response-payload-provided>http://.../ResultsofOffertoSell.xsd
>
>At a cursory level, this is all the information needed to describe the
>EXTERNAL interface of services available to market participants by a TA.
>The details of how a service is implemented by the TA is not necessary for a
>market participant to invoke a service and indeed the TA may consider the
>"processing steps" to be sensitive information that it does not wish to
>disclose.
>
>On the other hand the TA will want to maintain a detailed "choreography" of
>the steps performed within each service. This is the "executable" business
>process the TA performs whenever a service is invoked. Likewise a market
>participant may have their own "choreography" associated with a service,
>which they do not wish to disclose to a TA when invoking a service.
>
>Missing Pieces:
>
>The ebXML Message Service clearly provides the facilities to implement a
>service oriented architecture and is the prescribed solution for secure,
>reliable implementation.
>
>WSDL appears to provide the means to describe the "external interface" of a
>service, but it appears deficient in its support for ebXML MS.
>
>BPSS appears to provide a description of a business process but contains
>"too much" information, that may be considered sensitive, or perhaps
>irrelevant given the individual nature of "internal" business processes of
>each trading party.
>
>What "I need" is:
>1.  a standard "external service description" which contains the minimal
>information needed to invoke a service from an external source
>AND
>2. a flexible means to describe and implement the steps associated with each
>service, ideally this description would be "executable" by a "workflow
>engine".
>
>At this time, I don't believe BPSS or WSDL meet my needs, but I am
>participating in both efforts in the hope that this will be rectified.
>