RE: [wsbpel] Issue - 77 - Under specified operation definitions

Ron,

With your idea of rinsing SOAP off the body of BPEL, your agreement with Yaron also amounts to rejecting Yaron’s proposals for dealing with optional headers. I assume that is intentionally left unsaid .. ;-)

Satish

From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Wednesday, November 19, 2003 9:09 AM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 77 - Under specified operation definitions

Yaron,

    I have to agree with you; the only sane course of action here is to demand that any message constructs that BPEL can use must be described in WSDL, otherwise BPEL is blind to them. This doesn't prohibit lower-levels of a "stack" from mucking around with the message further, injecting or processing headers as needs be. We sure don't want to be in business of building exceptions to this rule into the BPEL vocabulary!

    I'm a little leary about having processes directly mess around with secondary protocols (i.e. headers). A process could easily become overwhelmed with chewing on and processing headers, signatures, assertions, and the actual business process being implemented could become unreadable. Do we want, at a business level, to be messing around with such low-level protocols? My sense is that BPEL ought to work at a higher level of abstraction, if it is to be used to express business processes rather than a lot of technical protocol processing.

    Getting back on topic: some confusion arises with the confusion of SOAP with WSDL. I know that SOAP and WSDL could have been better designed to keep this clearer, but the fact is some (many, perhaps?) associate web services only with SOAP, and look at BPEL as, in part, a way to play directly with SOAP messages. This is a misleading way to look at it, just as it is misleading to regard SOAP as just HTTP. Let's just rinse all that SOAP off our thinking, and stick with nice, clean WSDL. :-)

-Ron

Yaron Goland wrote:

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

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.

wsbpel message