Re: Build runtime wire/invocation chains for a composite hierarchy

[Raymond Feng]

Hi, Sebastien.

I think we are pretty much on the same page but I used a not-so-clear term 
"RuntimeContext". I even have an interface named 
ReferenceBindingContextProvider, which is your 
"ReferenceBindingInvokerFactory", in my local workspace :-).

For the service binding, I guess you're right. There is no need to have the 
service binding to provide an interceptor and the protocol-specific listener 
provided by the binding will dispatch the call to the promoted component 
service using an invocation chain.

In addtion to the invoker factory, I think there are other things as well, 
for example, the service binding will provide the lifecycle support so that 
the binding can start/stop listening on the incoming message for the 
protocol.

Thanks,
Raymond

----- Original Message ----- 
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, April 25, 2007 4:23 PM
Subject: Re: Build runtime wire/invocation chains for a composite hierarchy


ant elder wrote:
This sounds like something I'm interested in, but I'm really struggling 
to
understand what you're talking about in these two emails. What does 
"attach
runtime context to the model so that the model can be used to drive the
runtime behaviors" mean? What is MyContext? Could you describe this 
relating
it to the existing classes and say which of those you want to change?

  ...ant

On 4/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi,

Continueing on this path, I propose the following way to attach runtime
context to the model so that the model can be used to drive the runtime
behaviors.

1) How is a runtime context is attached to the model?

Let's assume the interface for the runtime context is "MyContext", then
the
model implementation can provide such a context in two ways:

a) Implement "MyContext" interface directly, then the model object is an
instance of MyContext and it can be cast to MyContext by the runtime.
There
is one thing not so nice is that we cannot have multiple inheritance and
we
can either use the base class for the model or the context, but not 
both.

b) Implement a getter method to return MyContext, and the runtime can
access
it using reflection or a provider interface. This approach can take
advantage of runtime context inheritance as MyContext is embedded.

2) How to build the invocation chain?

Let's assume we have the wiring like this: ComponentA.reference1 w/
binding1 ---> ComponentB.service1 w/ binding1

For the reference side, the invocation chain will look like:
Binding interceptor for reference1 over binding1 -->....  (binding
protocol
layer)

For the service side, the invocation chain will look like:
(binding protocol layer)...-->Binding interceptor for service1 over
binding1--> Implementation interceptor for ComponentB

If the binding is SCABinding, then for local interface or co-located
remotable interface, the reference side can connect to the service side
directly as:

Binding interceptor for reference1 over binding1 -->Binding interceptor
for
service1 over binding1--> Implementation interceptor for ComponentB

3) The interfaces for runtime context:
Please see the bottom of the wiki page at

http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy
.

Thanks,
Raymond

----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Tuesday, April 24, 2007 11:58 AM
Subject: Build runtime wire/invocation chains for a composite hierarchy


> Hi,
>
> I'm trying to indentify all the paths of SCA component interactions
which
> require to have runtime wires/invocation chains.
>
> By the SCA spec, there are three cases for the wiring:
>
> 1) Component.Reference (A.ref1) --is wired to--> Component.Service
> (B.svc1)
>
--------------------------------------------------------------------------------------------------

> 1.1) If both the service and reference are defined by non-composite
> components, then the runtime wire is as simple as A.ref1-->B.svc1.
>
> 1.2) If the service is defined on a composite component, then it
can be
> further resolved to the orginal atomic component service following the
> service promotion chain.
>
> For example, A.ref1 --> B.svc1 (B is implemented by another composite
and
> B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 -->
C.svc1
>
> 1.3) If the reference is defined on a composite component, then it can
be
> further resolved to the orginal atomic component reference
following the
> reference promotion chain.
>
> For example, A.ref1 --> B.svc1 (A is implemented by another composite
and
> A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 -->
B.svc1
>
> 2) Composite.Reference (Composite1.ref1) --promotes-->
Component.Reference
> (B.ref1)
>
-----------------------------------------------------------------------------------------------------------------

