OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Raw Chat from F2F day 1


[I didn’t realize that Jim had only sent this to me and not the whole list.]

 

michael beisiegel: good morning, is there a callin number

anonymous morphed into Jim Marino

Mike Edwards: 9.00 - 9.15 Welcome

Roll call

Appointment of scribe

Agenda bashing

Approval of minutes http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27482/SCA%20Java%20Minutes%202008-02-28.doc

 

9.15 - 10.30 Accepting new issues

Issues discussion

JAVA-1 Accessing SCA Service from non-SCA component code

 

10.30 - 10.45 Break

 

10.45 - 12.00 Issues discussion

JAVA-25 Callback Simplification

 

12.00 - 12.30 Lunch (sandwiches provided)

 

12.30 - 2.15 Issues discussion

JAVA-19 Redirecting Callbacks

JAVA-25 Callback Simplification (contd)

JAVA-10 State sharing between ServiceReference and type-safereference

 

2.15 - 2.30 Break

 

2.30 - 4.15 Issues discussion

JAVA-23 Asynchronous Client interface to Synchronous Service not well described

 

4.15 - 4.30 Break

 

4.30 - 6.00 Issues discussion

JAVA-12 Relation between conversational annotation and scope conversation

JAVA-17 A hole in the algorithm of introspecting property/referencefrom an unannotated impl class

JAVA-21 Clarify Request Scope lifetime

JAVA-22 When is a RequestContext available?

 

6.00 Adjourn

Mike Edwards: Item 1. Agenda Bashing

Mike Edwards: Michael R: Should the agenda items be rearranged?

Mike Edwards: Particularly should we start with JAVA-1?

Mike Edwards: MichaelR would like to add a discussion at the end of today about Java-15

Mike Edwards: Sanjay would like to discuss Java-28

Mike Edwards: Simon - ideally we need a response from OASIS staff regarding Java-28

Mike Edwards: but we could make a decision and push the OASIS staff to agree with the decision

Mike Edwards: Modify the agenda to add Java-15 and Java-28 at the end of the day

Mike Edwards: Remove all the items from 4:30 to tomorrow

Mike Edwards: ie Java-12, Java-17, Java-21, Java-22

Mike Edwards: Item 2. Minutes from Previous Meeting

Mike Edwards: Approved without objection

Mike Edwards: Item 3. New Issues

Simon Nash: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200803/msg00002.html

Mike Edwards: 1. Issue Java-XX : "Process Scope"

Mike Edwards: Michael R outlines the issue, raised in this email:

Mike Edwards: http://lists.oasis-open.org/archives/sca-j/200803/msg00002.html

Mike Edwards: Mike E moves to open the issue

Mike Edwards: Dave B seconds

Mike Edwards: This is Java - 30

Mike Edwards: Issue #30 is opened without ojection

Mike Edwards: s/objection

Mike Edwards: 2. Issue Java-31

Mike Edwards: http://www.osoa.org/jira/browse/JAVA-31

Michael Rowley: http://www.osoa.org/jira/browse/JAVA-31

Mike Edwards: "Semantics of ServiceReference.getConversationID()"

Mike Edwards: Simon N outlines the problem

Mike Edwards: Dave B moves to accept the issue

Mike Edwards: Simon N seconds

Mike Edwards: Issue 31 opened without objection

Mike Edwards: Item 4. Existing Issues.

Mike Edwards: 1) Java-1 : Accessing SCA Services from non-SCA component code

Mike Edwards: http://www.osoa.org/jira/browse/JAVA-1

Mike Edwards: Ron Barack presents a discussion based on a set of slides

Mike Edwards: The slides are on the Java email list:

Mike Edwards: http://lists.oasis-open.org/archives/sca-j/200803/msg00020.html

Mike Edwards: <Discussion of the usecases>

Mike Edwards: First usecase, where the "unmanaged code" is "fully outside and SCA container"

Mike Edwards: s/and/an

Mike Edwards: Second case where you are "in container" - prinipally "in JVM" or "in process"

Mike Edwards: Proposal to provide existing SCA APIs and allow access to a ComponentContect object

Mike Edwards: s/ComponentContect/ComponentContext

Mike Edwards: <Debate about whether there is a real need for this special case/cases>

Mike Edwards: Argument for the benefits of the "halfway house"

Mike Edwards: Michael R: Do people think that this area deserves significant further investigation:

Mike Edwards: a) "Just an API" (no SCDL, etc)

Mike Edwards: b) Concept of "implementation.client" to which "some code" can point

Mike Edwards: c) "Introduce a new component into existing or new domain" API

anonymous morphed into Ron Barack

Mike Edwards: Straw poll on whether these possibilities should be followed or not

Mike Edwards: a) 9 + 2 vote for "worth investigating"  /  0 votes against

Mike Edwards: b) 7 + 1 vote for "worth investigating" / 0 votes against

Mike Edwards: c) 4 + 2 vote for "worth investigating" / 4 votes against

Mike Edwards: Michael R: So this indicates a rough prioritization

Mike Edwards: Action:  Simon N, with help from Ron, Peter, Jim to flesh out b

Mike Edwards: Action:  Mike E will look at c)

Mike Edwards: Action: Dave B to work with Michael R on a)

Mike Edwards: 2) Java-25 - Callback Simplification

Mike Edwards: Proposal sent to the list here:

Mike Edwards: http://lists.oasis-open.org/archives/sca-j/200803/msg00014.html

Mike Edwards: (erroneously called Issue 2)

Michael Rowley1:

public interface ComponentContext {

    String getURI();

    <B, R extends CallableReference<B>> R cast(B target) throws IllegalArgumentException;

