tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Venkata Krishnan" <for.svkr...@gmail.com>
Subject Re: Pass-by-value support for remotable interfaces
Date Thu, 07 Dec 2006 17:30:32 GMT
Hi Raymond,

Thanks.  Will take a look at your comments and get some understanding.

Meanwhile I have gone ahead with '@AllowsPassByReference'.  I have been able
to get this working for the interface level.  I created an
AllowPassByReference implementation processor and am able to deal with this.

Now if this annotation is to be at the method level then it seems to be bit
tricky to get this information about which method has this stuff from the
Implemenation processing phase over to the wire precessors.   I am thinking
of having list of methods (with complete signature info) that have the
@AllowsPassByReference populated into the componentType and then inject this
into the Components during ComponentBulding phase.  Finally pull out these
components during the wire proecessing (which is our current
process(Outbound, Inbound)) and then access the list of methods that have
this annotation.  Is there a better way?

Thanks

- Venkat


On 12/7/06, Raymond Feng <enjoyjava@gmail.com> wrote:
>
> Hi, Venkat.
>
> I'll review the path. Please see my comments below.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Venkata Krishnan" <for.svkrish@gmail.com>
> To: <tuscany-dev@ws.apache.org>
> Sent: Thursday, December 07, 2006 1:55 AM
> Subject: Re: Pass-by-value support for remotable interfaces
>
>
> > Hi Raymond,
> >
> > I have attached a patch for this in the JIRA
> > http://issues.apache.org/jira/browse/TUSCANY-969 as a first increment.
> > Let
> > me know if its ok to commit and I will go ahead and do it.  This is the
> > first increment and will add more as I get clarity on the following: -
> >
> > - why is the databinding provider dependent copy required?  The
> > passbyvalue
> > thing happens after the data mediation - when data is already tranformed
> > into consumable java objects for the target component.  So just need to
> > make
> > copies of them isn't it.  I guess I am missing some bigger scenario
> here.
> >
>
> There are two thoughts behind the databinding-specific copy:
>
> 1. Data in other bindings such as SDO, JAXB other than the default java
> databinding can have their own way to copy the data, for example, copy via
> XML or even more efficiently, like the SDO cross scope copy. Copy by
> serialization is the alogorithm for java.
>
> 2. There're opportunities for optimization. As we know, transformation
> accross databindings have copied the data and we should be able to
> eliminate
> the copy() in the pass-by-value interceptor in some cases.
>
> > - right now I add the passbyvalue interceptor when processing wires that
> > connect two components.. i.e. the outbound of a source (consumer
> > component)
> > and the inbound of a target (provider component).  i.e. in the Processor
> > that I have implemented I only do this in the process(OutboundWire,
> > InboundWire).  I have understood that in the other case of
> > 'process(InboundWire, OutboundWire)' this might not be required.
> >
>
> Yes,  'process(InboundWire, OutboundWire)' case is for composite services
> and references. We discussed before and we asume that the binding
> implementation could take care of that considering the data will go
> accross
> some protocol/transport layer.
>
> > - When a particular service method takes two arguments that point to the
> > same object reference, when copying over we too make just one
> copy.  Maybe
> > in the consumer component's context of things these two arguments point
> to
> > the same object, but in the producers context of the service these two
> > might
> > wished to be seen as distinct ones that the producer can deal.  If this
> is
> > the case then it might so happen that while the producer is modifying
> arg1
> > it is actually unaware that it is also changing arg2 implicitly.  Am I
> > making sense ?
>
> This is an issue that Mike Edwards has pointed out. Different protocols
> have
> different requirements. RMI requires one copy while web service requires
> two. In the java case, if we serialize/deserilze the top Object[], we'll
> get
> the same copy for the elements pointing to the same instance in the
> Object[]. But if we serialize/deserialize the elements one by one, we'll
> get
> multiple copyies.
>
> >
> > Thanks
> >
> > - Venkat
> >
> > On 12/6/06, Jim Marino <jmarino@myromatours.com> wrote:
> >>
> >>
> >> On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:
> >>
> >> > Hi,
> >> >
> >> > Is there any way I can control the order in which the
> >> > WirePostProcessors are
> >> > loaded.  For example I would always want the PassByValue processor
> >> > to be
> >> > called last so that I ensure that the PassByValue interceptor is at
> >> > the head
> >> > of the invocation chain.
> >> >
> >> The best way to handle this is by implementing a phase mechanism. I
> >> can look into adding this. BTW, why is this a WirePostProcessor vs. a
> >> TargetPolicyBuilder (which has phases)?
> >>
> >> Jim
> >>
> >> > Thanks.
> >> >
> >> > - Venkat
> >> >
> >> > On 12/6/06, Venkata Krishnan <for.svkrish@gmail.com> wrote:
> >> >>
> >> >> HI Jim,
> >> >>
> >> >> Yes, the pass-by-value interceptor will come first exactly for the
> >> >> reasons
> >> >> you have mentioned.  I will get a testcase across soon.
> >> >>
> >> >> Thanks
> >> >>
> >> >> - Venkat
> >> >>
> >> >> On 12/6/06, Jim Marino <jmarino@myromatours.com> wrote:
> >> >> >
> >> >> >
> >> >> > On Dec 5, 2006, at 10:51 PM, Venkata Krishnan wrote:
> >> >> >
> >> >> > > Hi,
> >> >> > >
> >> >> > > I think I managed to figure this out now.  After your
> >> >> explanation I
> >> >> > > could
> >> >> > > follow the Connector a little better.  Its just that the
> outbound
> >> >> > > (of the
> >> >> > > source component) and inbound chains (of the target component)
> >> >> are
> >> >> > > fused
> >> >> > > thro the bridge interceptor.
> >> >> > >
> >> >> > > Given this if I added an interceptor to the begining of the
> >> >> > > target's inbound
> >> >> > > chain then I must have to reset the source's tail interceptor
to
> >> >> > > point this
> >> >> > > this added interceptor as its next.  (Infact I found this
code
> >> >> > > marked as
> >> >> > > "HACK" further down the DataBindingWirePostProcessor).  This
> >> >> is what I
> >> >> >
> >> >> > > intend to do.
> >> >> > We probably should do something to make this less error-prone
in
> >> >> the
> >> >> > fabric...I'll take a look.
> >> >> > >
> >> >> > > On the other hand if I were to add an intercetpr to the end
of
> >> >> the
> >> >> > > target's
> >> >> > > inbound chain then I end with an exception because the tail
is
> >> >> > > already an
> >> >> > > InvokerInterceptor and nothing can be added beyond that.
> >> >> > The pass-by-reference interceptor needs to come first since
> >> >> > interceptors could modify a the payload of a message. This can
> >> >> > violate pass-by-value semantics if a copy is not made beforehand.
> >> >> >
> >> >> > > So in this case I
> >> >> > > have to probably iterate thro all interceptors and then insert
> >> >> just
> >> >> > > before
> >> >> > > the InvokerInterceptor.
> >> >> > >
> >> >> > > So.. I am moving forward for now.  Thanks for the help.
> >> >> > >
> >> >> > Can you post a testcase so I can see how best to make this less
> >> >> error-
> >> >> > prone as mentioned above? Thanks.
> >> >> >
> >> >> > Jim
> >> >> >
> >> >> > > - Venkat
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > On 12/5/06, Jim Marino <jmarino@myromatours.com> wrote:
> >> >> > >>
> >> >> > >>
> >> >> > >> On Dec 5, 2006, at 1:34 AM, Venkata Krishnan wrote:
> >> >> > >>
> >> >> > >> > Hi Jim,
> >> >> > >> >
> >> >> > >> > Thanks for helping :).  Well, let me ask away very
simply....
> >> >> > >> >
> >> >> > >> > What I am doing here is just about trying to insert
an
> >> >> > >> interceptor for
> >> >> > >> > enforcing pass-by-value semantics in the case of
compoments
> >> >> > >> > implementing a
> >> >> > >> > Remotable interface - i.e. an interceptor to take
care of
> >> >> making
> >> >> > >> > copies of
> >> >> > >> > arguments and return values.
> >> >> > >> >
> >> >> > >> > Since I understand that the best place to perform
such a
> >> >> copying
> >> >> > >> > would be
> >> >> > >> > just before the serving (or provider) component
actually
> >> >> gets to
> >> >> > >> > service the
> >> >> > >> > request, I had thought of inserting this interceptor
into the
> >> >> > >> > InboundInvocation chain of the server component.
> >> >> > >> >
> >> >> > >> > For example if component A that has a reference
to Component
> B
> >> >> > >> whose
> >> >> > >> > interface is remotable.  Then I am trying to insert
this
> >> >> > >> > interceptor into
> >> >> > >> > Component B's Inbound wire's invocation chain. 
This I do
> >> >> in the
> >> >> > >> > DataBindingWirePostProcessor.process(OutboundWire
source,
> >> >> > >> InboundWire
> >> >> > >> > target) wherein 'target' is the wire where I am
doing the
> >> >> > >> insertion.
> >> >> > >> Pass-by-val should probably be enforced in another wire
> >> >> processor
> >> >> > >> since it is a separate concern (this isn't related to
the
> >> >> problem
> >> >> > >> though)
> >> >> > >> > (Component A being the source and Component B being
the
> >> >> target).
> >> >> > >> > When I
> >> >> > >> > tested this, the interceptor seemed to not get invoked.
> >> >> > >> >
> >> >> > >> > However, when I added this interceptor to the source
> >> >> component's
> >> >> > >> > outbound
> >> >> > >> > chain i.e. in DataBindingWirePostProcessor.process
> >> >> (OutboundWire
> >> >> > >> > source,
> >> >> > >> > InboundWire target) to the invocation chain of the
'source',
> >> >> > >> then the
> >> >> > >> > interceptor got invoked.
> >> >> > >> >
> >> >> > >> > So right now, I am wondering how to get the interceptor
> >> >> invoked
> >> >> > >> > from the
> >> >> > >> > Inbound invocation chain of Component B.
> >> >> > >> >
> >> >> > >> It sounds like something is not being setup properly
> >> >> > >>
> >> >> > >> > If I am still not clear please let me know and probably
> >> >> testcase is
> >> >> >
> >> >> > >> > the only
> >> >> > >> > way out.
> >> >> > >> >
> >> >> > >> This would be the easiest way (you can probably copy
the
> >> >> testcase I
> >> >> > >> pointed to, so it's not that much work). Such a testcase
will
> >> >> allow
> >> >> > >> you to set a breakpoint and see if the target chains
have been
> >> >> > >> sequenced properly. It sounds like  upon insertion your
> >> >> interceptor
> >> >> > >> is not being pointed to by the previous one in the chain.
It is
> >> >> > >> possible that there is a problem in the wiring infrastructure
> >> >> that is
> >> >> > >> causing this to happen.
> >> >> > >>
> >> >> > >> Jim
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> > Thanks
> >> >> > >> >
> >> >> > >> > - Venkat
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >
> >> >> > >> > On 12/5/06, Jim Marino <jmarino@myromatours.com>
wrote:
> >> >> > >> >>
> >> >> > >> >> Comments inline...
> >> >> > >> >>
> >> >> > >> >> On Dec 5, 2006, at 12:29 AM, Venkata Krishnan
wrote:
> >> >> > >> >>
> >> >> > >> >> > Hi Raymond,
> >> >> > >> >> >
> >> >> > >> >> > Yes, I am debugging to figure out quite
a few things.
> >> >> > >> >> >
> >> >> > >> >> > I just figured that in the ConnectorImpl.connect
> >> >> (OutboundWire
> >> >> > >> >> > sourceWire,
> >> >> > >> >> > InboundWire targetWire, boolean optimizable)
we set the
> >> >> > >> >> > 'targetInvoker' of
> >> >> > >> >> > the 'targetComponent' to the outbound chain
of the source.
> >> >> > >> Hence I
> >> >> > >> >> > guess
> >> >> > >> >> > the interceptors of set on the inbound
chain of the
> >> >> > >> targetComponent
> >> >> > >> >> > is not
> >> >> > >> >> > getting invoked.
> >> >> > >> >> >
> >> >> > >> >> > I am looking to see if there is a way where
at the end
> >> >> of the
> >> >> > >> >> > OutboundWire's
> >> >> > >> >> > invocation chain the target invoker triggers
off the
> target
> >> >> > >> >> > component's
> >> >> > >> >> > inbound invocation chains.
> >> >> > >> >> >
> >> >> > >> >> The TargetInvoker's job is to dispatch a request
to the
> >> >> target
> >> >> > >> >> instance *after* the request has been processed
by the
> >> >> invocation
> >> >> > >> >> chain pair. The invoker is cached on the source
side to
> avoid
> >> >> > >> having
> >> >> > >> >> to perform target resolution on every invoke
in certain
> >> >> situations
> >> >> > >> >> (e.g. when the target scope is "greater" than
the source,
> >> >> e.g.
> >> >> > >> >> request--->composite). The invocation handler
places the
> >> >> > >> >> TargetInvoker in the message sent down both
chains and it
> >> >> is the
> >> >> > >> >> responsibility of the last interceptor on the
target side to
> >> >> > >> pull the
> >> >> > >> >> invoker from the message and call its invoke
method.
> >> >> > >> >>
> >> >> > >> >> The source and target chains are fused by the
Connector
> >> >> with a
> >> >> > >> >> BridgingInterceptor, which may be synchronous
or non-
> >> >> blocking.
> >> >> > >> >>
> >> >> > >> >> I'm finding it a little difficult to follow
what you are
> >> >> doing
> >> >> > >> so do
> >> >> > >> >> you have a small testcase you can attach to
a JIRA similar
> to
> >> >> > >> this:
> >> >> > >> >>
> >> >> > >> >> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/
> >> >> > >> kernel/
> >> >> > >> >> core/src/test/java/org/apache/tuscany/core/integration/
> >> >> > >> conversation/
> >> >> > >> >> ConversationStartStopEndTestCase.java
> >> >> > >> >>
> >> >> > >> >> I can take a look and see what the problem is.
> >> >> > >> >>
> >> >> > >> >> Jim
> >> >> > >> >>
> >> >> > >> >> > I am still going at this... let me see
if I see the light.
> >> >> > >> >> >
> >> >> > >> >> > Meanwhile if I am not on the right track
(anybody)
> >> >> please advise
> >> >> > >> >> me on
> >> >> > >> >> > course corrections :)
> >> >> > >> >> >
> >> >> > >> >> > Thanks.
> >> >> > >> >> >
> >> >> > >> >> > - Venkat
> >> >> > >> >> >
> >> >> > >> >> >
> >> >> > >> >> >
> >> >> > >> >> > On 12/5/06, Raymond Feng <enjoyjava@gmail.com>
wrote:
> >> >> > >> >> >>
> >> >> > >> >> >> Hi,
> >> >> > >> >> >>
> >> >> > >> >> >> Can you debug to see how the interceptors
are chained? It
> >> >> > >> could be
> >> >> > >> >> >> a bit
> >> >> > >> >> >> tricky to make sure the new interceptor
is added to the
> >> >> correct
> >> >> >
> >> >> > >> >> >> position.
> >> >> > >> >> >>
> >> >> > >> >> >> Thanks,
> >> >> > >> >> >> Raymond
> >> >> > >> >> >>
> >> >> > >> >> >> ----- Original Message -----
> >> >> > >> >> >> From: "Venkata Krishnan" <for.svkrish@gmail.com>
> >> >> > >> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> > >> >> >> Sent: Monday, December 04, 2006 4:16
PM
> >> >> > >> >> >> Subject: Re: Pass-by-value support
for remotable
> >> >> interfaces
> >> >> > >> >> >>
> >> >> > >> >> >>
> >> >> > >> >> >> > Hi Raymond,
> >> >> > >> >> >> >
> >> >> > >> >> >> > Thanks.   I have started with
this and here are a
> >> >> couple of
> >> >> > >> >> >> questions
> >> >> > >> >> >> that
> >> >> > >> >> >> > I
> >> >> > >> >> >> > need help with.
> >> >> > >> >> >> >
> >> >> > >> >> >> > I believe the PassByValue Interceptor
is good to be
> >> >> on the
> >> >> > >> >> Inbound
> >> >> > >> >> >> > Invocation chain of the server
component.  Accordingly
> I
> >> >> > >> looked
> >> >> > >> >> >> up the
> >> >> > >> >> >> > DataBindingWirePostProcessor's
method -
> >> >> > >> >> >> > "public void process(OutboundWire
source, InboundWire
> >> >> > >> target)"
> >> >> > >> >> >> to do
> >> >> > >> >> >> this.
> >> >> > >> >> >> >
> >> >> > >> >> >> > Over here I added the PassbyValue
interceptor to the
> >> >> > >> 'target'.
> >> >> > >> >> >> But this
> >> >> > >> >> >> > did
> >> >> > >> >> >> > not invoke the interceptor.  If
I added it to the
> >> >> source then
> >> >> >
> >> >> > >> >> the
> >> >> > >> >> >> > interceptor gets invoked.  So,
am I missing something
> >> >> here?
> >> >> > >> >> >> >
> >> >> > >> >> >> > I understand that the interceptor
that you have
> >> >> attached is
> >> >> > >> >> for the
> >> >> > >> >> >> > default
> >> >> > >> >> >> > Java binding case.  I will work
on the databinding
> >> >> dependent
> >> >> > >> >> >> case once I
> >> >> > >> >> >> > get
> >> >> > >> >> >> > this default stuff working.
> >> >> > >> >> >> >
> >> >> > >> >> >> > Thanks
> >> >> > >> >> >> >
> >> >> > >> >> >> > - Venkat
> >> >> > >> >> >> >
> >> >> > >> >> >> >
> >> >> > >> >> >> >
> >> >> > >> >> >> > On 12/4/06, Raymond Feng <enjoyjava@gmail.com
> wrote:
> >> >> > >> >> >> >>
> >> >> > >> >> >> >> Hi, Venkat.
> >> >> > >> >> >> >>
> >> >> > >> >> >> >> Thank you for volunteering.
I opened a JIRA
> >> >> > >> >> >> >> http://issues.apache.org/jira/browse/TUSCANY-969
and
> >> >> > >> >> attached some
> >> >> > >> >> >> >> prototype
> >> >> > >> >> >> >> code there. Hopefully it can
get you started.
> >> >> > >> >> >> >>
> >> >> > >> >> >> >> Thanks,
> >> >> > >> >> >> >> Raymond
> >> >> > >> >> >> >>
> >> >> > >> >> >> >> ----- Original Message -----
> >> >> > >> >> >> >> From: "Venkata Krishnan" <
for.svkrish@gmail.com>
> >> >> > >> >> >> >> To: <tuscany-dev@ws.apache.org>
> >> >> > >> >> >> >> Sent: Sunday, December 03,
2006 10:08 PM
> >> >> > >> >> >> >> Subject: Re: Pass-by-value
support for remotable
> >> >> interfaces
> >> >> > >> >> >> >>
> >> >> > >> >> >> >>
> >> >> > >> >> >> >> > Hi Raymond,
> >> >> > >> >> >> >> >
> >> >> > >> >> >> >> > I'm interested in helping
with this.  It will give
> >> >> me a
> >> >> > >> >> >> chance to
> >> >> > >> >> >> work
> >> >> > >> >> >> >> > with
> >> >> > >> >> >> >> > the service invocation
paths of the core.  Let me
> >> >> know if
> >> >> > >> >> >> there is
> >> >> > >> >> >> >> > something
> >> >> > >> >> >> >> > that I help with.
> >> >> > >> >> >> >> >
> >> >> > >> >> >> >> > Thanks.
> >> >> > >> >> >> >> >
> >> >> > >> >> >> >> > - Venkat
> >> >> > >> >> >> >> >
> >> >> > >> >> >> >> > On 11/30/06, Raymond
Feng <enjoyjava@gmail.com>
> >> >> wrote:
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >> ----- Original Message
-----
> >> >> > >> >> >> >> >> From: "Mike Edwards"
> >> >> <mike.edwards.inglenook@gmail.com >
> >> >> > >> >> >> >> >> To: <tuscany-dev@ws.apache.org
>
> >> >> > >> >> >> >> >> Sent: Wednesday,
November 29, 2006 7:07 AM
> >> >> > >> >> >> >> >> Subject: Re: Pass-by-value
support for remotable
> >> >> > >> interfaces
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >> > Raymond,
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >> > First point
I need to make is that just because
> >> >> two
> >> >> > >> >> >> components are
> >> >> > >> >> >> >> >> > in
> >> >> > >> >> >> >> >> the
> >> >> > >> >> >> >> >> > same composite
does not mean that they are
> >> >> > >> automatically
> >> >> > >> >> >> running
> >> >> > >> >> >> in
> >> >> > >> >> >> >> the
> >> >> > >> >> >> >> >> > same VM or even
the same operating system
> process.
> >> >> > >> >> >> Composites can
> >> >> > >> >> >> >> span
> >> >> > >> >> >> >> >> > components running
on different nodes (node =
> >> >> > >> machine and/
> >> >> > >> >> >> or o/s
> >> >> > >> >> >> >> >> process).
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >> Good catch.
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >> > Consider a composite
which had component A
> >> >> > >> implemented in
> >> >> > >> >> >> Java and
> >> >> > >> >> >> >> >> > component B
implemented in C++.  Not likely
> >> >> that they
> >> >> > >> >> >> would run in
> >> >> > >> >> >> >> the
> >> >> > >> >> >> >> >> > same runtime
process (certainly not with the
> >> >> current
> >> >> > >> >> Tuscany
> >> >> > >> >> >> >> runtime).
> >> >> > >> >> >> >> >> > This is perfectly
OK as long as any interface
> >> >> between
> >> >> > >> >> them is
> >> >> > >> >> >> >> >> "remotable".
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >> > Second, more
general point to make, is that there
> >> >> > >> may be
> >> >> > >> >> >> implied
> >> >> > >> >> >> >> >> semantics
> >> >> > >> >> >> >> >> > for the interface
that depend on the binding
> >> >> used to
> >> >> > >> >> >> connect the
> >> >> > >> >> >> >> >> reference
> >> >> > >> >> >> >> >> > to the service.
 Consider the case where the
