Jim, Thanks for your response..replies below...
On 7/25/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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. ) > For management purposes it may make sense for a host to access composites but I think it should recurse through the composite tree as opposed to having a global namespace. > 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. > I think this is problematic. In the spec we were careful not to tie the addressing scheme to the structure of the composite tree since URIs shouldn't necessarily reflect "application" structure.
Yes, I figured the namespace would be hierarchical, not flat. I mentioned the "old" (not really so old since M1 worked this way too) Tomcat integration's use of WAR-level info to pass as the 'name' and 'uri' on this call ... not because this was a good way to do it... but to illustrate that it was the host environment that determines the name and uri to "register" a composite context at. So the method I was referring to had signature: ModuleComponent loadModuleComponent(String name, String uri) The name and uri are not calculated by Tuscany, and not implicit in the SCDL. Maybe I should have phrased my question: will Tuscany's host API support registration of Composite Context name and uri supplied by the host environment? Maybe this will be one option among several, including some where the name,uri are supplied by Tuscany or calculated somehow.
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. This may be more complicated than what we need. A basic notification/ registration mechanism (e.g. the host API) allows the binding to stay simple, decouples references from protocol bindings (e.g. Axis) from transport bindings (e.g. Jetty) and maintains a separation between configuration and runtime artifacts. For example, I'm not sure it is a good thing for binding code to interpret SCDL and then dig around in the composite tree for a service or reference.
I've read a few statements now saying this sort of thing: from Jeremy, in the callbacks discussion, here. However I'm too dense to really envision what you're talking about until seeing a sample of how this type of scheme works. The JettyServiceImpl I see now (grabbed Friday) only seems to "implement" one Host API, the ServletHost.. however I put that in quotes since the registerMapping() method is actually left blank. So this obviously isn't what everyone is talking about. I look forward to seeing the first example of this type of implementation so I can follow this discussion better.
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). We can do this today with autowire; it's just a matter of configuration. One thing we may want is some notion of priority queues though. > 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. > Tuscany could wire to multiple work managers as well. We aren't bound to one, although as an out-of-the-box configuration it seems like a good idea.
Thanks for clarifying that.
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. > Ideas are always good :-) Keep them coming. > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
