On 10/4/07, ant elder <[EMAIL PROTECTED]> wrote: > > On 10/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > ant elder wrote: > > > On 9/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > <snip> > > > > > > Here's sample code to illustrate that use case: > > > > > >> > > > http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/samples/ > > >> SampleTuscanyDomainImplementation.java > > >> > > > > > > > > > Why does that sample need to add and start composites with: > > > > > > // Add the Calculator deployable composite to the domain > > composite > > > domain.addComposite(new QName("http://calc";, "Calculator")); > > > > > > // Start the Calculator composite > > > domain.startComposite(new QName("http://calc";, > "Calculator")); > > > > > > The contribution jar is going to have the sca-contribution.xml (or the > > > composites in the "deployables" folder we once talked of supporting), > > > > No, sca-contribution.xml is optional. > > > > > so > > > can't the simplest case just be adding the contribution and the > > deployable > > > composites get started automatically? > > > > > > > I don't think that having to write a sca-contribution.xml file is the > > simplest case. > > > > <contribution xmlns="http://www.osoa.org/xmlns/sca/1.0"; > > targetNamespace="http://calc"; > > xmlns:sample="http://calc";> > > <deployable composite="calc:Calculator"/> > > </contribution> > > > > vs > > > > domain.addComposite(new QName("http://calc";, "Calculator")); > > > > Placing the composite file under META-INF/deployables will appear simple > > to some people, but will not necessarily play well with other people > > using IDEs for example which often hide META-INF, or people who are not > > used to place their development artifacts, .wsdl, .xsd, .componentType, > > or .composite... under META-INF. > > > Agree about sca-contribution.xml not being simplest nor > META-INF/deployables, but we've had this discussion before and couldn't > get > much agreement on anything else. Take the Tuscany/Geronimo integration as > an > example, deploying an sca contribution jar on that and the code can only > tell which composites to add based on somethng like sca-contribution.xmlor > doing some default behaviour like add all composites or add no composites. > > Does the spec say anywhere that when there is no sca-contribution.xml then > composites in a contribution must not be added by default? > > ...ant >
Having been stumped for a couple of days with various build problems I've now checked in the first pass on some new domain/node interfaces for people to play with and evolve. A good place to look first are the unit tests in the node implementation as they show the new interfaces being used... Driven from the node API http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/node-impl/src/test/java/org/apache/tuscany/sca/node/impl/NodeDrivenTestCase.java Driven from the domain API http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/node-impl/src/test/java/org/apache/tuscany/sca/node/impl/DomainDrivenTestCase.java Some notes on the changes... 1- I reinstated node-api, These are the modules now... Domain represents the abstract domain domain = domain SPI (should we rename to domain-spi?) domain-api = domain API domain-impl = implements the API and SPI Node represents the node and domain proxy in a JVM node - node SPI (should we rename to node-SPI?) node-api = node API node-impl = implements the API and SPI 2 - to get references to services local to the JVM your program is running in you have to get the domain from the node so I have gone back to Sebastien's original suggestion of having getDomain return an SCADomain. I'm not so comfortable with this but its currently an implementation convenience. I want to have all the nodes in a JVM associated with a single local domain representation. But the code just isn't structured to support this at the moment hence the current approach. 3 - Following on from 2 SCADomainFinder doesn't do anything useful as it creates domain representations with no nodes in. Waiting for resolution to 2. 4 - If you are adding multiple contributions to a domain how do combinations of contributions get sent to an individual node? We are expecting some magic in the fullness of time but currently the domain allocates one contribution to each node. I'm not sure exactly what to do with add/start composite. Currently is just adds the composite to all nodes and starts the composite in all nodes as we would need knowledge of which node has which composites to take more targetted approach. It does feels a bit strange addind/starting a composite in a domain but maybe I'll get used to it. 5 - the model in the domain it very light weight and doesn't use assembly model classes. It could but it doesn't at the moment. 6 - I would like to separate the node.composite into domain proxy bits and node management bits.Currently the node management and domain proxy application runs in the local domain representation. This is one of the reasons why it will take a little work to allow multiple nodes to associate with the local domain object. 7 - There is repetition of code and APIs that need tidying. 8 - I've not done anything with the component manager yet but I've left it in to refer back to. 9 - It's been instructive using SCA itself to implementation the node management and domain applications. The big issue I have is dynamically configuring endpoints. The programming mode, runtime is not currently set up to let me choose dynamically what endpoints to used. I only get the options to set it in, the SCDL, the host environment or accept the defaults. This causes problems in setting up the node endpoint as you probably want to specify that. Also the domain has to be able to talk to all of the nodes. Ideally, I'd like to register nodes with a callable reference back to their endpoints but it doesn't quite work that way just yet (when I wrote that bit originally passing callable references remotely didn't work) 10 - Passing URL/QNames across web services causes the JVM to crash on my machine. I'll raise a JIRA if I can tie this down a bit. 11 - The tool integration in HostEmbedded needs fixing up Anyhow, quite a few issues but I wasted a lot of time on the build this week so I wanted to get this checked in for people to play with rather than spend a lot more time polishing it. Regards Simon