    <B> B getService(Class<B> businessInterface, String referenceName);

    <B> ServiceReference<B> getServiceReference(Class<B> businessInterface, String

 

referenceName);

    <B> B getProperty(Class<B> type, String propertyName);

    <B> ServiceReference<B> createSelfReference(Class<B> businessInterface);

    <B> ServiceReference<B> createSelfReference(Class<B> businessInterface, String serviceName);

    RequestContext getRequestContext();

}

 

public interface RequestContext {

    Subject getSecuritySubject();

    String getServiceName();

    <B> CallableReference<B> getServiceReference();

    <CB> CB getCallback();

    <CB> CallableReference<CB> getCallbackReference();

}

 

public interface CallableReference<B> {

    B getService();

    Class<B> getBusinessInterface();

    boolean isConversational();

    Object getCallbackID();

}

 

public interface ServiceReference<B> extends CallableReference<B> {

    Object getConversationID();

    void setConversationID(Object conversationId) throws IllegalStateException;

    void setCallbackID(Object callbackID);

    Object getCallback();

    void setCallback(Object callback);

}

 

public interface Conversation {

    Object getConversationID();

    void end();

}

Mike Edwards: ....is the current API

Mike Edwards: Michael R outlines the proposal

Mike Edwards: "bidirectional interface" implies passing a conversation ID being passed out of band with every call

Mike Edwards: ie not in the business data / not in the interface

Mike Edwards: - service provider MUST use the callback proxy (injected or obtained)

Mike Edwards: - bidirectional interfaces work the way currently described for "conversational callbacks"

Mike Edwards: if the (outbound) interface is not conversational, then there is a new conversation ID for each outbound call

Mike Edwards: - when the client receives a callback in this circumstance, it gets this coversation ID

Mike Edwards: <discussion>

Mike Edwards: Michael R: Should callback interfaces allow for an @endsConversation annotation when they are non conversational?

Mike Edwards: also:

Mike Edwards: "Should outstanding callbacks be able to keep alive conversation scoped clients?"

Mike Edwards: <long discussion of he nature of conversation & callback interfaces and the components that use the>

Mike Edwards: s/the/them

Mike Edwards: - conversationID is about finding the right instance - or getting the ID for a stateless scope

anonymous morphed into Jim Marino

Mike Edwards: <Long discussion of the use case of A calling B calling C with conversations and callbacks>

Mike Edwards: Simon N: Moves that where a service has a conversational interface it MUST be implemented as by conversation-scoped component.  If no scope is specified on the implementation, then conversation scope is implied.

Mike Edwards: s/as by/by a/

Mike Edwards: Dave B seconds

Mike Edwards: <It is noted that this motion will also resolve Issue 12>

Mike Edwards: Dave B: Moves to close issue 12 with the previous accepted motion (as written immediately above)

Mike Edwards: Simon N: seconded

Mike Edwards: Approved with no objection.

Mike Edwards: <Adjourn>

Ashok: s/<Adjourn>/<Recess>/

Jim Marino: Reajourn

Jim Marino: Issue 21

Jim Marino: http://www.osoa.org/jira/browse/JAVA-21

Jim Marino: Mike R has a potential proposal

Jim Marino: Mike R: issue: clarify meaning of scope and its relation to thread

Jim Marino: Mike R drawing on board: A calls B twice and also C

Jim Marino: B calls C

Jim Marino: Mike E asks what the nature of the interfaces are

Jim Marino: if all are local, then all invocations are in the same scope

Jim Marino: ambiguity is if B and C are remotable but collocated with A

Jim Marino: Mike E raises question about difference w/ conversations

Jim Marino: discussion of request scope with one-way

Jim Marino: proposal to not allow one-way with request scope

Jim Marino: Anish likes name "operation scope" instead of "request scope"

Jim Marino: Simon point out there may be multiple operations during the lifecycle

Jim Marino: Mike R moves to accept: proposal 1

Jim Marino: Mike E asks for a clarification

Jim Marino: interfaces must be declared "local"

Jim Marino: Mike R proposes limiting request scope to same thread and not crossing a remotable boundary

Jim Marino: correction: remotable service

Jim Marino: Mike E proposes doing something at the level of the composite

Jim Marino: discussion of using conversational propagation instead

Jim Marino: <long discussion of conversational propagation>

Jim Marino: short break

Jim Marino: vote on restaurant

Jim Marino: 9 yes

Jim Marino: 11 yes

Jim Marino: 1 abstention

Jim Marino: adjourn

Jim Marino: <long discussion on conv propagation>

Michael Rowley: 1. Composite can be marked to propagate conversations through all components within the composite ("propagatesConversation").

Michael Rowley: 2. Request scope goes away.

Michael Rowley: 3. If the composite service has a conversational interface, then if the composite is marked as "propagatesConversation" then the conversation of the composite's client will be propagated throughout all of the components within the composite.

Michael Rowley: 4. If the composite service has a non-conversational interface, then if the composite is marked as "propagatesConversation", then (unless step 3 applies) a new conversation will be  started on each operation of the composite service and propagated throughout the components within the composite.

Michael Rowley: 5. Marking a composite as "propagatesConversation" acts as if all the components have been marked as "propagatesConversation".  Marking a component with "propagatesConversation" means that any conversationID passed into the component through a service will be passed with any call on a intra-composite wire from the component.

Michael Rowley: ISSUE: What happens with "endsConversation" operations?

Michael Rowley: Perhaps say that it is an error to call an operation after the conversation has been explicitly ended.

Michael Rowley: Perhaps say that it is an error to call an operation after the conversation has been explicitly ended.

Michael Rowley: (using the same conversation id)

Jim Marino: come back to proposal tomorrow

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]