Raw Notes from SCA-J concall on December 20th 2007

[Peter Walker <Peter.Walker@Sun.COM>]

Apologies for the raw notes. I'm about to vanish into cyber-silence. I will massage in the New Year where required.

Michael Rowley: Event Description:
US & Canada Toll Free: (866) 484-4232
International Dial-In Number: (702) 894-2358 ACCESS CODE:  960335

Chat room:
http://webconf.soaphub.org/conf/room/sca-j-TC

Agenda:
- Roll Call
http://www.oasis-open.org/committees/membership.php?wg_abbrev=sca-j

- Appointment of scribe. List attached below
- Agenda bashing
- Approval of minutes from previous meeting(s) http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/26649/raw%20text%20of%20chatroom.doc

2. Accepting new issues:

None submitted.

3 . Issues discussion

Issue #4: Dependency Reinjection

http://www.osoa.org/jira/browse/JAVA-4

There are two outstanding sub-issues:
A) does a reference represent the wire or the wire target (i.e. does it get invalid if the target changes, or is it a "smart" proxy)?
B) does the component context reflect wiring changes during the life time of the component scope?



Regarding the (A) Ron, Peter, and Henning came up with the following proposed assertions: 

1. Services have an address: Service Component Services have an SCA URI, otherwise bindings provide a URI or some equivalent addressing data.
2. Service reference instances are a client view to a service address: It consists of the service address and (if available) a conversation handle (e.g. an ID, a proxy) and interface information.
3. The address and interface association does not change over the life time of a service reference. An exchange (re-deployment) of the addressed service's implementation SHOULD not invalidate a Service reference instance. Technical constraints may however lead to a de-facto invalidation of service reference instances (e.g. cannot consume previously handed out data).

Or, in one paragraph: 

Services have an address, which can be an SCA URI in the case of a service component service or some other addressing data provided by a binding declaration. A service reference instance is a client view to a service address. It consists of the service address and (if available) a conversation handle (e.g. an ID, a proxy) and interface information. The address and interface association does not change over the life time of a service reference instance. An exchange (re-deployment) of the addressed service's implementation SHOULD not invalidate a Service reference instance. Technical constraints may however lead to a de-facto invalidation of service reference instances (e.g. cannot consume previously handed out data).

4. Adjourn

---------------------------------------------------------------
Rotating scribe list:

Martin Chapman Oracle Corporation
Jeff Mischkinsky Oracle Corporation
Peter Peshev SAP AG
Roberto Chinnici Sun Microsystems
Peter Walker Sun Microsystems
Sriram Narasimhan TIBCO Software Inc.
Pradeep Simha TIBCO Software Inc.
Scott Vorthmann TIBCO Software Inc.
Bryan Aupperle IBM
Michael Keith Oracle Corporation
Uday Joshi Oracle Corporation
---- scribed once -----
Anish Karmarkar Oracle Corporation
Mike Edwards IBM
Michael Beisiegel IBM
Ashok Malhotra Oracle Corporation
David Booz IBM
Simon Nash IBM
Jim Marino BEA Systems, Inc.
Sanjay Patil SAP AG
Jason Kinner Oracle
Ron Barack SAP AG (2nd time)

[10:09] Mike Edwards: I'm listening to music on the published #

[10:11] Pete Walker: I'll give it a try

[10:11] Pete Walker: I think that makes 9/15 - we are quorate

[10:12] Pete Walker: Pete Walker as scribe

[10:13] Pete Walker: Agenda bashing - only Hennings announcement as additional item

[10:13] Pete Walker: last meeting minutes motion Mike Edwards, second Michael Beisiegel app w/o

[10:14] Pete Walker: Extra agend aitem - Henning stepping down as co-chair, see email sent to list

[10:15] Simon Nash: can everyone not talking please mute

[10:16] Pete Walker: Henning mentions that Simon Nash is very willing to offer his name as new co-chair

[10:17] Pete Walker: Expressions of thanks by members to Henning for his work as co-chair to date

[10:18] Pete Walker: On Jan 10th election will be held as organized by chairs

[10:18] Pete Walker: On to issue 4

[10:20] Pete Walker: focus today on remaining sub-issue A

[10:20] Mike Edwards: I honestly believe that there is much more to be said about this, overall

[10:21] Mike Edwards: but perhaps it is best done as an addition to the SCA Assembly spec

[10:22] Pete Walker: As presented by Henning...1. Services have an address: Service Component Services have an SCA URI, otherwise bindings provide a URI or some equivalent addressing data.
2. Service reference instances are a client view to a service address: It consists of the service address and (if available) a conversation handle (e.g. an ID, a proxy) and interface information.
3. The address and interface association does not change over the life time of a service reference. An exchange (re-deployment) of the addressed service's implementation SHOULD not invalidate a Service reference instance. Technical constraints may however lead to a de-facto invalidation of service reference instances (e.g. cannot consume previously handed out data).

[10:25] Pete Walker: MikeR - what happens when service becomes invalid?

[10:28] Pete Walker: Simon - further questions about invalidity or incompatible update (service vs address)

[10:31] Pete Walker: MikeR - differentiation between service invalid vs service unavailable exceptions

[10:31] Michael Rowley: Previous suggestion (last meeting): If the wiring of a composite component causes a reference to be reinjected, any ServiceReference object that was acquired before the reinjection will still correspond to the target prior to the change. If the target service for a ServiceReference ever becomes invalid, then attempts to call business methods through that ServiceReference MUST throw InvalidServiceException.

[10:32] Mike Edwards: I think there is a need to spell out all these cases

[10:32] Mike Edwards: in some detail

[10:33] Michael Rowley: Yes, that is what we are trying to accomplish.

[10:36] Pete Walker: Simon - when do I have to check logical address vs physical address to disambiguate the two occurrences?

[10:37] Pete Walker: Henning - two addresses perhaps not helpful after all

[10:37] Pete Walker: MikeR - what does service reference really correspond to? logical or physical?

[10:40] Pete Walker: MikeE - prefers simple approach using physical address

[10:41] Pete Walker: MikeR - physical addresses will change when bindings change

[10:44] Pete Walker: discussion about how service reference remains valid if wire remains so

[10:48] Michael Rowley: The ServiceReference corresponds to the (logical) target service of the reference.  If that service is undeployed after the service reference is created then attempts to call business methods through that ServiceReference MUST throw InvalidServiceException.  If the target service is modified, then the service reference may or may not continue to work, depending on the runtime and the type of change that was made.  If it doesn't work, the exception thrown will depend on the runtime and the cause of the failure.

[10:48] Michael Rowley: [That is my suggestion]

[10:58] Pete Walker: clarification discussion around usage of SCA target and explicit binding URI usage in reference

[11:00] Michael Rowley: s/MUST/SHOULD/

[11:01] Michael Rowley: s/may or may not/MAY/

[11:03] Pete Walker: motion by Simon to accept MikeR's last suggestion/wording, second by Henning. Carried w/o

[11:03] Pete Walker: Adjourned