Hi Monosij,
thank you for that very helpful post. Is anyone still using the Tuscany Wiki? There isn’t much up-to-date stuff in it, but perhaps it would be worthwhile including information like this. What do people think – should one create a new top-level page “Using Tuscany: Tips and Pitfalls” or somesuch to collect posts like Monosij’s summary? n Sebastian From: Monosij Dutta-Roy [mailto:monosij.for...@gmail.com] Sent: Wednesday, May 04, 2011 4:21 AM To: user@tuscany.apache.org Subject: Summary: Basic configuration aspects in SCA I want to take a moment and update on a discussion thread - with Simon Nash and also with Ant Elder - and try to summarize my understanding to confirm they are valid. Both have helped me a lot through this startup. Thanks! New to SCA and such so had gotten some of the aspects on linking mixed up. I will try to keep it to as plain English as possible. The context for the points below is a set of contributions interlinked - and servicing web-app requests (or any), but web-app for this discussion. So a REQUEST / RESPONSE scenario. -------------------- 1. In having multiple contributions with composites from one contribution linked to a composite in another contribution - the main reason for having linkage through <service> / <reference> is for request handling and NOT for response handling. If I have a Contribution-1 / Composite-A that needs to pass a Request (as - say a HashMap) to another Contribution-2 / Composite-B: Composite-B needs to be <service> and be <referenced> from Composite-A. or be Composite-B needs to be <wired> to Composite-A. -------------------- 2. It is best to return the Response from Composite-B to Composite-A through a POJO and not have any Java object enclosing it. If Composite-B returns a list of Patients - just return an ArrayList and not encapsulate the ArrayList in a QueryResponse object that has the ArrayList. To return it through another object will NOT work as a plain return. That object (QueryResponse) will then need to be setup as a <ServiceReference> object in SCA and things get a little complicated from here. In short: this <ServiceReference> object (the QueryRsponse) then needs to be setup in a HashMap that will be uniquely identified by the original Request and be picked up by the Requesting object (Contribution-1 / Composite-A) from this HashMap - and cleaned up and such. Thus the implementation becomes SCA specific. -------------------- 3. <wired> vs <reference> Best to link Contribution-2 / Composite-B as <reference> to Contribution-2 / Composite-B and not wired, while both can be done. <wired> does not work between domains - so if you decided to move Contribution-2 / Composite-B to a different domain all <wired> needs to be redefined as <reference>. QUES: So why have the option of <wired> at all? Maybe to make sure that a contribution cannot be moved to a different domain? -------------------- 4, Response with POJO or JAXB datatype. When reposnding with a POJO - its best to have it as a JAXB datatype as it will also make the Response compatible with ws.binding. Returning an ArrayList will work between contributions in a java binding - but then to use web services need to use JAXB datatypes. -------------------- 5. sca-contribution.xml Again when using multiple contributions it is important to have the sca-contribution.xml file have the right imports and exports and the xmlns named correctly in that file. Also there is an order to the elements: deployable then import then export. -------------------- Given a basic understanding of contributions, composites, service, reference, wired - the above points should allow one to set up a loosely structured app framework using SCA and allow ws.binding (with JAXB) and of course the available java binding. I found that I needed to get the above in order to make the app very loosely structured into separate contributions. I hope it is correct and please feel free to correct any inconsistencies. I am sending this as a summary to discussions with Simon Nash and Ant Elder who have helped me much through all this. Thanks.
