[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] BPSS to WSDL mapping
JJ, I was not proposing to use WSDL instead of the CPA ! My point was simply: an ebXML deployed solution, once looking at the two partners as two separate black-boxes, looks very much like looking at two separate web services. So, since w/s can be described using WSDL, the same applies to the two separate ebXML components. The reason one would do this... well, I tried to highlight two of them which may be valid, may be dummy... there may be other ones or there may be none. I was just looking at the problem from a technical point of view. Ciao /stefano » -----Original Message----- » From: Jean-Jacques Dubray [mailto:jjd@eigner.com] » Sent: 12 March 2002 17:03 » To: 'Stefano POGLIANI'; ebtwg-bps@lists.ebtwg.org; 'OASIS ebxml-cppa' » Subject: RE: [ebxml-cppa] BPSS to WSDL mapping » » » Stefano: » » I am not sure I understand your distinction between Definition and » Description in the context of ebXML. I thought that a CPA was all you » needed as a description to configure your system unitarily and be » guaranteed that when you do business with the other party of the CPA it » will work. This would qualify as a description, even though there are » definitions embedded in it (e.g. a Collaboration definition which can be » reused in different CPAs). » » Furthermore, I don't see why I would need to define a WSDL based » description rather than just stick with my CPA. Now, if the » implementation of your ebXML infrastructure is done via web services, » this can be done internally, but what would be the value in making it » public? Since you would have to create adjuncts to past information » relative to the part of the BPSS/CPA metamodel which is not covered by » WSDL? » » The point that you are making is very valid that maybe BPSS should be » extended to be able to choreograph "wsdl:operation" invocations and » "ebXML:business transactions", this could have some application in » multiparty collaborations where you could do a web-service based credit » check before you accept an order, or you do a 'price check" before you » place an order. I think that this is a very interesting idea an will » clearly (and finally ...) show why BPSS is different of WSDL. If I could » summarize it as one sentence, web services are good for casual » interactions, while ebXML was designed to carry out business » transactions. » » As you pointed it out we could raise WSDL to the level of BPSS, but what » for, this will only get in the way of the nascent and very promising » "intra-enterprise web service infrastructure market". » » Cheers, » » Jean-Jacques Dubray____________________ » Chief Architect » Eigner Precision Lifecycle Management » 200 Fifth Avenue » Waltham, MA 02451 » Tel: 781-472-6317 » Cell: 508-816-4518 » email: jjd@eigner.com » url: www.eigner.com » » » » >>-----Original Message----- » >>From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com] » >>Sent: Tuesday, March 12, 2002 10:35 AM » >>To: ebtwg-bps@lists.ebtwg.org; OASIS ebxml-cppa » >>Subject: RE: [ebxml-cppa] BPSS to WSDL mapping » >> » >>I have followed so far this thread, but I am little bit » >>confused of what the goal is. I try to summarize here my » >>personal thoughts and ideas on the subject (as I said, » >>"personal" thoughts) » >> » >>The title speaks about "BPSS to WSDL mapping". I think that, » >>in practice, there could be two possible mappings: » >> » >>1. Definition vs Description » >> This is what I personally like very much. » >> » >> I think that BPSS (and all the "ebXML stack") is very good » >> when one needs to "define" and "model" a scenario (B2B or » >> sometimes B2C) which needs to be robust, enforced, secure... » >> well, we all know, "a real life" scenario. » >> » >> Following this path, I could think that I "model", then » >> I "define" and, finally, I "implement and deploy" my » >> ebXML solution following the canonical ebXML steps. » >> The result will be software that enforce the BPSS/CPA » >> and that will really support my business. » >> » >> The "deployed" ebXML solution (the two BSIs... just to » >> mention something I like) are actually "software endpoints » >> which use internet protocols to communicate and XML". » >> From a "black-box" perspective, they are not different » >> from "web services". Let's not consider them (the two » >> BSIs) as something which is derived by ebXML and which » >> enforce a specific BPSS/CPA... just look at them as mere » >> software endpoints... aren't they web services? » >> » >> And, so, one can "DESCRIBE" the two endpoints as one » >> describes web services; why cannot they be "described" » >> by 2 WSDL files? It would be a "reflective" capability. » >> » >> For which reason should I do this? » >> - Because I would like to expose my "ebXML-BSI" » >> as a w/s in order to ease the acces to it from » >> other partners (my BSI "enforces" the BPSS). » >> Could be useful in situation where a big partner » >> is accessed by little ones (who do not have » >> bandwith to understand ebXML) » >> - Because I want to standardize the interfaces » >> of my software towards the web... » >> » >> The missing point is, imho, the fact that we are missing » >> the WSDL bindings to the ebXML-TRP. Otherwise... » >> » >>2. Collaborating "operations" » >> Another possibility would be to investigate the option » >> of referring to WSDL operations in the » RequestingBusinessActivity » >> and RespondingBusinessActivity, and to reference WSDL » >> message (parts) in the DocumentEnvelopes » >> [Sorry if I missed something, BPSS is not my "forte"] » >> » >> This would assume that we have pre-defined the operations, » >> messages, porttypes in a web-service way and that we » >> want to re-use them as building blocks for the ebXML BPSS. » >> » >> I do not see that interest in doing this since it will boil » >> down to the "define vs describe" scenario, but I think » >> it could be done. » >> » >>3. Extending WSDL. » >> I do not think this is the way to follow. BPSS and WSDL » >> are at very different levels (as Bob highlighted). What » >> would be interesting is to "derive" WSDL from BPSS, but » >> the two domains are very different. Extending WSDL would » >> mean to "change it completely". So why WSDL? » >> » >>Best regards » >> » >>/stefano » >> » >>---------------------------------------------------------------- » >>To subscribe or unsubscribe from this elist use the subscription » >>manager: <http://lists.ebtwg.org/ob/adm.pl> » » »
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC