[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime
I would prefer to describe the idea on the table as replacing request scopes with the more general concept of conversation propagation. I would not want to get rid of request scopes if we didn't have something to replace them with. I agree that conversation propagation should not have to be specified as a composite-wide concept. I think you should be able to specify conversation propagation on an individual component. I _think_ that specifying it on a composite is almost the same as specifying it on all of the components within it. I also agree is like other technologies concepts of "session" or "shared context". Michael -----Original Message----- From: David Booz [mailto:booz@us.ibm.com] Sent: Tuesday, March 18, 2008 10:00 AM To: sca-j@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime +1 to dropping request scope. ...with a word of caution. We have not yet created constraints in the assembly model which force developers/architects to place boundaries on composites (with the exception of composites that are used as implementations). Any semantic which can only be obtained through collocation of components in a composite will turn out to be overly constraining as it will force developers and assemblers to aggregate components which otherwise might not need to be aggregated. I would hope that we could explore these new ideas from the perspective of a session concept, and I mean session in a generic form. I would also hope that we could avoid the temptation to tie this semantic too tightly with composites. I'm thinking about components which cooperate to provide coarse grained business services with some shared runtime context called a session. We will have to debate how much of the session is visible to the business logic. We will have to debate system managed vs. application managed session correlation. Other technologies have been here. WS RM has this idea baked into it. CORBA has activity session. Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome Mike Edwards <mike_edwards@uk. ibm.com> To sca-j@lists.oasis-open.org 03/17/2008 08:59 cc AM Subject RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime Michael, Yes, I'm OK with the idea of dropping request scope. The conversation propagation idea is interesting - possibly it is part of a wider consideration of sets of components within a composite acting in a coordinated or unified way, that may apply to a number of things beyond conversations. Perhaps this is going to turn into some mechanics that apply to composites as a whole. Intents at the composite level that are meaningful to the composite itself -and which has specific implications on the components within the composite. An example might be the idea that all conversations between components within the composite are shared. 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 "Michael Rowley" <mrowley@bea.com> To 13/03/2008 18:31 Mike Edwards/UK/IBM@IBMGB, <sca-j@lists.oasis-open.org> cc Subject RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime Mike, You are absolutely right. The resolution was only w.r.t. java components. Given that, I will agree with Dave B that in this case the conversation-propagation idea is a little bit different from request scope semantics. Nonetheless, I think it would be close enough to warrant getting rid of the request scope. Michael From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Thursday, March 13, 2008 10:44 AM To: sca-j@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime Folks, Unless I've got the wrong end of the stick here, I think that the SCA Java TC is acting ultra vires. Dave posed a question about a composite exposing two services, one conversational one non, conversational. Michael responded saying that the Java F2F decided that a component cannot offer both a conversational and non-conversational service. Now, I can agree that the SCA Java TC decided that a Java implementation could not offer both a conversational and a non-conversational service. However, to extend this idea to apply to all components, using whatever implementation type, I think must be a decision of the SCA Assembly TC. If the Java TC really wants to limit ALL components to only expose either conversational or non conversational services, but never both, then I think the TC must get an appropriate issue raised in the Assembly TC. I suspect that the other C&I TCs would need to be consulted also. 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 "Michael Rowley" <mrowley@bea.com> To 13/03/2008 14:30 "David Booz" <booz@us.ibm.com>, <sca-j@lists.oasis-open.org> cc Subject RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime At the F2F we resolved that a component is not allowed to offer both a conversational and non-conversational service. Michael -----Original Message----- From: David Booz [mailto:booz@us.ibm.com] Sent: Wednesday, March 12, 2008 10:35 PM To: sca-j@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime What if the composite exposes two services, one conversational and one non-conversational? Would the conversational service act as in 3 and the non-conversational service as in 4? That's not clear from your text. While it seems desireable to be able to answer yes to the second question, I'll observe that it means that components in that composite will run differently (different context) depending on the inbound service. This is another divergence from request scope. ...and while I have your attention...regrets for the call tomorrow. Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome "Michael Rowley" <mrowley@bea.com> To 03/12/2008 10:14 "Barack, Ron" <ron.barack@sap.com>, PM "OASIS Java" <sca-j@lists.oasis-open.org> cc Subject RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime During the F2F it was observed that the request scope is similar to the conversation scope, except that it automatically propagates around the local components of a composite. Perhaps it would be simpler to take advantage of this similarity and also expand on conversation scopes. If an entire conversation can be marked as conversational, it could mean that all of the components within the composite work within the same conversation. This is also something that BEA has had customers ask for on its own right. However, if we did this, the request-scope could be removed, since basically same semantics could be achieved by having a composite that has been marked as "local" be also marked as conversational. The rules that we discussed at the F2F were: 1. Composite can be marked to propagate conversations through all components within the composite ("propagatesConversation"). 2. Request scope goes away. 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. 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. 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. If this were to happen, it would probably have to be done in either the policy or assembly TC. Michael From: Barack, Ron [mailto:ron.barack@sap.com] Sent: Thursday, January 31, 2008 11:26 AM To: OASIS Java Subject: [sca-j] ISSUE 21 - Clarify Request Scope lifetime http://www.osoa.org/jira/browse/JAVA-21 Von:: Michael Rowley [mailto:mrowley@bea.com] Gesendet: Montag, 21. Januar 2008 21:24 An: OASIS Java. Betreff: [sca-j] NEW ISSUE: Clarify Request Scope lifetime RAISER: Michael Rowley TARGET: SCA Java Component Implementation Specification section titled "Request Scope" DESCRIPTION: The section currently starts with the following sentence: "The lifecycle of request scope extends from the point a request on a remotable interface enters the SCA runtime and a thread processes that request until the thread completes synchronously processing the request." From this description, it is not clear whether the request scope lasts through a remotable call to another component that happens to be local. In one possible interpretation it would depend on the binding. A call through a web service binding would be seen as changing threads, and therefore would be a new request scope. The same call through an SCA binding might be assumed to remain within the thread and therefore be within the same scope. It is probably a bad idea for the scope to depend on the binding that is used, and it may even be a bad idea for the scope to depend on whether a call through a remotable interface _happens_ to be local. PROPOSALS: 1) Have the request scope be only for a single remotable operation call. From that operation, any request scope component that is reached through only local-service calls would reach the same component instance. Calls through a remotable interface would introduce a new request scope. 2) Alternately, the request scope could last from the time a request "enters the SCA runtime" until it is done, but with the clarification that the "SCA Runtime" is domain-wide. As long as a call is made to another SCA component within the same domain (irrespective of the binding used) it is part of the same request scope. --------------------------------------------------------------------- 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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]