[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 77 - Under specified operation definitions
Hi Paco, Just curious: does WSIF allow you to define abstract messages that are not part of an abstract operation? Ugo > -----Original Message----- > From: Francisco Curbera [mailto:curbera@us.ibm.com] > Sent: Wednesday, November 19, 2003 3:34 PM > To: Ugo Corda > Cc: Ron Ten-Hove; Satish Thatte; wsbpel@lists.oasis-open.org; > ygoland@bea.com > Subject: RE: [wsbpel] Issue - 77 - Under specified operation > definitions > > > > > > > Hi Ugo, > > It is interesting that you mention WSIF because WSIF follows > very strictly > the notion that one programs against the explicit porttype > definition only, > and relegates all protocol specific stuff down to the > middleware - where it > belongs. When we developed WSIF two years ago the whole idea > was to have a > Web services programming model counterpart of the WSDL > separation between > business interface (the porttype) and protocol and QoS > specific function > and artifacts. BPEL embodies today that same approach of > trying to keep > binding stuff from obfuscating the business logic while at > the same time > allowing you to run over multiple protocols (a fact which we > conveniently > exploited building the BPWS4J engine on top of WSIF.) > > In any case, I have to agree with you that WSIF lets you do > really cool > stuff ;-) > > Paco > > > > > > > "Ugo Corda" > > > <UCorda@SeeBeyond To: > "Satish Thatte" <satisht@microsoft.com>, "Ron Ten-Hove" > > .com> > <Ronald.Ten-Hove@Sun.COM>, <ygoland@bea.com> > > cc: > <wsbpel@lists.oasis-open.org> > > 11/19/2003 05:51 Subject: RE: > [wsbpel] Issue - 77 - Under specified operation definitions > > PM > > > > > > > > > > All that needs to be said here is that some WS designers > decided to use the > full spectrum of the WSDL abstract interface, including > abstract messages > not belonging to abstract operations, to define their message > contents. > Even though it might be argued that it was not a good > decision for various > reasons, they still did that in complete compliance with the WSDL 1.1 > rules. > > Exactly how they did their binding mappings is really hard to > tell in all > possible cases. You know very well that SOAP has not been the > only binding > being deployed so far. For instance, IBM's WSIF > implementation has been > around for quite a while and has been supporting all kind of > other bindings > other than to SOAP, including (if I remember well) JMS, RMI > and plain Java > code. > > Ugo > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Wednesday, November 19, 2003 2:36 PM > To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified operation > definitions > > My problem is that I can’t pin down where the requirement > comes from — if > it is relative to legacy services presumably in the real world that is > because they are using SOAP. If not, what is it? We can’t > have a very > abstract requirement based on arguments about dirty legacy > problems without > being specific about those problems. > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Wednesday, November 19, 2003 12:52 PM > To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified operation > definitions > > You are referring to one binding officially supported by WSDL > (by the way, > it is not the only one). But this group has previously decided that we > don't want to limit ourselves to that. So I don't think using > that argument > is appropriate in this discussion. > > Ugo > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Wednesday, November 19, 2003 12:43 PM > To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified operation > definitions > The only well-defined way in WSDL to actually use parts of abstract > messages not appearing in abstract operations is through SOAP header > binding is it not? Not mentioning it does not make it go > away, much like > those legacy services ;-) > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Wednesday, November 19, 2003 12:37 PM > To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified operation > definitions > > The requirement to deal with legacy Web services (it just > happens to be a > hot item with my company ;-). > > Please keep in mind that my proposed resolution does not > even mention SOAP > and bindings. It just extends the current coverage of the abstract > interface to include abstract messages not appearing in abstract > operations (which, whether you like it or not, are still > part of the WSDL > abstract interface). > > Ugo > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Wednesday, November 19, 2003 12:31 PM > To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified operation > definitions > We came back full circle. > > I am starting with the assumption that we do not want to > deal with SOAP > complexities and binding issues in BPEL. That leaves us > with abstract > WSDL interfaces. This is also Yaron’s position. > > Now given this as the starting position (which I know you > disagree with, > but suspend disbelief for a moment), what requirements could motivate > Issue#77? > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Wednesday, November 19, 2003 12:07 PM > To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified operation > definitions > > Satish, > > Which requirement are you referring to? A BPEL requirement? A WSDL > requirement? > > As far as I know, according to WSDL (and SOAP too) there is no such > requirement that a header must be associated with a > secondary protocol or > used by intermediaries. > > BPEL of course is free to add this requirement, but if it does so it > should clearly specify that it is something above and beyond what is > required by the basic specs (and it would still leave us to > deal - or not > to deal - with legacy Web services that took a different > interpretation). > > Ugo > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Wednesday, November 19, 2003 12:00 PM > To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified > operation definitions > Ugo, > > This is just a requirements issue. You are absolutely correct that > abstract message parts might reflect anything. The > question is: where is > the requirement for any additional mechanism coming from if not from > contingent data being added via secondary protocols or by > intermediaries? > > Satish > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Wednesday, November 19, 2003 11:53 AM > To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified > operation definitions > > The connection between "optional headers" and "secondary > protocols" is > completely arbitrary. There is nothing in the WSDL spec > that says that a > header that appears in an operation is not related to a "secondary > protocol", or vice versa that a header that appears in an abstract > message not part of an operation is indeed related to a "secondary > protocol". > > So BPEL already deals with headers that might be related to > "secondary > protocols" and that just happen to be part of an abstract > operation. Are > you suggesting we say something in the spec to disallow > those headers? > > Ugo > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Wednesday, November 19, 2003 11:43 AM > To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified > operation definitions > Agreed. I was referring more to the intent of Ron’s > rinsing proposal. > To repeat his second paragraph > > 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. > This suggests that the *source* of optional headers (“secondary > protocols”) is out of scope for BPEL, which should “work at a higher > level of abstraction.” > > In case it is not obvious, I should add that I am in > complete agreement > with the way Ron has characterized the issue. > > Satish > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Wednesday, November 19, 2003 11:19 AM > To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 77 - Under specified > operation definitions > > Satish, > > The concept of optional header needs to be better specified in the > context of Yaron's message. There are two cases: > > 1 - The optional header is defined in an abstract message > (this is the > case I used when raising this issue). > > 2 - The optional header is not defined in any part of the abstract > interface (this is not the case I exemplified when I filed > this issue, > and I prefer to keep it out of the discussion of the issue itself). > > Yaron's discussion about introspection does not apply to > case 1. In case > 1 BPEL does not need to concern itself with how to get to > the abstract > message: that is just part of the underlying binding > machinery. All BPEL > sees is the abstract message. Reaching that abstract > message is not any > more complicated for BPEL than reaching any other component of the > abstract operation. > > Ugo > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Wednesday, November 19, 2003 11:04 AM > To: Ron Ten-Hove; ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: 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.h tml) 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/le ave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]