Hi Monosij,
Thanks for posting this helpful summary. See comments inline for some
clarifications.
Simon
Monosij Dutta-Roy wrote:
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.
The point here is to not have an SCA service enclosing the returned
response. Enclosing it by a Java object (POJO) is fine.
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.
Again, it's fine to encapsulate this in a QueryResponse object, but
not in a QueryResponse service.
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.
Here again, replace the first two references to "object" by "service".
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.
It's not the ServiceReference object that would need to be set up in a
HashMap. It's the response object for the original request (accessed using
the ServiceReference) that would need to be set up in this way.
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?
Wiring is for convenience when everything is in a single domain. It
avoids needing to provide binding-specific details for the connections
between references and services.
Simon
--------------------
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.
