[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Suggestions from Karsten Riemenr
Marty, I got it, thanks a lot for the explanation. Actually, without entering WSEL it is a little bit difficult to evaluate. The impression that I have, however, is that it seems that you consider the CPP as a sort of "shell" (with characteristics that will be found in WSEL and some other that are present in WSDL) with, in addition, the reference to a Collaborative Process Spec. This same Process Spec is, today, covered by BPSS but, I assume, you imagine it could be covered also by a combination of WSFL/WSDL. Is this a correct interpretation ? Thanks a lot. /stefano � -----Original Message----- � From: Martin W Sachs [mailto:[email protected]] � Sent: 27 June 2001 21:40 � To: Stefano POGLIANI � Cc: Welsh, David; [email protected] � Subject: RE: Suggestions from Karsten Riemenr � � � � Stefano, � � We are both correct. � � I meant that the last sentence say "CPP". I will explain: � � There are three different but functionally similar models that we can talk � about � � 1. The CPP plus the Process-Specification document. The � Process-Specification document describes the collaborative � process in terms � of roles. The CPP adds specific party IDs and all the endpoint properties � to the description in the Process-Specification document. � � 2. The CPP plus some combination of WSDL/WSFL. Here the CPP � adds endpoint � properties to the abstract definition of the choreography and interfaces � that is in WSDL/WSDF. � � 3. WSEL plus WSDL/WSFL. Here WSEL would add endpoint properties (whatever � they might be) to WSDL/WSFL. Again, I can't say much about this � combination yet. You can infer what you want from what is in WSFL. � � With regard to the sentence you quoted, I had model (2) in mind. � � 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" <[email protected]> on 06/27/2001 03:03:28 PM � � To: Martin W Sachs/Watson/IBM@IBMUS � cc: "Welsh, David" <[email protected]>, � <[email protected]> � Subject: RE: Suggestions from Karsten Riemenr � � � � Marty, � � I agree with this explanation. I thought mine was not very � different from this one. � My take was that WSDL is not enough by itself; if we complete it � with WSEL/WSFL, then I see the equivalence. � � I do not understrand the following sentence, though: � � � So, an ebXML BSI configured out of � � a CPP plus Process-Specification document (the BPSS instance document) � � reflects an interface including both the equivalent of the WSDL � � abstraction and the concrete endpoint properties described in the CPP. � � Is the last "CPP" reference what you meant? � � Thanks a lot for the comment! � � /stefano � � � -----Original Message----- � � From: Martin W Sachs [mailto:[email protected]] � � Sent: 27 June 2001 20:18 � � To: Stefano POGLIANI � � Cc: Welsh, David; [email protected] � � Subject: RE: Suggestions from Karsten Riemenr � � � � � � � � Stefano, � � � � While I agree with most of your comments, I would like to offer a � somewhat � � different view of these matters. � � � � WSDL does not overlap the CPP/CPA at all. Indeed, WSDL, as you say, is � a � � way in which a Web Service advertises the way it can be � accessed. In the � � ebXML world, this advertisement is effectively part of the BPSS instance � � document that is referenced by the CPP and CPA. More precisely, the � � combination of WSFL and WSDL is architecturally equivalent to the BPSS � � instance document in that the combination describes both the abstract � � service interface and the choreography. So, an ebXML BSI � � configured out of � � a CPP plus Process-Specification document (the BPSS instance document) � � reflects an interface including both the equivalent of the WSDL � � abstraction � � and the concrete endpoint properties described in the CPP. � � � � Since WSEL has not yet been exposed outside of IBM except for the four � � letters and the very brief description in the WSFL � specification, I can't � � comment on its role at this time. Given that the E stands for � "endpoint", � � an obvious inference can be made as to how it conceptually relates to � � ebXML. � � � � 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 <[email protected]> on 06/27/2001 11:51:01 AM � � � � To: "Welsh, David" <[email protected]>, Martin W � � Sachs/Watson/IBM@IBMUS, [email protected] � � cc: � � Subject: RE: Suggestions from Karsten Riemenr � � � � � � � � The idea of approaching the CPP/CPA with WSDL has been recurrent in some � � discussions I recently had. � � � � I just would like to add my 2 cents here, expressing my own position. � � � � I think that WSDL and CPP/CPA have some area of overlap, which does not � � mean � � that, IMHO, they overlap. � � The "area of overlap" is the area in which both the � specifications aim to � � define how a network component (the WebService or the BSI, � � according to the � � different vocabularies used here) defines itself to other � components. So, � � in � � my understanding: � � - WSDL is a way in which WebServices advertise the way in which � � they can be accessed. � � I apologize for the extreme simplification, but WSDL is a sort � � of API (in XML form) with binding infos � � - the CPP/CPA, **in addition to other things**, provides a � � similar "advertising" functionality but it is not API-oriented � � but is "business process" oriented. � � Instead of saying which are the "technical doors", the � � approach of the CPP/CPA is to expose the "logical doors", � � i.e. the doors "interpreted" in a business process context. � � � � If this succint description makes sense, then I think that WSDL � � and CPP/CPA � � tackle the problem in different ways (in addition of CPP/CPA doing more � � than � � this advertising, at least up to the state-of the WSDL specs). So, I � think � � that it would be very difficult to find a compromise on these different � � approaches. It may be possible to "expose both interfaces" at the same � � time, � � perhaps. � � � � I personally think that exposing "technical entry points" is a � � very minimal � � approach, that is good for trivial WS such as currency-converters, � � weather-forecasts and the like (which are the ones that are normally � � mentioned in the literature, btw...). "technical entry points" do not � � capture the "context", do not capture the information about the � � environment � � (and, why not, the reasons) for which a WS is called. � � � � I think that an ebXML BSI, configured out of a CPP, may "reflect" a � � WSDL-like interface. But this could become much more useful when the � whole � � WSEL/WSFL picture will be in place. � � � � /stefano � � � � � -----Original Message----- � � � From: Welsh, David [mailto:[email protected]] � � � Sent: 25 June 2001 16:58 � � � To: 'Martin W Sachs'; [email protected] � � � Subject: RE: Suggestions from Karsten Riemenr � � � � � � � � � Marty, � � � It would be very useful if 1. was elaborated a little more. � � � Couldn't 2 and 4 be tied to the same thing ? What's behind WSDL � � � is then left to the individual organization to operate; ie. very � � � elaborate system automation or semi-/manual efforts to create the � � � web service. But WSDL appears very important. � � � I'd suggest the BP jury is still out on should there even be a � � � procedural 'BP language' like BPML/WSFL/XLANG, or should BP be � � � more a declarative approach which probably resembles more of the � � � real business world. � � � -Dave � � � � � � � � � > -----Original Message----- � � � > From: Martin W Sachs [mailto:[email protected]] � � � > Sent: Monday, June 25, 2001 7:40 AM � � � > To: [email protected] � � � > Subject: Suggestions from Karsten Riemenr � � � > � � � > � � � > I have received the following suggestions from Karsten Riemer: � � � > � � � > 1. Use of the 'substitution' capability that was added to � � � > BPSS at Vienna. � � � > In � � � > general this expands to how to have generic business � � � > processes, and yet � � � > have � � � > easy to process specializations of those for the specific partners. � � � > � � � > 2. Alignment with WSDL. Generically this expands to how to � � � > best register � � � > the � � � > metadata about a partner's capabilities relative to the BP and its � � � > documents. � � � > � � � > 3. Alignment with other BP languages like BPML and WFSL. This � � � > may seem like � � � > more of a pure BP issue. But actually BPML may play an � � � > important role in � � � > describing what specifically a partner will do internally in � � � > response to an � � � > ebXML exchange. Generically this expands to how we apply XML � � � > to the link � � � > between b2b and EAI. � � � > � � � > 4. Specification of a Business Service Interface. ebXML phase � � � > one shyed � � � > away � � � > from specificying the actual software architecture. We just � � � > hinted that a � � � > BSI � � � > is configured with a CPP. Someone, probably in OASIS should � � � > step up to this � � � > task. � � � > � � � > Items 2 and 4 are clearly CPP-CPA issues. Item 4 should be joint � work � � � > among CPPA, MSG, and BP. � � � > I am less certain about items 1 and 3. I look forward to � � � > having Karsten � � � > participate and explain. � � � > � � � > � � � > 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 � � � > ************************************************************** � � � > *********************** � � � > � � � � � � � � � � � � � � � � � �
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC