[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] NEW ISSUE: Title: The algorithm for deciding whethera partnerLink is a service or a reference needs to be deterministic
Per the issues process that we agreed on, during the last f2f: A new issue will not be discussed till it is assigned a number. Once it is assigned a number that number will be included in the subject so that we can search for discussion on a particular issue. I would prefer that when the issues editor assigns a number he would reply to the 'NEW ISSUE' email with the issue number and a modified subject containing the issue number. Given that we haven't figured out issue mgmt (JIRA) yet, this is not possible right now. Which is a little frustrating. Martin: do you know if we have any resolution from the OASIS admin regd. JIRA? Thanks. -Anish -- Alex Yiu wrote: > > Hi, Danny, > > The way that I read that section is: the logic there is quite > deterministic already: > > If a partnerLink can be determined as a service, > then that is a service ... > If _not_, > if reference case#1, then ... > if _not_ #1 and if #2, then ... > if _not_ #1 or #2 and if #3, then .. > if _not_ #1, #2, #3, then ... > > > Let me give you an example. If a partnerLink is used in both invoke and > receive activities without any logical ordering enforced in the process > definition, _it will go into the reference case_. Because, the static > analysis CANNOT determine the partnerLink is a service. > > My thought is: if different implementation come out a different > componentType definition after static analysis of the same process, it > sounds to me that it is more like a bug in an implementation, not the > case of the spec being unclear. (unless you can give me a concrete > example of our existing rules are not sufficient) > > And, I think if users do not want to rely on static analysis of a BPEL > process to calculate the componentType, it may be a better idea to ask > users to supply an explicit componentType artifact. (That is an issue > raised by Anish.) > > > Thanks! > > > Regards, > Alex Yiu > > > Danny van der Rijn wrote: >> TARGET: SCA C+I WS-BPEL spec, General >> >> DESCRIPTION: Section 2.1 currently states "If a static analysis of the >> process determines that it is possible that the first message for a >> partner link will be received in a <receive> activity, the <onMessage> >> element of a <pick> activity or the <onEvent> element of an event >> handler then the partner link has a corresponding SCA service in the >> component type." >> I have concerns that this will leave cases where one vendor can make >> such determination, where another vendor, with a less sophisticated >> static analysis can not. This will leave the algorithm >> implementation-dependent. The goal of the algorithm is to produce a >> component type from a BPEL file in a deterministic way, with no >> external dependencies. >> >> >> PROPOSAL: none >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]