OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Business Service Interface


Based on your posting below, I believe that you see the BSI as performing
two distinct functions.  One is the application-independent functions that
can be performed by the B2B middleware.  These are the functions listed on
my first BPF slide.  In the implementation pictures, the
application-independent part is a combination of the TPA objects and the
BPF Services.  The TPA object is not really application-independent but it
is generated from the TPA without reference to any other aspect of the
application. The second, which you are describing below, is
application-dependent in the sense that it has to look inside the payload
and know how to do that.  I agree that the second one is necessary and we
have similar function in our BPF prototype.  We call it the service
implementation (SI) object. It is shown in my BPF slides, though
unfortunately named differently in each case.  It is custom-written for
each application and is essentially the interface between the legacy
application and the middleware.

   In "Business Setup...", it is "Business Logic"

   In "BFP Compnents...", it is "I/F to Bus. Logic"

   In "Flow Through...", it is the SI (Service Implementation) object,
   which is the actual name of it in our prototype.

So, I think that we are in very good agreement on all points.



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 01:05:36 PM

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


     the only thing we seem to "disagree" is the use of the payload as a
for "decision making".
I agree that the payload is application specific but decisions based on
application-specific data may not be taken by the application itself.
     Think to a case where you have a legacy which works independently
     of an "integration environment". The application may behave evenly
     in case if <SALARY> is > 100 USD or <=.
     But, in the context of the integrated solution, you may want to do
     something using this "rich information".

     You do not want to modify the code of your application nor the
     application will ever be able to output the necessary "command"
     for driving the BSI.
So, in such a case you could choose :
     - either to have the "BSI" to look inside the payload
     - or to duplicate some info in the payload and put them
       at header/envelope level
In both cases, I think, the BSI should be involved :
     - in the first, of course the BSI should be able to drill
       inside the payload
     - in the second, somebody else (another BSI since it is the
       only one who could build the header) drilled down in the
       payload to duplicate the info into the header.

Does it make sense ?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC