[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Business Service Interface
Stefano, 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. 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 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 Marty, the only thing we seem to "disagree" is the use of the payload as a "source" 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 ? Regards /Stefano
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC