OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Issue - 77 - Under specified operation definitions


There is also the solution I proposed before: allow abstract messages, other than the ones specified in an abstract operation, to appear in BPEL activities.

So far I heard somebody saying it's not a good idea, but I have not seen concrete indication of any negative consequences of doing that.

Ugo

> -----Original Message-----
> From: Yaron Goland [mailto:ygoland@bea.com]
> Sent: Tuesday, November 18, 2003 1:53 PM
> To: Ugo Corda; 'Harvey Reed'; 'Satish Thatte';
> wsbpel@lists.oasis-open.org
> Subject: Issue - 77 - Under specified operation definitions
> 
> 
> Issue - How do to deal with message content that is not 
> specified in the WSDL abstract operation definition?
> 
> 	For example, if a BPEL process receives a SOAP message 
> with a SOAP security header that wasn't specified in the WSDL 
> abstract operation definition then how does the BPEL process 
> reach into the header and pull out the name of the sender so 
> that the BPEL process can send a message such as "I just got 
> a signed message from Joe"?
> 
> 	The inverse example is also possible. The BPEL engine 
> may have been given a standard WSDL definition that does not 
> specify the use of a callback header in the WSDL abstract 
> operation definition. If the BPEL process needs to insert 
> such a header, how does it do it?
> 
> 	The original issue that started this thread 
(http://lists.oasis-open.org/archives/wsbpel/200310/msg00197.html) also provides another example of the problem that uses some fairly naughty but not apparently illegal WSDL behavior.

There would seem to be two fairly straight forward solutions to the issue - Introspection or re-write the WSDL.

Introspection would require us to introduce a new BPEL activity that could somehow plum a message so that it is possible to 'see' parts of the concrete message that are not present in the abstract operation definition. Similarly we would need to be able to edit the concrete message before it goes out in order to include content that wasn't defined in the WSDL abstract operation definition. The complexity of introspection makes for what appears to me to be a solution that is much worse than the problem.

The other solution is to require that people re-write their WSDLs. If you want to receive message content that isn't in the abstract operation definition you were given then you need to edit the WSDL you feed your BPEL engine to include that content in its abstract operation definition. The same logic applies to sending messages with content that wasn't specified in the original WSDL abstract operation definition. 

Re-writing WSDLs may not be pretty but introducing introspection seems worse.

	Yaron


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]