I'm certainly not wedded to the way I've suggested here.
It is tricky to find a way to state the requirement that is both clear and
accurate.
You suggested: "for a service, there must be a fixed set for the
endpoint of the callback". This is close. I
don't think it is a fixed set, but more like a fixed single endpoint.
However, I think that begs the question, since I'm not aware of any SCA spec
that has a precise definition for "endpoint" and how it might be
specified (I might be wrong, of course). I used the phrase "binding,
promotion and wiring" because I can think of a few ways that the clients
address might be known by the system:
1) The callback binding specifies an endpoint address
2) The service is promoted and some higher level componenty is
configured so that the client address is known (using (1) or (3)).
3) The service callback uses the SCA binding and there is only a
single wire to the service _and_ the system uses technology for the SCA binding
that allows it to guarantee that no client other than the one wired client will
connect to the service.
There may be other cases as well, but I suspect that the phrase
of "binding, promotion and wiring" is broad enough to cover them.
I thought about trying to find a way to state a use case for
this restriction as part of the spec text. The use case is that it should
be possible to assign from the partner role of the partner link as soon as the
partner link's scope is initialized. The result of such an assignment
should be to move a useful EPR to the target of the assign. I found it difficult
to state the use case, and it is the same use case as for BPEL's @initializePartnerRole
attribute even without SCA, so I decided it probably doesn't belong in this
spec.
Michael
From: Mike Edwards
[mailto:mike_edwards@uk.ibm.com]
Sent: Monday, April 27, 2009 6:41 AM
To: OASIS BPEL
Subject: [sca-bpel] RE: [Issue 38]: Is the 'MUST' in section 2.1.2
needed?
Folks,
I am still left
feeling that the whole story is not being given from an SCA perspective here.
Perhaps an example is called for.
What I think I
am missing is what demands this set of requirements place on the guy assembling
a component which uses
a BPEL
implementation with this characteristic.
I am having a
hard time translating "the partner link's partner role will be initialized
as soon as the partner link becomes active"
into something
that is meaningful to an assembler.
If it means
something like "for a service, there must be a fixed set for the endpoint
of the callback" and "for a reference, the reference
must be wired
to a service", then I think that we should say so. If these words
are not the right ones, I'd appreciate it if someone
who understands
@initializePartnerRole better could come up with a better set of words.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
|
Michael
Rowley <michael.rowley@activevos.com>
|
To:
|
Anish
Karmarkar <Anish.Karmarkar@oracle.com>, OASIS BPEL
<sca-bpel@lists.oasis-open.org>
|
Date:
|
23/04/2009
21:44
|
Subject:
|
RE:
[sca-bpel] [Issue 38]: Is the 'MUST' in section 2.1.2 needed?
|
I took an action to try rewriting this. Here is a version that
separates out the reference side from the servic side. It has a lot of
redundancy this way, so immidiately below it I have a second try that attempts
to combine the requirements for services and references.
-----
2.1.2 Handling @initializePartnerRole
If a partner link marked with initializePartnerRole="yes" maps to
a reference in the component type, then any component that uses this business
process as an implementation MUST configure the corresponding reference using
binding, promotion and wiring configuration that guarantees that the partner link's
partner role will be initialized as soon as the partner link becomes active.
The component type reference for a partner link that is marked as
initializePartnerRole="yes" MUST NOT specify
wiredByImpl="true".
SCA has no concept of multiplicity on services, but partner links that map
to services can still be marked with an initializePartnerRole attribute.
[SBPEL2014] If initializePartnerRole="yes" is specified for a
partner link and the partner link maps to a service in the component type, then
any component that uses this business process as an implementation MUST
configure the corresponding service using a callback binding, promotion and
wiring that guarantees that the partner link's partner role will be initialized
as soon as the partner link becomes active.
------
2.1.2 Handling @initializePartnerRole
If a partner link is marked with initializePartnerRole="yes" then
any component that uses this business process as an implementation MUST
configure the corresponding service or reference using binding, promotion and
wiring configuration that guarantees that the partner link's partner role will
be initialized as soon as the partner link becomes active. If the partner
link is mapped to a service, the callback binding would be the relevant binding
for this requirement. The the partner link is mapped to a reference then
the component type ype reference MUST NOT specify wiredByImpl="true".
Michael
-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Thursday, April 23, 2009 3:24 AM
To: OASIS BPEL
Subject: Re: [sca-bpel] [Issue 38]: Is the 'MUST' in section 2.1.2 needed?
This is now issue 38: http://osoa.org/jira/browse/BPEL-38
Anish Karmarkar wrote:
> Title: is the 'MUST' in section 2.1.2 needed?
>
> Target: SCA BPEL C&I
>
> Description:
> This issue came up as a result of discussion of test assertion
SBL-TA-2012.
> The test assertion, which is based on SBPEL2014, is not really
testable.
> OR to be more precises perhaps could be testable for some corner
cases,
> which the SCA BPEL TC (very likely) is not going to test.
> The problem is that the requirement states that the binding configured
> must know the identity of the partner as soon as the PL becomes
active.
> It is not clear how that would happen for the bindings that we define.
> It seems to assume that the binding and the port associated with the
> binding is visible only to other SCA references. It is not clear
why/how
> this would be true.
> A related minor issue is that it talks about the 'identity' of the
> partner. Does it really mean 'identity' or the 'location'? The
> parenthetical statement seems to indicate that it is the location, not
> identity.
>
> Proposal:
> Two possible solutions:
> 1) If this is indeed a corner case which we want to enable but not
test,
> we could s/MUST/SHOULD/
> 2) If this is a corner case that we don't intend to test nor do we see
> it serve a useful purpose then we should just get rid of section 2.1.2
>
> -Anish
> --
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS
at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless
stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU