RE: [wsbpel] endpoint references

["Martin Chapman" <martin.chapman@oracle.com>]

Personally I would suggest BPEL defines its own container for holding
wsdl1.1 
Port information, after all that is all that is needed.

Martin.

> -----Original Message-----
> From: John Evdemon [mailto:jevdemon@microsoft.com] 
> Sent: Monday, January 26, 2004 9:11 AM
> To: Ron Ten-Hove; Martin Chapman
> Cc: Eckenfels. Bernd; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] endpoint references
> 
> 
> How then would endpoint references be made?  Would all 
> endpoint references be treated as BPEL extensions?
> 
> What do you all think?
> 
> Thanks!
> 
> John
> 
> > -----Original Message-----
> > From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> > Sent: Friday, January 23, 2004 4:59 PM
> > To: Martin Chapman
> > Cc: 'Eckenfels. Bernd'; wsbpel@lists.oasis-open.org
> > Subject: Re: [wsbpel] endpoint references
> > 
> > Martin,
> > 
> >     This is an instance of issue 34 <http://www.oasis- 
> > open.org/apps/org/workgroup/wsbpel/download.php/5099/wsbpel_is
> > sues_list.html#Issue34> , for which I am champion.
> > 
> >     I asked OASIS management (in August) to help us, with a 
> statement 
> > of policy concerning the incorporation of proprietary 
> specifications 
> > in OASIS specifications. I have yet to receive an answer 
> (this type of 
> > policy must be crafted with due care), but it seems reasonable to 
> > assume that proprietary specifications that aren't already de facto 
> > standards will be excluded from OASIS standards. This means that 
> > references to non-standard materials, such as those you mentioned, 
> > will need to be removed as part of the resolution of issue 34.
> > 
> >     WS-Addressing is the only proprietary spec that I'm 
> aware of that 
> > BPEL takes a direct dependency on (which in turn depends on 
> WS-Policy, 
> > which sucks in a herd of other WS- specs, most of which are 
> > proprietary, many of which cannot even be licensed!) We should 
> > certainly avoid adding new references to such specs, for we will 
> > likely have to remove them before we are done with BPEL.
> > 
> > Cheers,
> > -Ron
> > 
> > Martin Chapman wrote:
> > 
> > 
> > 	This raises a question. Since we agreed to remove
> > references and
> > 	dependancies to
> > 	non-standard material such as ws-t and ws-c we should
> > also remove references
> > 	to
> > 	ws-addressing, and leave snippets like below to
> > extensions.
> > 
> > 	Martin.
> > 
> > 
> > 
> > 		-----Original Message-----
> > 		From: Eckenfels. Bernd
> > [mailto:B.Eckenfels@seeburger.de]
> > 		Sent: Thursday, January 22, 2004 3:02 PM
> > 		To: wsbpel-dev@yahoogroups.com;
> > wsbpel@lists.oasis-open.org
> > 		Subject: [wsbpel] endpoint references
> > 
> > 
> > 		Hello,
> > 
> > 		has anybody a valid bpel snippet, which uses an
> > assign from a
> > 		fixed endpoint reference to a partnerLink and then
> > invokes
> > 		that dynamically defined endpoint? I am curious on
> > the
> > 		typical usage for that feature of BPEL.
> > 
> > 		I guess t he from looks something like:
> > 
> > 		<sequence>
> > 		  <assign>
> > 		  <from>
> > 		    <wsa:EndpointReference>
> > 
> > <wsa:Address>http://www.newurl.com/</wsa:Address>
> > 		    </wsa:EndpointReference>
> > 		  </from>
> > 		  <to partnerLink="supplier" />
> > 		  </assign>
> > 		  <invoke partnerLink="supplier" ... />
> > 		</sequence>
> > 
> > 		Mit freundlichen Grüßen
> > 		Bernd Eckenfels
> > 		Chief Architect
> > 		--
> > 		SEEBURGER AG - Edisonstr.1 , D-75015 Bretten,
> > Germany
> > 		Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-
> > 1256
> > 
> > 
> > 	mailto:b.eckenfels@seeburger.de -
> > http://www.seeburger.de
> > 
> > 	To unsubscribe from this mailing list (and be removed
> > from the roster of the
> > 	OASIS TC), go to
> > 	http://www.oasis- 
> > open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.
> > 	php.
> > 
> > 
> > 
> > 	To unsubscribe from this mailing list (and be removed
> > from the roster of the OASIS TC), go to http://www.oasis- 
> > open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
> > .
> > 
> > 
> > 
> 
>