On Feb 20, 2006, at 8:56 AM, hung tran wrote:
Hi Jim,
I hope this makes it clearer, otherwise i'll give it another shot :)
From: Jim Marino <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: dynamic invocation...again
Date: Fri, 17 Feb 2006 14:39:39 -0800
Hi Hung,
I'm not quite sure I follow...
On Feb 17, 2006, at 12:09 PM, hung tran wrote:
Hi Tuscans,
I had previously posted a question regarding dynamic invocation,
which i believe i didn't word clearly enough.
I would like to build a test tool, with a runtime piece sitting
as part of the container.
I assume here you want to have some type of code that sits
"inside" the runtime and performs some type of analysis. Could
you provide some use case so I understand better?
say you've developed a component and want to see that it works. To
do that at the very least, you'd need to create an entrypoint and
then some sort of client - a jsp for instance - to invoke it.
Well I'd like to simplify that, such that you could test the
component as you develop without having to build these extra
artifacts just to see if it works.
You don't need an entry point to invoke a component from a JSP (or
unit test, etc.) assuming the module context is set properly - just
use ModuleContext.locateService(). You can also use the
RuntimeContext and AggregateContext APIs (see the unit tests in core
for how that is done). There are some limitations with the latter
APIs, however:
- Currently, there is no API to dynamically navigate the aggregate
context hierarchy. You need to know the name of the aggregate context
when you call AggregateContext.getInstance(..). We could easily add
the ability to return the collection of child contexts.
- How one gets ahold of RuntimeContext will be depoyment platform
(e.g. Tomcat, Geronimo, etc.) specific.
So the most important part of this enablement is to be able to
invoke this particularcomponent. The best way I found to do this
is to (as you said) 'sit inside the runtime' and perform this
invocation. Since I'll only know of the component at runtime, I'll
need to dynamically obtain the service on that component. I
believe this can be best done if i'm inside the runtime.
There are several options here:
- You can have something that "sits" inside the deployment
environment but not "inside" RuntimeContext (the Tuscany runtime).
This just walks RuntimeContext and its aggregates.
- You develop a system component which "sits" in a system aggregate
in the runtime (see SystemAggregateContext) and provides the
monitoring facilities.
The goal is to be able to invoke any component in any module in any
(sub)system, so i'll need to invoke by name as rather than by
reference.
Could you elaborate what you mean "by name" vs. "by reference"
and give a use case here?
Well, currently when you look up a service, it would be casted to
an interface that is known,
then the desired method on that interface is called.
ie
HelloWorldService helloworldService = (HelloWorldService)
moduleContext.locateService("HelloWorldService");
helloworldService.getGreetings("world");
which is what i would call be reference.
With 'by name' I only know the string values of the service and the
operation, thus i won't be able to preform any casting. I guess it
would be similar to java reflection.
I would use the logical model to find out the service and then use
reflection to get at the method for the operation. This presumably
could be done with a DII, which we don't have yet in the spec. One
thing I don't want to do is cast from the business interface to the
DII since it would require proxies, mixins, or subclassing on
everything returned by locateService(..). I'd rather see a separate
API, or better, just use Java reflection.
As a part of the runtime, I assume I'll be granted access to
APIs not available to clients, thus my question is whether there
is currently a way for me to perform this action or is there
anything planned in the near future.
There are APIs that are not part of the SCA spec and we could
certainly add additional ones if appropriate. If we can pinpoint
the use cases, I can tell you if there are existing ones.
I'll need to be able to create objects in the context of the
desired module, as well as impersonate the module when invoking.
You can create "components" (actually InstanceContexts) in a
"module" (actually an AggregateContext) so this may be what you
need. What do you mean by impersonate?
By impersonating, i'm trying to say that when i'm invoking a
particular component in that module,
i get the same priviledges and resources as if I'm calling from
within the module.
Right now, there is nothing that inhibits locateService other than
needing to be in the correct classloader context (we still need to
add a mechanism for retrieving the classloader for the module). If
there some type of security constraint in the future, we have the
capability to dynamically add (and remove) entry points which could
mitigate that. You could also create a component which is deployed
dynamically in a module that calls into other components.
If you have a specific set of use cases, I'd be happy to map them to
the APIs we currently have and see where the gaps are. Let me know
if you would like to do that.
Jim
I've been digging around the tuscany code and have a faint idea,
but would appreciate some help, and additionally to create some
dialog in this general area as I believe it might be useful to
others.
Yes the docs are lacking and there is quite a bit of churn. Sorry
about that. We're always happy to help so if you can provide more
specifics, I can answer your questions better.
Jim
thanks,
hung
_________________________________________________________________
Scan and help eliminate destructive viruses from your inbound and
outbound e-mail and attachments. http://join.msn.com/?pgmarket=en-
ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/
enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of
MSN® Premium right now and get the first two months FREE*.
