Re: Imbedded model
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]
Re: Imbedded model
On Jul 25, 2006, at 7:24 PM, Scott Kurz wrote: So the method I was referring to had signature: ModuleComponent loadModuleComponent(String name, String uri) The replacement is Component deploy(CompositeComponent parent, ComponentDefinition componentDefinition) where the parent determines which composite the new component will be added to and the definition contains things like the name of the component etc. The name and uri are not calculated by Tuscany, and not implicit in the SCDL. They are supplied by the host in the definition being deployed. 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? For now we do name. Adding URI should be easy once we figure out what it should be (from the spec) - in 0.9 we mostly ignored it. Maybe this will be one option among several, including some where the name,uri are supplied by Tuscany or calculated somehow. Depends what you mean by "Tuscany" - the core will never take a guess at these, it will always use values supplied to the deployer. They could be specified by the user, or they could be determined by the deployment environment (for example, the directory scanner uses the filename sans extension as the component name). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imbedded model
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),
Re: Imbedded model
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. 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. 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. 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 repos
Re: Imbedded model
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 th
Re: Imbedded model
On Jul 19, 2006, at 6:36 PM, Ken Tam wrote: I'm about to check-in some code to support embedding Tuscany in any servlet container -- mostly a servlet listener that launches the runtime. It's not a lot of code (if it were, I'd be worried :), but I could still see moving it out into a separate place in the svn tree & build, once we figure out the layout/strategy for that. There's currently a "runtime" dir under "sca" where the equinox OSGi and "standalone" runtimes live.. but the standalone being just a packaging thing, and the equinox code isn't active in the build currently. In another post I had proposed moving "standalone" into "distribution/ sca/standalone" to make it closer to what we had in M1. I was thinking that all assembly/packaging stuff would be there. If we do that, then perhaps your webapp support code and the equinox (OSGi support) code become modules under runtime and we put all host- integration type stuff there. I'm building off the core.launcher pkg, which seems flexible enough with some tweaks. I haven't thought too hard yet about further modularization -- I don't grok the code well enough yet to have a strong opinion.. Looking forward to the tweaks ;-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imbedded model
On Jul 19, 2006, at 6:36 PM, Ken Tam wrote: I'm about to check-in some code to support embedding Tuscany in any servlet container -- mostly a servlet listener that launches the runtime. It's not a lot of code (if it were, I'd be worried :), but I could still see moving it out into a separate place in the svn tree & build, once we figure out the layout/strategy for that. That may be good so we're consistent across environments. There's currently a "runtime" dir under "sca" where the equinox OSGi and "standalone" runtimes live.. but the standalone being just a packaging thing, and the equinox code isn't active in the build currently. I'm building off the core.launcher pkg, which seems flexible enough with some tweaks. I haven't thought too hard yet about further modularization -- I don't grok the code well enough yet to have a strong opinion.. 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? This is a key question IMO. I've been thinking mostly in terms of Tuscany embedding in existing server environments, mostly because those strike me as the most compelling use cases at this point (given SCA as a technology that purports to ease integration). But there's no reason why it can't go the other way around -- e.g. embedding server functionality into Tuscany via something like jetty. Indeed, the current standalone is a very basic "server" that embeds Tuscany. Yea I'm working on the Jetty service now. I got sidetracked because I ran across a configuration issue doing this related to annotation processing (the ability to have constructor injection work with multiple annotation extensions) so I've been spending time on getting that working. On 7/19/06, scabooz <[EMAIL PROTECTED]> 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? 2) Is the runtime config mechanism extensible enough? 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. ...there's many more questions... Hopefully that's enough to provoke a discussion. Dave Booz - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imbedded model
Just a few minor comments inline... On Jul 19, 2006, at 6:33 PM, Jeremy Boynes 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. One of the things we've been toying with (alluded to by Jeremy) is the (optional) ability for the core to pull down extension dependencies from maven repositories. This would be kind of like the server equivalent to Eclipse's plugin installation. 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). Dave, it would be good if you can also outline some of the use cases you have in mind so we can make sure we cover them. 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 run
Re: Imbedded model
I'm about to check-in some code to support embedding Tuscany in any servlet container -- mostly a servlet listener that launches the runtime. It's not a lot of code (if it were, I'd be worried :), but I could still see moving it out into a separate place in the svn tree & build, once we figure out the layout/strategy for that. There's currently a "runtime" dir under "sca" where the equinox OSGi and "standalone" runtimes live.. but the standalone being just a packaging thing, and the equinox code isn't active in the build currently. I'm building off the core.launcher pkg, which seems flexible enough with some tweaks. I haven't thought too hard yet about further modularization -- I don't grok the code well enough yet to have a strong opinion.. 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? This is a key question IMO. I've been thinking mostly in terms of Tuscany embedding in existing server environments, mostly because those strike me as the most compelling use cases at this point (given SCA as a technology that purports to ease integration). But there's no reason why it can't go the other way around -- e.g. embedding server functionality into Tuscany via something like jetty. Indeed, the current standalone is a very basic "server" that embeds Tuscany. On 7/19/06, scabooz <[EMAIL PROTECTED]> 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? 2) Is the runtime config mechanism extensible enough? 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. ...there's many more questions... Hopefully that's enough to provoke a discussion. Dave Booz - 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]
Re: Imbedded model
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]
Imbedded model
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? 2) Is the runtime config mechanism extensible enough? 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. 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? ...there's many more questions... Hopefully that's enough to provoke a discussion. Dave Booz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
