Hi Crhis snip...
> > > I can see how the samples are working, as Tuscany has automatic access > to the files required as they are included within the same jars, but > assume I have a DAO component which implements a service > HibernateProductDAO which provides a Hibernate specific implementation > of the ProductDAO interface. If our full application is deployed in a > component oriented fashion, then ideally I would like to be able to > say... ok this single component needs a bug fix. Fix the bug and > repackage this single component and redeploy. At the moment our deployment granularity is at the composite level rather than the component level. As long as you build a composite with just the HibernateProductDAO component in it you will be able to deploy this component in isolation. You are not restricted to any particular number of composites in your application. Components from one composite can reference components in another composite, composites can be included in other composites, composites can be assembled recursively using implementation.composite. > So say > HibernateProductDAO_1.5.jar is sitting with component contained within > (and a composite mapping?) and I would like to get this into my > application. Would it be as simple as dropping it within the shared > lib/classpath of the webcontainer and will Tuscany be able to find it? Replacing a component with a bug fixed implementation implies stopping and restarting the component. As your component is wrapped in a single composite this can be as simple as stopping and restarting the node that is running the composite that holds the HibernateProductDAO component. This will work today if you are running Tuscany from some command line launcher. It may even work if you are deploying as a webapp. The deep integration isn't done yet so the webapp will have to include all of the Tuscany jars. > > > Thanks again > > Chris > I think we should start to get a little more specific... A) We might have a composite for the DAO... <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"; targetNamespace="http://test"; xmlns:test="http://test"; name="dao"> <component name="ProductDAO"> <implementation.java class="product.impl.HibernateProductDAOImpl" /> <service name="ProductInfo"> <interface.java interface="product.ProductDAO"/> <tuscany:binding.jsonrpc uri="http://myhost:8080//ProductInfo"/> </service> </component> </composite> B) And another composite for the client app <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"; targetNamespace="http://test"; name="client"> <component name="Products"> <tuscany:implementation.widget location="uiservices/product.html"/> <service name="Widget"> <tuscany:binding.http uri="/ui"/> </service> <reference name="productDAO"> <tuscany:binding.jsonrpc uri="http://myhost:8080//ProductInfo";> </reference> </component> </composite> C) And some javascriptin the browser which exercises this <html> <head> <title>Store</title> <script type="text/javascript" src="products.js"></script> <script language="JavaScript"> //@Reference var products= new Reference("productDAO"); etc.. I haven't actually run this so there may be typos but let me explain... A) is deployed as a stand-alone contribution to some runtime (could be webapp or could be standalone). The result of running up the "dao" composite is an a live service at the endpoint http://myhost:8080//ProductInfo. This endpoint will respone to JSONRPC requests. B) and C) are wrapped together into a war contribution (along with all of the Tuscany jars) and deployed to a webapp container. When the webapp starts up you can point you browser at http://myhost:8080/mywebapp/uiservices/product.html. This will return javascript C) and, on the fly, build the javascript "products.js" which contains the references for the Products component from B). The reference in B) happens to refer to our ProductDOA componenent service that is running elsewhere. Hence the javascript in the browser can talk directly to the ProductsDOA service. If we chose to stop and restart the runtime running the "dao" composite. Say if we wanted upgrade it. We could do that without affecting the client component as long as the resulting service comes back with the endpoint http://myhost:8080//ProductInfo. The same pattern works for any component that references another component. I used a fairly complicated widget component implementation here that we use for creating web2.0 type applications where the browser talks directly to back end services. You can of course have server side UI generating component doing the same job. make any sense? Regards Simon
