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: [wsbpel] Issue 44 - Summary so far.


Even with outbound ops it is *possible* to infer the right portType *if*
one assumes that the operation names will not be duplicated within the
two portTypes in the partnerLink.  There is the edge case of identical
req/resp and sol/resp operations in the partnerRole and myRole portTypes
which would cause ambiguity.

But this does bring in the issue of staying compatible with the WSDL 1.2
MEP set which at the moment looks like including outbound ops.

Another reason to rethink the resolution of this issue.

-----Original Message-----
From: Liu, Kevin [mailto:kevin.liu@sap.com] 
Sent: Thursday, October 16, 2003 3:31 PM
To: 'Chris Keller'; Satish Thatte; 'Marin, Mike';
'wsbpel@lists.oasis-open.org'
Cc: 'ygoland@bea.com'
Subject: RE: [wsbpel] Issue 44 - Summary so far.

Outbound operations are not supported in the current draft. I don't
expect that it will be support in the TC's first release, but I don't
see it justified for us to declare that they will never be supported
either.

Best Regards, 
Kevin 


-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com] 
Sent: Thursday, October 16, 2003 3:07 PM
To: 'Satish Thatte'; Liu, Kevin; 'Marin, Mike';
wsbpel@lists.oasis-open.org
Cc: ygoland@bea.com
Subject: RE: [wsbpel] Issue 44 - Summary so far.

The only reason to include portType that I can see is to handle
solicit-response and notify operation definitions where the "role" is
somewhat reversed from most operation definitions.  Normally for
request-response and one-way operations then receives, replies and
onMessage constructs could assume the context of the myRole role's
portType and the invokes are in the context of the partnerRole role's
portType.  Do we support solicit-response and one-way
portType/operations?  If we do support them then we need to include
portType to avoid conflicts between operation names in the partnerRole
role's portType and the myRole role's portType.  In addition we should
have an example in the specification where a portType defines a
solicit-response so we can highlight this case.  Currently there are no
solicit-response or notify examples in the specification.

Chris

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Thursday, October 16, 2003 2:06 PM
To: Liu, Kevin; Marin, Mike; wsbpel@lists.oasis-open.org
Cc: ygoland@bea.com
Subject: RE: [wsbpel] Issue 44 - Summary so far.

It is true that we have in fact made other decisions recently that
maintain some redundancy, e.g., in resolving Issue 36.  

We would need to change this for all constructs that use patrnerLink and
portType, including invoke, receive, pick and event handlers, and of
course all the examples.  Now that I look at the way the resolution is
worded this is not clearly stated.  That alone is justification for
reopening the issue or asking for clarification.  But this issue is
currently resolved.  We do not have a process for reopening it.  If we
want to reverse the decision we would have to open a new issue.  Opening
a new issue would be justification for not doing the editorial work if
we may have to undo it.

Opinions?  Yaron, what is your take from an issues process perspective?

Satish 

-----Original Message-----
From: Liu, Kevin [mailto:kevin.liu@sap.com] 
Sent: Thursday, October 16, 2003 7:07 AM
To: 'Marin, Mike'; 'wsbpel@lists.oasis-open.org'
Cc: Satish Thatte; 'ygoland@bea.com'
Subject: RE: [wsbpel] Issue 44 - Summary so far.

Hi guys,

I need a few clarifications/confirmations before I start to really
change the spec to reflect this resolution.

1. Does it really help to remove the portType attribute? 

After the removal, the new syntax looks like

<invoke partnerLink="ncname" operation="ncname"
    inputVariable="ncname"? outputVariable="ncname"?
    standard-attributes>

It does need the portType information to make operation, input, output
meaningful. It's true that the portType info is inferable from
partnerLink, but what harm does it cause to duplicate it here if we make
it clear that the portType here must be consistent with the portType in
parterLink? 

2. What's the impact on other constructs?
If we change it for invoke, same should also apply to <receive> (and
maybe more?). Does this resolution cover that?

Let alone the non-trivial editorial work - almost all the example codes
in the spec need to be changed to get rid of the portType attribute, I
am concerned about the uncertain impact on <receive> and maybe other
constructs and the "corner cases" left uncovered (issue 52 is still
open).  

It seems to me we could go for a simpler solution  - just add
clarification text to <invoke> definition and make it clear that the
invoke@portType must be consistent with partnerlink.

Not intended to reopen the issue, but just want to make sure that the
above concerns have already been considered

Best Regards, 
Kevin 


-----Original Message-----
From: Marin, Mike [mailto:MMarin@filenet.com] 
Sent: Tuesday, August 19, 2003 12:11 PM
To: ygoland@bea.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 44 - Summary so far.


To keep things clean, I will remove proposal two from issue 44, and let
keep issue 52 for calling yourself. That way there is only one proposal
for issue 44 as follows:

Issue 44 - Proposal: Just remove the portType from the invoke activity
and use the portType that corresponds to the partnerRole in the
partnerLink. This covers most if not all the use cases. With the only
exception of a process that wants to call itself, which is discussed by
issue 52.

--
Regards,
Mike Marin

-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Tuesday, August 19, 2003 11:55 AM
To: Marin, Mike; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 44 - Summary so far.

Hum... maybe I shouldn't have created Issue 52 and instead should have
kept it part of Issue 44? I thought Issue 44 would just address the
issue of removing the portType and that issue 52 would address how to
deal with calling yourself. Because, given your summary below, clearly
52 (http://lists.oasis-open.org/archives/wsbpel/200308/msg00158.html)
should be a 3rd option.

> -----Original Message-----
> From: Marin, Mike [mailto:MMarin@filenet.com]
> Sent: Monday, August 18, 2003 5:40 PM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue 44 - Summary so far...
>
>
>
> This issue deals with the fact that in the current syntax 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. So far, there is no
> disagreement on this analysis.
> 
> There are two possible solutions (or proposals):
> 
> 1- (proposal 1): Just remove the portType from the invoke activity and
> use the portType that corresponds to the partnerRole in the
> partnerLink.
> This covers most if not all the use cases. With the only
> exception of a
> process that wants to call itself, in which case you will
> need to create
> another partnerLink (using the same partnerLinkType) and use
> it instead.
> So, in this case you end with two partner links.
> 
> 2- (proposal 2): Remove the portType from the invoke activity, but add
> an optional role. 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.
> 
> With this second proposal, in most cases the syntax will look exactly
> the same as with the first proposal. But, if a process needs to call
> itself, instead of adding a partner link, it just adds a role to the
> invoke activity.
> 
> Both solutions are similar and better than the current
> syntax. The only
> real difference is the optional role on the invoke activity
> to preserve
> the functionality currently specified, but that seems to be uncommon.
> 
> Regards,
> Mike Marin
> 
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org



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_workgr
oup.php.







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