On 6/26/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Here are a few thoughts and questions on our SPI story. I'd like to start a discussion on these items and get your thoughts.
Cool. My first thought is that what you're describing here is very close to what we have in the sandbox - for example, common themes of modularity and removing complexity. I've added a few more detailed comments inline.
A. I think we should create different projects for the various types of SPI we have, for example one project for the assembly model SPI, one project for the interaction/invocation related SPI, one project for the deployment SPI, one for the management SPI etc.
This sounds good, especially when we deal with high level building blocks like management. One thing I think we need to be careful of though is breaking it down too far so that we force users to understand several different modules just to do something simple. I think we can address that with the right package structure in each module.
If these SPI go into a spec at some point this will allow us to publish them and evolve them independently.
Agreed. We are actually leading the spec here which gives us a chance to influence the direction it is taking. However, when the spec actually adopts something the classes will move from the o.a.t namespace to the org.osoa one which will impact users and implementations. We can handle those changes for both separate modules and individual packages within a module.
I also think that this allows to cut complexity, for example a contributor only interested in management will not get the other SPIs. More generally, somebody assembling/embedding a Tuscany runtime will be in a better position to pick a subset of selected pieces.
Cutting complexity is good and we can help with that by making sure that things that naturally go together are bundled together. For example, someone writing an extension should not need to dig through several modules to figure out what they need to do.
Finally this shows a clear path to people who want to extend the runtime, for example, if we put the java interface support in a different project, the WSDL interface support in another one, then somebody wanting to add ruby or javascript support will have a clear template to follow.
I'm not sure what you mean here. This sounds like two implementations of a "pluggable interface type" SPI - one for Java interfaces, one for WSDL ones - which I think would be a good way to break this down.
B. I'd like to separate interfaces and implementation classes or helpers in different projects.
Wholeheartedly agree on the separation between interface and implementation. In M1 we did this but had both inside the same module which was confusing; one of the things we did in the sandbox was to move the interfaces into spi and leave the implementation in core. I think helpers can go either way. If they are useful (but optional) to any implementation of the interface, then we can reduce the complexity by including them with the SPI. An example of this would be the extension base classes that contain functionality to support an implementation but which (in general) don't implement the interface contracts. On the other hand, classes that support a specific implementation should just be part of it (directly or in the form of a library).
For example the assembly model interfaces would go into one project, the Tuscany implementation of these interfaces in a different one. In M1 we have interfaces+implementation classes but they are in the same project, in the sandbox there's no interfaces anymore for this, can you guys tell me what motivated that change?
Simplicity really. The model objects are really just data holders (set and get methods only) and don't contain significant implementation.
Separate interfaces and implementation classes will allow us to swap different implementations (e.g. using different databindings, or integrated with tooling for example). It will also allow model extensions to not depend on Tuscany implementations classes (the extensions will only implement interfaces instead of extending implementation classes). C. I would like to change the project folder structure a little and introduce a plugins/ directory where contributors could drop their extension projects/modules. It is not clear to me anymore that we need different bindings/ and containers/ folders. I'm thinking more and more that the programming model for component implementation extensions and binding extensions should be the same. Some plugins will not be implementation or binding specific, for example it should be possible to contribute a plugin that provides support for a new interface definition language. Also these plugins will have to contribute multiple extensions covering codegen/development, model, validation, deployment, install, invocation, management etc.
I think we're heading the same way here. To me, containers and bindings were just a couple of types of plugin - two types out of many, there were also system services, tools and so on. Moving the plugins into a location separate from the core makes sense. On a closing note, I'd suggest there a couple of concrete things we can look at: 1) Look at the spi package and see if we can identify things that stand alone and could be broken out. For example, I've been thinking we might bundle deployer, model, loader and builder together in a deployment package. 2) Look at our deployment story and see how we can package plugins. I think a couple of people have suggested that OSGi bundling may work for us. Having a management API for deploying new modules would be good too. 3) Keep looking at the extension interfaces and see how they fit with actual extensions. You mentioned javascript and ruby containers and I think Ant was looking at how rhino could work with the sandbox code. Jim, Dan and Jervis are working on getting Celtix to work with it; it would be interesting to see how Axis2 fitted in. 4) Let's look at some of the newer more complex areas such as Raymond's data mapping, Ant's interface representation, or the async stuff Scott mentioned and see if the SPIs we have work or if they need to be tweaked. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