> >> >> interface
> >> >> > >> >> >> involves an
> >> >> > >> >> >> >> >> > operation with
a message having two references to
> >> >> > >> the same
> >> >> > >> >> >> object.
> >> >> > >> >> >> >> >> > When
> >> >> > >> >> >> >> >> > this is sent
from consumer to provider (say),
> >> >> does the
> >> >> > >> >> >> provider
> >> >> > >> >> >> >> receive
> >> >> > >> >> >> >> >> 2
> >> >> > >> >> >> >> >> > separate copies
of the object or just one -
> >> >> assuming
> >> >> > >> the
> >> >> > >> >> >> consumer
> >> >> > >> >> >> >> >> started
> >> >> > >> >> >> >> >> > with only 1.
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >> > The answer is
"it depends on the binding" - RMI-
> >> >> IIOP
> >> >> > >> says
> >> >> > >> >> >> there is
> >> >> > >> >> >> >> only
> >> >> > >> >> >> >> >> 1
> >> >> > >> >> >> >> >> > copy.  Web Services
says there are 2 copies...
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >> > I don't think
that SCA can hide these subtle
> >> >> > >> differences,
> >> >> > >> >> >> much
> >> >> > >> >> >> >> >> > though
> >> >> > >> >> >> >> >> > we
> >> >> > >> >> >> >> >> > may like to
do so.  However, what we must
> >> >> guarantee is
> >> >> > >> >> >> that the
> >> >> > >> >> >> >> >> behaviour
> >> >> > >> >> >> >> >> > matches the
binding type - if the internal wire
> >> >> uses
> >> >> > >> >> >> binding.ws,
> >> >> > >> >> >> for
> >> >> > >> >> >> >> >> > example, then
we provide Web services
> >> >> semantics.  This
> >> >> > >> >> >> must be
> >> >> > >> >> >> true
> >> >> > >> >> >> >> for
> >> >> > >> >> >> >> >> > any optimisations
we may like to use in the
> >> >> case where
> >> >> > >> >> >> both ends
> >> >> > >> >> >> of
> >> >> > >> >> >> >> the
> >> >> > >> >> >> >> >> > wire are in
1 process - since for a remotable
> >> >> interface
> >> >> >
> >> >> > >> >> this
> >> >> > >> >> >> >> proximity
> >> >> > >> >> >> >> >> is
> >> >> > >> >> >> >> >> > "accidental"
and could be changed by a subtle
> >> >> change in
> >> >> >
> >> >> > >> >> >> deployment.
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >> > That leaves
open what to do in the case of
> >> >> > >> binding.ws.  We
> >> >> > >> >> >> may
> >> >> > >> >> >> need
> >> >> > >> >> >> >> >> > a
> >> >> > >> >> >> >> >> way
> >> >> > >> >> >> >> >> > for the composition
to indicate the type of
> >> >> semantics
> >> >> > >> >> >> required -
> >> >> > >> >> >> or
> >> >> > >> >> >> >> we
> >> >> > >> >> >> >> >> > could default
to one form (eg Web services...)
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >> Should this be clarified
by the SCA spec on
> pass-by-
> >> >> > >> value?
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >> > Yours,  Mike.
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >> > Raymond Feng
wrote:
> >> >> > >> >> >> >> >> >> Hi,
> >> >> > >> >> >> >> >> >>
> >> >> > >> >> >> >> >> >> I'm talking
about the following:
> >> >> > >> >> >> >> >> >>
> >> >> > >> >> >> >> >> >> componentA.reference
--> componentB.service1
> >> >> > >> >> >> >> >> >> non-SCA
client --> componentB.service1
> >> >> > >> >> >> >> >> >>
> >> >> > >> >> >> >> >> >> In the cases
above, componentA and componentB
> are
> >> >> > >> in the
> >> >> > >> >> >> same
> >> >> > >> >> >> >> >> >> composite
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >> >> (in the
same VM). Both the service and
> >> >> reference are
> >> >> > >> >> >> declared
> >> >> > >> >> >> with
> >> >> > >> >> >> >> >> >> a
> >> >> > >> >> >> >> >> >> remotable
interface. We need to have an
> >> >> interceptor to
> >> >> >
> >> >> > >> >> >> deal with
> >> >> > >> >> >> >> >> >> the
> >> >> > >> >> >> >> >> >> pass-by-value.
> >> >> > >> >> >> >> >> >>
> >> >> > >> >> >> >> >> >> For the
following wirings:
> >> >> > >> >> >> >> >> >>
> >> >> > >> >> >> >> >> >> .. -->
composite.reference
> >> >> > >> >> >> >> >> >> composite.service
--> ...
> >> >> > >> >> >> >> >> >>
> >> >> > >> >> >> >> >> >> I assume
the binding implementation for the
> >> >> composite
> >> >> > >> >> >> >> >> >> reference/service
> >> >> > >> >> >> >> >> >> will handle
the pass-by-value naturally over the
> >> >> > >> >> transport.
> >> >> > >> >> >> >> >> >>
> >> >> > >> >> >> >> >> >> Thanks,
> >> >> > >> >> >> >> >> >> Raymond
> >> >> > >> >> >> >> >> >>
> >> >> > >> >> >> >> >> > <snip>
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >>
> >> >> > >> >>
> >> >> > >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >
> >> >> > >> >> >> >> >> > To unsubscribe,
e-mail: tuscany-dev-
> >> >> > >> >> unsubscribe@ws.apache.org
> >> >> > >> >> >> >> >> > For additional
commands, e-mail: tuscany-dev-
> >> >> > >> >> >> help@ws.apache.org
> >> >> > >> >> >> >> >> >
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >>
> >> >> > >> >> >>
> >> >> > >> >>
> >> >> > >>
> >> >>
> ---------------------------------------------------------------------
> >> >> > >> >> >> >> >> To unsubscribe, e-mail:
tuscany-dev-
> >> >> > >> >> unsubscribe@ws.apache.org
> >> >> > >> >> >> >> >> For additional commands,
e-mail: tuscany-dev-
> >> >> > >> >> help@ws.apache.org
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >
> >> >> > >> >> >> >>
> >> >> > >> >> >> >>
> >> >> > >> >> >> >>
> >> >> > >> >> >>
> >> >> > >> >>
> >> >> > >>
> >> >>
> ---------------------------------------------------------------------
> >> >> > >> >> >> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> > >> unsubscribe@ws.apache.org
> >> >> > >> >> >> >> For additional commands, e-mail:
tuscany-dev-
> >> >> > >> help@ws.apache.org
> >> >> > >> >> >> >>
> >> >> > >> >> >> >>
> >> >> > >> >> >> >
> >> >> > >> >> >>
> >> >> > >> >> >>
> >> >> > >> >> >>
> >> >> > >> >>
> >> >> > >>
> >> >>
> ---------------------------------------------------------------------
> >> >> > >> >> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> unsubscribe@ws.apache.org
> >> >> > >> >> >> For additional commands, e-mail: tuscany-dev-
> >> >> help@ws.apache.org
> >> >> > >> >> >>
> >> >> > >> >> >>
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >>
> >> >>
> ---------------------------------------------------------------------
> >> >> > >> >> To unsubscribe, e-mail:
> tuscany-dev-unsubscribe@ws.apache.org
> >> >> > >> >> For additional commands, e-mail: tuscany-dev-
> >> >> help@ws.apache.org
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >>
> ---------------------------------------------------------------------
> >> >> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> > >>
> >> >> > >>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >
> >> >> >
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message