On Jul 25, 2006, at 10:50 AM, Scott Kurz wrote:
I have a couple thoughts on the subject of Host APIs:
First, I think it would be valuable for the host environment to be
able to
access any CompositeContext via some sort of namespace of Composites
registered with a given runtime instance... or to at least access any
top-level Composite.
(Maybe it would best left up to the host environment to manage the
naming
convention and not Tuscany. )
Composite's in the runtime are organized into a navigable hierarchy
that the host (or anything with access to the runtime) can access.
This specifically excludes normal application code as that has no
real business digging around in the runtime. However, it should be
available though alternative APIs such as those used for management
(which suitably privileged user code could use).
For example, IIRC, back in the March tagged version (and probably
still in
M1) a given module was registered under the runtime context along
with a key
corresponding to the name of the WAR (or maybe it was the WAR's
context
root) that the module was packaged in.
When you deploy a ComponentDefinition, its name is used as the name
of the node in the tree of runtime Components. This gives the host
(specifically whatever code is invoking the deployer) complete
control over the name of the node.
Some sort of global Tuscany naming scheme seems like it useful.
For one, it
would give the host more flexibility in setting up
CurrentCompositeContext
(assuming the spec leaves something to the implementation here). I
also
have it in my mind that this would help in implementing a binding,
allowing
the binding to grab the right CompositeContext and the
EntryPointContext out
of it. However, in reading other emails I can see that what other
people
have in mind is to use a separate host API to register a specific
reference
with a binding-level object.
As above, the host has complete control over naming already.
The builder for the binding type has complete control over what
information is made available to the binding. A runtime artifact like
a binding should not be "grabbing" anything from the system - a major
feature of the SCA wiring model is that it allows these references to
be resolved by the runtime in advance.
The host SPI is a way of abstracting the host environment from
Tuscany runtime components so that the builders do not get tied to a
specific environment. For example, a web-service Service binding may
want to receive requests on a specific URL. It needs a way to
communicate to the host that requests over the HTTP protocol for a
certain URL (or URL pattern) should be directed to it. It may not
actually care if the host implements this as a servlet, a Tomcat
handler, an async channel, a HTTPD module, or whatever.
A key thing here is that the contact between the host and the runtime
is bidirectional - the host uses APIs implemented by the runtime to
perform operations on the Tuscany environment, and Tuscany service
components use SPIs implemented by the host to perform operations on
the host environment.
Second, I wonder if a single system-level WorkManager is too coarse-
grained,
and if instead it would be nicer to provide a WorkManager setter at
other
levels, (say, for specific bindings). I understand Jeremy's point
that a
single WorkManager allows for a single point of configuration for the
underlying thread pool. However, if the host environment has
disparate
thread pools and/or WorkManagers to begin with then it would have
to provide
a single WorkManager facade just for Tuscany just to defer the
complexity to
another level.
I think that it is better for the host to provide such a facade over
its complexity rather than expose that to Tuscany services.
What we do need to do is provide metadata with submitted work so that
the work manager implementation has the information to make the
decisions on how to route the work request. For example, we should
add information about how long work is expected to run, whether it is
likely to block on I/O, what priority it has relative to other work,
and so forth.
And as Jim said, there is nothing to prevent you from deploying
multiple work managers and explicitly wiring things to them. If a
component has a need for a dedicated thread pool it can set one up.
Before doing that though it would be worth considering the implications.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
