RE: [ebxml-cppa] BPSS to WSDL mapping

[Stefano POGLIANI <stefano.pogliani@sun.com>]

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