RE: [sca-j] ISSUE 4 - Dependency reinjection

Simon,

A dose of <mje>Edwards
commentary</mje>

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:  

Simon Nash/UK/IBM@IBMGB

30/01/2008 15:29

To

"OASIS Java" <>

cc

Subject

RE: [sca-j] ISSUE 4 - Dependency reinjection

Now that we have agreed to permit reinjection into
conversational-scoped 

instances, this (re)raises the question of callback reinjection.

We had decided not to permit this at all, based on the earlier decisions

to limit reinjection to composite-scoped instances only, and to prohibit

callback injection into composite-scoped instances.

The reversal of the first of these decisions means that we need to 

consider the case of a conversational-scoped instance with a bidirectional

interface that is invoked by two different callers using the same 

application-generated conversationID.  Section 6.6.1 gives some hints
that 

it is possible, without saying so explicitly.

We could address this in (at least) four ways:

1. Prohibit callback injection for conversation-scoped components, as we

have done for composite-scoped components.  This seems bad because
it 

penalises a common case (calls from one client per conversational 

instance) in favour of a rare case (calls from multiple clients per 

conversational instance).

2. Say that in this case, callback reinjection MUST be done.  This
goes 

against the "big MAY" for other types of reinjection.  It
can also lead to 

non-deterministic behavior in multithreaded scenarios.

3. Say that in this case, callback reinjection MUST NOT be done.  This

puts the burden on developers to know that they should avoid using 

injected callbacks if there is a possibilty that the component will be

invoked by multiple clients within the same conversation.

4. Say that in this case, callback reinjection MAY be done.  This
has a 

similar effect to option 3. 

To start the ball rolling, I suggest that we adopt option 3.  What
do 

others think?

<mje>The simple case
for a conversation scoped component with a callback is that 

it has exactly one client.
 This will be the 99% case, in my opinion.  This is dealt with

by a simple injection of
the callback at the start of the conversation.

Any case which might imply
the need for reinjection is going to be a rare case - ie

where the client in the
same conversation changes during the conversation.

I'm in favour of not doing
anything to support this.  No reinjection.  

If the component wants to do anything about it, it can use the (more complex)

context calls to discover
if the client has changed and then act accordingly.

This corresponds to your
option 3.</mje>

<mje>I note that
the default behaviour of most conversation scoped components

will thus be to ignore
a change of client during the progress of a single

conversation.  The
implication of this is that it will not be possible to change

the client in reality,
since the service will always call back to the original client.</mje>

    Simon

Simon C. Nash, IBM Distinguished Engineer

Member of the IBM Academy of Technology

Tel. +44-1962-815156  Fax +44-1962-818999

Simon Nash/UK/IBM@IBMGB 

15/01/2008 22:32

To

"OASIS Java" <>

cc

Subject

RE: [sca-j] ISSUE 4 - Dependency reinjection

Two approved motions from last week's call were not incorporated into the

v3 version of the table.  These were:

1. ComponentContext.getServiceReference() should be always in sync with

the current configuration of the domain

2. no objections to dropping the column, as long as long as the text typed

by Michael is present

I have made these changes in the v4 version (attached).

    Simon

Simon C. Nash, IBM Distinguished Engineer

Member of the IBM Academy of Technology

Tel. +44-1962-815156  Fax +44-1962-818999

"Michael Rowley" <> 

10/01/2008 21:19

To

"OASIS Java" <>

cc

Subject

RE: [sca-j] ISSUE 4 - Dependency reinjection

 

Here is an updated table, based on the last TC meeting.

 

Michael

 ---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and 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

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and 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

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and 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

Dynamic Modification Behavior v3.xls

Dynamic Modification Behavior v4.xls