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>
13/03/2008 14:30
|
To
|
"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