> If Composite1 is the top-level composite, and the B is a non-composite
> component, then the runtime wire will be: B.ref1 --> Composite1.ref1
>
> If Composite1 is used to implement a component A in Composite2,
then we
> need to futher check if A.ref1 is promoted or wired until we hit
the end
> of the promotion chain. The final target will be either a composite
> reference or a component service that the out-most reference is wired
to.
> For example, if A.ref1 is wired to D.svc1 in Composite2, then the
runtime
> wire is B.ref1 --> D.svc1. If A.ref1 is promoted by Composite2.ref1,
then
> the runtime wire is B.ref1 --> Composite2.ref1.
>
> If B is a composite component, then we need to find out the final
> component reference that B.ref1 promotes. For example, it promotes
D.ref1,
> then the runtime wire is D.ref1 --> C.ref1
>
> 3) Composite.Service (Composite1.svc1) --promotes--> Component.Service
> (A.svc1)
>
-----------------------------------------------------------------------------------------------------------

> The source will be the outmost service on the promotion chain.  For
> example, if Composite2.svc1 promotes B.svc1 and B is implemented by
> Composite1, then it is Composite2.svc1.
>
> The target will be the innermost service on the promotion chain. For
> example, if A is implemented by Composite3 and Composite3.svc1
promotes
> C.svc1, then it is C.svc1.
>
> * Please note, due to the spec limitation, the composite service
cannot
> promote a composite reference directly.
>
> Based on the above scenarios, it seems that we can create runtime
wires
> using the following algorithm (assuming multiplicity = 1..1). The
key is
> to get a final list of targets and selected bindings.
>
> 1) Runtime wire for references: For each of the references (r1) on
> non-composite components, find the outmost reference (r0) on the
reference
> promotion chain. Then get the targets and selected bindings from
r0. If
> SCA binding is used for a target, it can be further optimized to
use the
> orginally promoted component service. The runtime wire should be
created
> between the r1 and a target (either a component service with SCA
binding
> or a reference binding) from r0.
>
> 2) Runtime wire for service promotions: For each of the service1
(s1) on
> non-composite components, find the outmost service (s0, can be the
same
as
> s1) on the service promotion chain. Create a runtime wire between the
> selected binding of s0 and the component that defines s1. (Can we
assume
> that s1 is always local to s0?)
>
> The service/reference promotions make the picture complicated. I
hope my
> thought makes sense.
>
> Thanks,
> Raymond
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




I'm not sure what a RuntimeContext would do either.

Currently we have Interceptors and TargetInvokers. Both have an invoke 
method, so I'm going to make a simplifying assumption and not distinguish 
the two for now, and just call them Invokers here.

Then I think that we need to be able to associate an Invoker with a 
ComponentService. If I want to add to Tuscany support for a new Component 
implementation type, I need to be able to provide a specific 
implementation of Invoker to deal with the specifics of dispatching an 
invocation to my component implementation. I'd suggest to call what 
creates the Invoker an ImplementationInvokerFactory with a 
createInvoker(Component component, ComponentService componentService, 
Operation operation) method.

Then, if I want to provide a new Binding for use on ComponentReferences, 
I'll need the same kind of Invoker and Factory, something like 
ReferenceBindingInvokerFactory.createInvoker(Component component, 
ComponentReference, Operation operation).

The most obvious way to connect these factories with the assembly model 
IMO is to extend the model classes to implement the factory interfaces. 
For example:
class RuntimeJavaImplementation extends JavaImplementationImpl implements 
ImplementationInvokerFactory {
 Invoker createInvoker(...) {
   // here create a Java specific invoker
   // you have handy the implementation, component and service models
 }
}

and for a Binding:
class RuntimeAxis2WebServiceBinding extendsWebServiceBindingImpl 
implements ReferenceBindingInvokerFactory {
 Invoker createInvoker(...) {
   // here create an Axis2 WebService specific invoker
   // you have handy the binding, component and reference models
 }
}

Finally, I'm not sure that we need to define anything generic for Bindings 
on ComponentServices, as the form of the code handling incoming 
interactions will probably always be imposed by the particular protocol, 
middleware and/or hosting environments. For example today our Axis2 and 
JSON-RPC Service bindings are implemented as Servlets.

One aspect not discussed here is the management of component 
implementation instances and integration with our scope mechanism, but I 
think that this can be discussed separately.

Thoughts?

--
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]