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. ) 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. 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. 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. Not sure which is better, and since I'm not backing up this suggestion with code now just consider it food for thought for now. Scott Kurz On 7/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
Comments inline ... On Jul 19, 2006, at 5:20 PM, scabooz wrote: > Jeremy (and others of course), > There have been a few recent threads that have touched on the > various aspects of how Tuscany might be imbedded in a larger > runtime environment. At least Jeremy is already starting to form > a mental model of what that should look like, so I'm wondering > if someone could elaborate more in general about what you're > thinking. Questions like the following come to mind: > 1) Is there a distribution for imbedders? There might be a more fundamental question here: what's a distribution? For M1, we focused on a end-user distribution, by which I mean something someone could download, unpack and everything that they needed to run Tuscany would be there. As a result it ended by a bit kitchen-sick like containing, for example, Tomcat, Axis2, Celtix, etc. and ended up just a tadge under 50MB in size. I don't think this will scale as we add more functionality. I would suggest that we continue to produce distributions aimed at end-users but tailor them to particular runtime environments. Specific ones that come to mind would be a simple client, one with Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so on. These may include the environment (like we did with Tomcat in M1) or they may packages that can install on top (e.g. as a CAR for Geronimo). Each one of these would be tailored for the runtime - for example, the Tomcat one would be web-oriented, the Celtix one message- oriented. The baseline distribution could be extended by adding in plugins that would be distributed separately. This is a similar model to e.g. Eclipse, Maven, etc. We would also distribute each module from the build through the Maven repository system. During incubation, all artifacts would be available from the Apache snapshot repository; post-incubation, released artifacts would also be available through the mirror system (e.g. from ibiblio.org). Someone looking to embed Tuscany could go about it in a couple of ways. One would be to start with one of our distributions, take it apart and integrate it into their environment. This would have the advantage that all artifacts would have been tested to work with each other but may mean that they are dependent on more than they need or that they would have to wait for a full release to get fixes etc. Alternatively they could work directly with the artifacts from the maven repo. In trunk we are now using the maven assembly plugin to build the distribution and it would be trivial for someone to assemble a different distribution just be reconfiguring that plugin. > 2) Is the runtime config mechanism extensible enough? It's based on the SCA config mechanism so I hope so - otherwise we will have valuable feedback for the spec ;-) The runtime is constructed by deploying a SCA component implemented by an SCA composite (which contains other SCA components). Which components are present are determined by the content of the composite and they can be configured in the same way any component can (including via xpath expressions once we get complex properties working). > 3) Is the build modular enough to only build the pieces you want to > imbed? I saw some posts on modularizing the build > that seemed useful. At this point probably not - for example, in order to work around the issues building JAXB Meeraj had to hack a couple of the pom files and that is not very desirable. As you said there have been a couple of posts on making the build more modular and it may be better to continue on that thread. > 4) What's the right way to think about Tuscany in relation to a > hosting environment? Is it always imbedded or are there use > cases where server function in imbedded in Tuscany? > I consider the "core" to be the bit that is always embedded in some host environment, with the core being the bit that provides the SPIs and the framework for running system services. The host is responsible for bootstrapping the basic runtime and for determining which services will be started. Such services will include things like programming models, bindings and policies as well as normal application components. Different hosts will start different services depending on what type of host they are. Some may just be clients, some may start "server" services in Tuscany and some may start "bridge" services that transfer function between the host and the Tuscany runtime. > ...there's many more questions... We probably should work on a guide for embedding Tuscany with more information on the bootstrap APIs. So, ask away so we can get the right information there and tidy up the JavaDoc. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
