RE: Business Service Interface

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

Stefano:

My responses are embedded in the appended copy of your posting.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Stefano POGLIANI <stefano.pogliani@Sun.COM> on 10/23/2000 11:22:02 AM

Please respond to stefano.pogliani@Sun.COM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-tp@lists.ebxml.org
Subject:  RE: Business Service Interface



Marty,

     thanks for the mail (sorry for my late answer but I have been out of
office).

Indeed the BPF slides you provide are covering the same area as the BSI
description
I posted. The challenge is, now, being able to capture these inputs
and the powerful comments from the other members of the list and
consolidate them
in a document that could be accepted as a basis for discussion.

Please find, embedded, the answers to your comments.

Best regards

/Stefano

>
> The BSI is highly desirable for new ebXML-aware applications as well as
for
> legacy applications.  The reason is that most of its functions provide
> essential services even to new applications.

     certainly this is what I think. I meant this when I wrote:

     "The BSI is not mandatory, but it is logically necessary to
accommodate
     the basic functionalities described below".

     The BSI layer should be present everywhere an Application (new or old)
     needs to participate in an ebXML context. The BSI Layer is NOT JUST a
     Technical Passive layer, but adds behaviour to the Application and
makes
     sure this behaviour is consistent with the ebXML specifications and is
     interoperable with other inplementations.

       MWS:  I agree completely.

>
> IDEAS TO BE DEVELOPED (page 7):
>
> The BSI should provide essential conversation-based services. The actual
> start and end of a conversation are application-dependent, so the BSI's
> interface to the application should provide for indicating start and end
of
> conversation.  See the IBM tpaML proposal for discussions of the
> conversation.

     My idea was to "define" a Conversation object which has its own
lifecycle
     within the BSI and could, eventually, be persisted (for
receoverability
     and/or for scalability [a sort of swap]).

     I am not sure I understand and/or agree with the fact that
conversations
     are application-dependent.

       MWS:  The conversation is not application-dependent but the events
which
       start and end a conversation are.  The reason is that it is the
application
       that defines what is a meaningful unit of business.  The BSI must
provide
       the operational constructs for the application to use according to
its
       design.

       I think that, in a general model, conversations
     may even not require interfacing the Application world but could be
     in the position of "taking decisions" by themselves (based, for
instance,
     on information found in the envelope/header (environment information)

       MWS:  I believe that you are suggesting that information in the
header
       should define the beginning and end of the conversation.  That is a
valid
       interface between the applicaton and the BSI.

     or, why not?, in the payload itself (stop this conversation and start
     the other when the content of the tag is > 100 USD...).

       MWS: I don't agree to use of the payload because the payload content
should
       be purely an application matter and middleware should not have to
look inside
       it.

       MWS:  If you are proposing a header that is at the application level
but
       independent of the details of any specific application, I could
agree to
       that but that may not have the richness you are suggesting by your
example
       ("when the content of the tag is > 100 USD...").


     This would, probably, require an extension of the Transformation
layer.
     What I mean is that the Tr Layer could be "programmed" to dynamically
     load modules or stylesheets which could "help" in that.

>
> A given BSI should definitely support concurrent conversations as a
> performance enhancement. An alternative view is that a BSI is an
> instantiation of one conversation and a B2B server should be able to run
> many BSI's concurrent.  In that case, starting a conversation
> invokes a new BSI.

     from a design point of view, I would prefer to separate the
     BSI from the Conversation and having the BSI able to manage
     multiple conversations in parallel.
          Parallel conversations may be required both to support
          multiple "clients" (where each client runs its own
          statefull conversation independently on the others) and
          to support "switching" within the same client (where
          some rule make a sub-conversation start whilst keeping
          the main one active).
>
> I prefer that a conversation always be started by an API call from the
> application.

     see my point previously. I would say that the conversation is
     started by the BSI. The BSI may be "triggered" by the Application
     or, in some cases, be triggered by the "rules".

       MWS:  The application triggering the BSI to start a conversation
       is equivalent to what I proposed.  The signal comes from the
       application but the BSI does the actual work of initiating or
       terminating the conversation.
>
> Maintaining the conversation state is an essential service of the BSI.
It
> can maintain the state in a conventional database.

     Indeed. What is important is to "avoid" to bind to a specific DB
     and to provide the "interface"/"message defs" that allow an
     interoperable use of the stored informations.

     What I mean is that the SMEs may not be forced to buy an expensive
     DBMS and could implement some of these things in flat files for
instance.

       MWS:  I fully concur.

>
> Regards,
> Marty
>
> (See attached file: bpf.pdf)
>
> ******************************************************************
> *******************
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ******************************************************************
> *******************
>
>
>
> Stefano POGLIANI <stefano.pogliani@sun.com> on 10/18/2000 09:15:53 AM
>
> Please respond to stefano.pogliani@sun.com
>
> To:   ebxml-tp@lists.ebxml.org
> cc:
> Subject:  Business Service Interface
>
>
>
>
> I have started to  collect some ideas on the Business Service Interface
> (BSI).
> These ideas were  mainly derived from some thoughts I had on this subject
> and from the discussions  during the f2f last week.
> At the moment,  please consider this as a contribution to the discussion.
>
> Attached, find a  word document with two gifs for the pictures.
>
> Best  regards
>
> /Stefano
>
>
>
>
>
>
>