Hi Chris Some more thoughts and some comments in line..
A service is defined by a contract/interface and collects together a set of related operations. A service may provide an endpoint through which remote clients can access it over the network A component provides the implementation for one or more services and in doing so can define references to other services A composite assembles together components into a working application by wiring references to services A contribution is the deployment packaging for a composite and can collect together the composite and all of the artifacts it requires to run, e.g. .java, .xml, .xsd. wsdl files etc. A contribution in SCA can be any hierarchical mechanism the we use today for collecting artifacts together, e.g. a directory on a file system, a zip, jar or war etc. A contribution does not define a new format for storing artifacts. Hope this helps Simon On Fri, Jun 6, 2008 at 4:29 PM, Miles, Chris <[EMAIL PROTECTED]> wrote: > Simon, > > Thanks for the response again. > > I understand a little better now; however some parts of it still leave > me a little stumped. How these physical units would be packaged and > moved around. They should be packaged in whatever schemes you are familiar with today for collecting together application artifacts for deployment. The exact mechanism chosen will depend on which container is going to run the SCA application. E.g. if its going to run in a web app container the contribution is likely to be a war. If its going to be run using a command line based Tuscany runtime then the contribution could well be a directory structure or a jar. > > > If I have a webapp with JSP, Servlets and the other usual bits and bobs. > This would be packaged in it's normal war and deployed to the server > (which happens to be OC4J just now). > Yep > > I then want a business layer as a component. If this was being deployed > somewhere there would need to be some sort of intelligent process which > picks it up and registers it somewhere. I suppose a quartz job or a > timertask running checks against the file system could do something to > this effect, but it feels I would then be adding extra layers of > complexity to my application. Are you suggesting here that components are deployed and activated in the same way that wars are activated, for example, in Tomcat by dropping the war into the tomcat/webapps directory. There are two approaches. 1. add the Tuscany and dependency jars to the war itself. This should work today. See samples/calculator-webapp 2. do some deep integration with the web app container so that the Tuscany and dependency jars don't have to be added to the war. Ant is looking at this for Tomcat at the moment but it's not done yet. It's not the only way of working with Tuscany though. For example, you can just run Tuscany from the command line and ask it to run up a named composite, This works because if Tuscany is not running within a webapp container it will fire up its own web server (tomcat or jetty) to service web service style requests. See samples/calculator for our most basic sample and samples/helloworld-ws-service and samples/helloworld-ws-reference for a reference that talks to a service remotely over web services. > > The way I feel something like this should work for my purposes is a > standalone daemon running which manages services and components etc (I > am not completely understanding of the exact difference in definition > between components, service and contributions I will be honest). See above:-) The standalone daemon I think is catered for by running Tuscany from the command line. This doesn't support the hot deploy options (although again there has been some work on this in the past). You basically run Tuscany given the composite when you want to start a composite application and the stop the program when you want to stop the application. This > daemon would be have a store of components which it loads when it runs > or they are hot deployed and then any other application or web > application through the use of the Tuscany library can then start > creating objects which this server will provide. This standalone server "Start using services" is probably a better phrase that "start creating objects". Using a service may or may now involve creating new objects. This depends on the scope of the component and the type of processing the component does. In the case where you are reading business object from a database I can imagine that the business object we be created when you make a request for information. The component instance may or may not be created afresh depending on whether you want the component to display some stateful behaviour, for example, so that you can hold a conversation with it. > may be some other application which could be deployed to the web > container/sever instead of a separate running process. Yes, once you have defined your composite application you should be able to deploy it either as a web app or using Tuscany running from the command line. > > If I am way off the mark on the merits of SCA then please let me know, > but all I know is I am trying to get a more lightweight version of the > old JNDI lookup of beans within my web container. :) Doesn't sound like you are way off. I think we need to convince ourselves we are talking the same language;-) > > Any other ideas or suggestions would be greatly appreciated. > > Thanks again > > Chris >
