[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Raw chat of 3/7, Fri (1pm - 3pm) Mg
Sanjay: scribe: Sanjay
Sanjay: Topic:Issue 25: http://osoa.org/jira/browse/JAVA-25
Sanjay: Topic: Issue 31 - http://osoa.org/jira/browse/JAVA-31
Sanjay: Simon describes the proposal in the issue text
Sanjay: Simon describes the proposal in the issue text
Sanjay: MikeE: we need more clarification than what is addressed by the proposal
Sanjay: MikeE: we need more clarification than what is addressed by the proposal
Sanjay: MikeE: ServiceRef.geConversationID seems to be useful for future conversations
Sanjay: ... there are specific points for calling setConversaionID()
Sanjay: MichaelR: Sometimes conversational semantics are passed through the bindings e.g. ws-rx, where the service provider dreams up the conversation-id
Sanjay: ... you can't set the conversation id until after the first call
Sanjay: Sanjay: you could conduct the sequence creation handshake in advance of sending out the first business message
Sanjay: Anish: it's the binding runtime's decision to get a new id or use an existing. nevertheless the application wouldn't know until the first call is made.
Sanjay: MikeE: Why do we allow a client to set conversation-id?
Sanjay: MichaelR: semi-objects to removing client side conversation-id setting
Sanjay: ... subject to support for conversation propagation
Sanjay: Anish: conversation propagation we talked about was limited to composite
Sanjay: MichaelR: thinks it applies to component
Sanjay: Simon: client may want to use the id of an existing ongoing conversation
Sanjay: Anish: How would the conversation propagation work when there is no target on reference? Is the issue about both setting and gettting?
Sanjay: Jim: Can we pass the proxy instead of conversation id?
Sanjay: MichaelR: we can't support conversation propagation with that
Sanjay: MikeE: When a service is not conversational, how does client send conversation-id? (needed by the diamond use case)
Sanjay: MichaelR: like the idea to remove conviersation id get/set ability but instead support conversation propagation
Sanjay: Jim: supporting setConvesationID may require a global registry with routing info
Sanjay: Jim: supporting setConvesationID may require a global registry with routing info
Sanjay: MichaelR: need not be global
Sanjay: ... proposal clarifies the semantics and need not be simplifying
Sanjay: simon: motion to resolve issue 31 with proposal described in jira
Sanjay: seconded by DaveB
Sanjay: MikeE: there is text required to describe the times when you are allowed to make some of the calls outlined in the proposal
Sanjay: SimonN: accepts MikeE's friendly amendment to - clarify that ServiceReference.set/getConversationID() is used only for future conversations
Sanjay: MikeE: need to clarify that 'get' returns what was 'set'
Sanjay: MikeE: Replace 'ServiceReference.getConversation().getConversationID()' with 'getConversationID() on the current conversation object'
Sanjay: MichaelR asks for any objections and edits the proposal text in JIRA
Michael Rowley: Motion:
Michael Rowley: Replace lines 363-367 with the following:
Whether the conversation ID is chosen by the user or is generated by the system, the client
may access the conversation ID by calling getConversationID() on the current conversation object.
Replace lines 780-781 with the following:
getConversationID() - Returns the id supplied by the user that will be associated with
future conversations initiated through this reference, or null if no ID has been set by the user.
lines 782-785 section 7.4 ServiceReference
setConversationID(Object conversationId) - Set an ID, supplied by the user, to associate with any _future_ conversation
started through this reference. If the value supplied is null then the id will be generated
by the implementation. Throws an IllegalStateException if a conversation is currently
associated with this reference. The infrastructure MUST _not_ call this method with system generated conversationIDs.
Michael Rowley: Next attempt:
Michael Rowley: Replace lines 363-367 with the following:
Whether the conversation ID is chosen by the user or is generated by the system, the client
may access the conversation ID by calling getConversationID() on the current conversation object.
Replace lines 780-781 with the following:
getConversationID() - Returns the id supplied by the user that will be associated with
future conversations initiated through this reference, or null if no ID has been set by the user.
lines 782-785 section 7.4 ServiceReference
setConversationID(Object conversationId) - Set an ID, supplied by the user, to associate with any _future_ conversation
started through this reference. If the value supplied is null then the id will be generated
by the implementation. Throws an IllegalStateException if a conversation is currently
associated with this reference.
Sanjay: Motion carried unanimously. Issue 31 resolved.
Sanjay: Topic: Issue 25: http://osoa.org/jira/browse/JAVA-25
Sanjay: Simon: in a bidi interacion, whether or not conversationality of forward direction is applied to backward direction?
Sanjay: MichaelR: In bidi+non-conv, all callbacks are routed to the same client instance
Sanjay: Simon: Being explicit about convesationality will be better
Sanjay: Simon: non-conv fwd + non-conv callback is not allowed in MR proposal
Sanjay: MikeE: If client is 'stateless' you will get non-conv callback
Sanjay: Anish: we are mixing conversational declaration on the interface with the scope
Sanjay: MichaelR: for 'non-conv fwd + non-conv callback' and 'conv fwd + non-conv callback', client still needs to send callback epr
Sanjay: Simon: I can do what you can do, and I can also do what I can do better
Sanjay: discussion and agreement that both the proposals do not limit what can be the scope of client
Sanjay: Anish: Is the correlation information for callback and conversation same?
Sanjay: ... client and service may be using different implementation technologies
Sanjay: MichaelR: combination of callback and conversation-id is a possibly additional simplification
Sanjay: Simon: both MichaelR and I feel that there should be one id
Sanjay: long, many conversations with whiteboarding, etc... that scribe could not capture
Sanjay: long, many conversations with whiteboarding, etc... that scribe could not capture
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]