[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 44 - portType is duplicated on Invoke activity and partnerLinkType
Satish, The problem with the second example is that because BPEL doesn't require that every new instance of a process have a unique URI so it may not be possible to express at the BPEL level the full 'name' for a process instance. This is why, in those cases, one is forced to play the games I specified. Is the following an accurate portrayal of your proposed solution for case #2? <partnerLinkType name="BillProcessing"> <role name="Receiver"> <portType name="foo:BillProcessingPortType/> </role> </partnerLinkType> <partnerLinks> <partnerLink name="ProcessBill" partnerLinkType="foo:BillProcessing" myRole="Receiver"/> </partnerLinks> <invoke partnerLink="ProcessBill" role="Receiver" operation="billsending" inputVariable="TheBill"/> Before I discuss this proposal I want to make sure I understand you correctly. BTW, do you actually object to the idea of allowing for the use of the role attribute on invoke? Yaron > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Monday, August 11, 2003 11:09 PM > To: ygoland@bea.com; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated on Invoke > activity and partnerLinkType > > > I don't get the third (invisible intermediary) scenario. The > sample you > have below works for the first but not the second (createInstance) one > unless you interpret the role="Receiver" in an instance agnostic way, > which I think would be extraordinarily confusing. How do you prevent > the intra-instance "cross flow" communications from leaking to other > instances? > > Why not just create two partnerLinks with the same portType > (I don't see > the use of the two distinct protTypes in your example) -- one for > sending/invoking (with only partnerRole) and the other for receiving > (with only myRole), and let deployment/binding create the circuit as > appropriate? > > Satish > > > -----Original Message----- > From: Yaron Goland [mailto:ygoland@bea.com] > Sent: Monday, August 11, 2003 5:20 PM > To: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated on Invoke > activity and partnerLinkType > > There are at least three real world scenarios I can think of > [1] where a > process would want to call itself. If I understand the proposal > correctly then this is how a process would go about calling itself: > > <partnerLinkType name="BillProcessing"> > <role name="Receiver"> > <portType name="foo:BillProcessingPortType/> > </role> > <role name="Sender"> > <portType name="foo:BillConfirmationPortType/> > </role> > </partnerLinkType> > > <partnerLinks> > <partnerLink name="ProcessBill" > partnerLinkType="foo:BillProcessing" > myRole="Receiver"/> > </partnerLinks> > > <invoke partnerLink="ProcessBill" role="Receiver" > operation="billsending" inputVariable="TheBill"/> > > So assuming the partnerLink ProcessBill hasn't been used > before so that > the partner endpoint reference hasn't been previously > instantiated then > in the example both partners in the ProcessBill partnerLink would have > the same endpoint reference which would be the endpoint reference > belonging to the process itself. > > Is that right? > > Yaron > > [1] Here are the three main scenarios I know of for why a > process would > call itself: > > Inter-Flow Communication - If two flows in the same process want to > share information they either have to use shared variables or > they have > to send messages to each other. Shared variables are a nasty business > which give even experienced programmers a headache. Just sending > yourself messages is usually easier. > > Kicking off New Process Instances - Depending on the URI model a BPEL > process is using (something left unspecified by BPEL) the only way to > create a new process instance of the same type as yourself may be to > call a 'createInstance' enabled receive activity on yourself. > An example > of this situation is a system where all instances of a > process have the > same URL but different HTTP cookies. > > Benefiting from Bad Intermediary Design - This is a pet peeve of mine > but unfortunately people constantly have the brilliant 'new' idea of > providing 'invisible' services via intermediaries. Router based HTTP > proxies, firewalls and nats are all examples. In these cases network > based entities provide services as a consequence of routing messages > rather than being directly addressed. For example, one could imagine a > logging intermediary that automatically logs, possibly with > some sort of > cryptographically secure timestamp, when it routed a > particular message. > If a web service wants some information logged it couldn't > just send the > logger a message since the logger is supposed to be > 'invisible'. Instead > the web service would have to actually send out a message into the > network that it knew would eventually be routed through the logger. > However such a message would need a destination (you can't route a > message that isn't going anywhere) which in this case would be the Web > Service itself. Of course you better pray that your application server > doesn't do you a 'favor' by short circuiting the web stack and sending > you your own message locally. > > (Web Service)---->("Invisible" Logger Intermediary)--| > /-\ | > | | > ------------------------------------------------ > > -----Original Message----- > From: Marin, Mike [mailto:MMarin@filenet.com] > Sent: Monday, August 11, 2003 1:23 PM > To: Satish Thatte; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated on Invoke > activity and partnerLinkType > > > Satish, > > I do agree that it is unlikely that a process will call > itself, but the > specification do allow it, because you do specify the port type in the > Invoke. So you could specify the one that refers to the > process itself. > In order to retain that functionality, I did proposed to > optionally use > the role instead. But, I will be happy to modify my proposal to just > remove the port type form the Invoke. > > -- > Regards, > Mike Marin > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Monday, August 11, 2003 1:01 PM > To: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated on Invoke > activity and partnerLinkType > > I agree with the analysis and the proposal except that I don't see the > need for the optional role specification. When would a > process need to > invoke itself? And in the rare cases when it does, the binding of the > portLinks to create the cycle could be done externally relative to the > process definition, could it not? > > Satish > > > > > From: ws-bpel issues list editor > [mailto:peter.furniss@choreology.com] > Sent: Thursday, August 07, 2003 3:41 AM > To: wsbpel@lists.oasis-open.org > Subject: [wsbpel] Issue - 44 - portType is duplicated on > Invoke activity > and partnerLinkType > > This issue has been added to the wsbpel issue list. The issues list is > posted as a Technical Committee document to the OASIS WSBPEL > TC pages on > a regular basis. The current edition, as a TC document, is the most > recent document with the title in the "Issues" folder of the WSBPEL TC > document list - the next posting will include this issue. The list > editor's working copy, which will normally include an issue when it is > announced, is available at this constant URL. > Issue - 44 - portType is duplicated on Invoke activity and > partnerLinkType > Status: open > Date added: 5 Aug 2003 > Submitter: Marin, Mike > Date submitted: 01 August 2003 > Description: The Invoke activity requires a partnerLink and a > portType. > However the partnerLink refers to a partnerLinkType, which > also includes > the portType. Therefore the portType in the Invoke is redundant. > A partnerLinkType do refer to a maximum of two portTypes. > Assuming that > a process does not invokes itself, then the Invoke refers to the > partnerRole, not myRole, so there is only one possible portType, for > that Invoke. In the other hand, if we assume the process can invoke > itself, then it will be better to specify the role in the Invoke > activity instead of the portType, because role has process semantics > instead of the portType. > Submitter's Proposal: I propose that portType on the Invoke > activity be > removed and instead an optional role be included instead. > When the role > is specified, it must correspond to one of the two roles > defined in the > partnerLink. If the role is not specified the partnerRole in the > partnerLink should be assumed. > Changes: 5 Aug 2003 - new issue > > > > To comment on this issue, please follow-up to this announcement on the > wsbpel@lists.oasis-open.org list (replying to this message should > automatically send your message to that list), or ensure the subject > line as you send it starts "Issue - 44 - [anything]" or is a reply to > such a message. > To add a new issue, see the issues procedures document. > -------------------------------------------------------------- > ------- To > unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org For > additional commands, e-mail: wsbpel-help@lists.oasis-open.org > >
<<attachment: winmail.dat>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]