RE: [sca-bpel] RE: [Issue 38]: Is the 'MUST' in section 2.1.2 needed?

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

The Assembly spec uses the term "target
service" rather than "endpoint", and also uses the term
"target service address" for the actual location of a target
service (this is as close as we get to "endpoint")
so I suppose that might make the wording
something like:

"for a service, there must be a
fixed target address for the callback"

To cover your 3 cases:

1) Callback address is supplied via
configuration of the callback binding
2) Service is promoted and the configuration
of the higher level service provides a single Callback address
3) Service is connected only via a single
wire that uses the SCA binding so that the source of the wire provides
an unambiguous callback address.

I think that the case for a reference
is clearer.  All that is needed is that the reference is configured
with at least one target service.
I'm unclear as to whether more than
1 reference target is OK.  If it isn't, then that translates into
a restriction of the multiplicity of the reference to 1..1.
Otherwise the restriction is to 1..n
or 1..1.  But 0..x is not allowed.


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:	Mike Edwards/UK/IBM@IBMGB, OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date:	27/04/2009 14:50
Subject:	RE: [sca-bpel] RE: [Issue 38]: Is the 'MUST' in section 2.1.2 needed?

---

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

---

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