You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Monosij Dutta-Roy <mo...@gmail.com> on 2011/05/04 04:20:51 UTC
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.
Re: Summary: Basic configuration aspects in SCA
Posted by Simon Nash <na...@apache.org>.
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.
>
Re: Summary: Basic configuration aspects in SCA
Posted by Monosij Dutta-Roy <mo...@gmail.com>.
Thanks. I unfortunately did not relate the POJO aspect correctly - but
thanks for the pointers.
monosij
On Wed, May 4, 2011 at 6:18 PM, Simon Nash <na...@apache.org> wrote:
> Monosij Dutta-Roy wrote:
>
>> hi Simon (Laws) -
>> You are welcome. I have learnt a lot in this process. Its a great
>> framework. And I would be happy to help with summarizing as concisely as
>> possible into a wiki. If you all indicate a thread that needs to be
>> summarized I can move it to a GoogleDoc or such to share it, refine it with
>> you all and then post to the wiki. Of course the GoogleDoc can still be
>> linked with examples and such.
>>
>> You could start by adding your recent post (with corrections as
> appropriate) to the wiki. Once it is there, others can update it as they
> feel necessary.
>
>
> I plan to work with SDO / DAS so can help there as well. Maybe we can try
>> and move towards some Pitfalls / Best Practices with key inter-operable
>> frameworks such as DAS / JDBC / REST / EJB and such. I will try and keep it
>> as simple and concise as possible.
>>
>> Sounds good.
>
>
> You all have a lot of topics in your book to begin with - and maybe some
>> elements could be summarized, re-referenced and referred back to the book
>> pages for reference?
>>
> It's a bit trickier to bring the book into this, because not everyone
> who reads the wiki will have a copy of the book.
>
>
> I can try to address the variability issues that SCA addresses - staring
>> with Languages (CPP, Java,...) and move into the other dimensions. Hopefully
>> will start to use the right terminologies.
>> ----------
>> hi Simon (Nash) -
>> Thanks for the updates and clarifications and your help through this. Now
>> based on your comments below - have a few more to add.
>>
>> 1. I understand the distinction between service and object and will try to
>> refer to it accordingly from now.
>>
>> 2. Regarding returning as a POJO (ArrayList) vs encapsulated in object as
>> QueryResponse (which has the ArrayList) - you say is fine. Good - but when
>> moving to ws.binding and using JAXB datatypes - will that still work?
>> Meaning if I return JAXB datatypes encapsulated in QueryResponse - will that
>> work or would I have to return PO JAXB O? Maybe should come with an acronym
>> here - POXO? Plain Old XML Objects? :-)
>>
>> You're right that all Java objects passed across binding.ws need to
> support
> the JAXB mapping from Java to XML.
>
>
> 3. Reference vs Wire - Thanks for the explanation. Just wanted to mention
>> that I like the aspect of <wire> being outside the <component> definition.
>> Reason, to me, is - as an app gets more complex and assuming multi-domain -
>> it would be good to see all linkage <wires>, <references> - in one place.
>> <reference> does not allow that to happen as it is always withing a
>> <component> definition. <wire> does but then limited by single-domain.
>> It would be good if <wire> (or some other similar) could do that too as -
>> as a developer could just go to the <wire> section and see what has been
>> setup - and not have to go through the <component> definitions. Hope its a
>> valid statement as I have not done a large scale SCA impl yet. But already I
>> feel I want to quickly see what is connected and deciphering <references> in
>> each <component> section becomes tedious. But that's just me, so its a
>> suggestion.
>>
>> I think it's an interesting idea to extend the SCA definition of <wire>
> to do as you are suggesting. To make it happen, someone would need to
> propose it to the OASIS SCA Assembly Technical Committee for the members
> of that committee to consider and decide.
>
> Simon
>
> Great! Thanks again and look forward to contributing.
>>
>> monosij
>>
>>
>> On Wed, May 4, 2011 at 5:19 AM, Simon Nash <nash@apache.org <mailto:
>> nash@apache.org>> wrote:
>>
>> Simon Laws wrote:
>>
>> On Wed, May 4, 2011 at 9:14 AM, Millies, Sebastian
>> <Sebastian.Millies@ids-scheer.com
>> <ma...@ids-scheer.com>> wrote:
>>
>> 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
>>
>>
>>
>>
>> +1 from me. We should probably take a look at the wiki generally
>> and
>> try and remove the cruft that has built up there.
>>
>> Simon
>>
>> +1 for adding information like this to the wiki.
>>
>> Simon
>>
>>
>>
>
Re: Summary: Basic configuration aspects in SCA
Posted by Simon Nash <na...@apache.org>.
Monosij Dutta-Roy wrote:
> hi Simon (Laws) -
>
> You are welcome. I have learnt a lot in this process. Its a great
> framework. And I would be happy to help with summarizing as concisely as
> possible into a wiki. If you all indicate a thread that needs to be
> summarized I can move it to a GoogleDoc or such to share it, refine it
> with you all and then post to the wiki. Of course the GoogleDoc can
> still be linked with examples and such.
>
You could start by adding your recent post (with corrections as
appropriate) to the wiki. Once it is there, others can update it as they
feel necessary.
> I plan to work with SDO / DAS so can help there as well. Maybe we can
> try and move towards some Pitfalls / Best Practices with
> key inter-operable frameworks such as DAS / JDBC / REST / EJB and such.
> I will try and keep it as simple and concise as possible.
>
Sounds good.
> You all have a lot of topics in your book to begin with - and maybe some
> elements could be summarized, re-referenced and referred back to the
> book pages for reference?
>
It's a bit trickier to bring the book into this, because not everyone
who reads the wiki will have a copy of the book.
> I can try to address the variability issues that SCA addresses - staring
> with Languages (CPP, Java,...) and move into the other
> dimensions. Hopefully will start to use the right terminologies.
> ----------
> hi Simon (Nash) -
>
> Thanks for the updates and clarifications and your help through this.
> Now based on your comments below - have a few more to add.
>
> 1. I understand the distinction between service and object and will try
> to refer to it accordingly from now.
>
> 2. Regarding returning as a POJO (ArrayList) vs encapsulated in object
> as QueryResponse (which has the ArrayList) - you say is fine. Good - but
> when moving to ws.binding and using JAXB datatypes - will that still
> work? Meaning if I return JAXB datatypes encapsulated in QueryResponse -
> will that work or would I have to return PO JAXB O? Maybe should come
> with an acronym here - POXO? Plain Old XML Objects? :-)
>
You're right that all Java objects passed across binding.ws need to support
the JAXB mapping from Java to XML.
> 3. Reference vs Wire - Thanks for the explanation. Just wanted to
> mention that I like the aspect of <wire> being outside the <component>
> definition. Reason, to me, is - as an app gets more complex and assuming
> multi-domain - it would be good to see all linkage <wires>, <references>
> - in one place. <reference> does not allow that to happen as it is
> always withing a <component> definition. <wire> does but then limited by
> single-domain.
>
> It would be good if <wire> (or some other similar) could do that too as
> - as a developer could just go to the <wire> section and see what has
> been setup - and not have to go through the <component> definitions.
> Hope its a valid statement as I have not done a large scale SCA impl
> yet. But already I feel I want to quickly see what is connected and
> deciphering <references> in each <component> section becomes tedious.
> But that's just me, so its a suggestion.
>
I think it's an interesting idea to extend the SCA definition of <wire>
to do as you are suggesting. To make it happen, someone would need to
propose it to the OASIS SCA Assembly Technical Committee for the members
of that committee to consider and decide.
Simon
> Great! Thanks again and look forward to contributing.
>
> monosij
>
>
> On Wed, May 4, 2011 at 5:19 AM, Simon Nash <nash@apache.org
> <ma...@apache.org>> wrote:
>
> Simon Laws wrote:
>
> On Wed, May 4, 2011 at 9:14 AM, Millies, Sebastian
> <Sebastian.Millies@ids-scheer.com
> <ma...@ids-scheer.com>> wrote:
>
> 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
>
>
>
>
> +1 from me. We should probably take a look at the wiki generally and
> try and remove the cruft that has built up there.
>
> Simon
>
> +1 for adding information like this to the wiki.
>
> Simon
>
>
Re: Summary: Basic configuration aspects in SCA
Posted by Monosij Dutta-Roy <mo...@gmail.com>.
hi Simon (Laws) -
You are welcome. I have learnt a lot in this process. Its a great framework.
And I would be happy to help with summarizing as concisely as possible into
a wiki. If you all indicate a thread that needs to be summarized I can move
it to a GoogleDoc or such to share it, refine it with you all and then post
to the wiki. Of course the GoogleDoc can still be linked with examples and
such.
I plan to work with SDO / DAS so can help there as well. Maybe we can try
and move towards some Pitfalls / Best Practices with
key inter-operable frameworks such as DAS / JDBC / REST / EJB and such. I
will try and keep it as simple and concise as possible.
You all have a lot of topics in your book to begin with - and maybe some
elements could be summarized, re-referenced and referred back to the book
pages for reference?
I can try to address the variability issues that SCA addresses - staring
with Languages (CPP, Java,...) and move into the other
dimensions. Hopefully will start to use the right terminologies.
----------
hi Simon (Nash) -
Thanks for the updates and clarifications and your help through this. Now
based on your comments below - have a few more to add.
1. I understand the distinction between service and object and will try to
refer to it accordingly from now.
2. Regarding returning as a POJO (ArrayList) vs encapsulated in object as
QueryResponse (which has the ArrayList) - you say is fine. Good - but when
moving to ws.binding and using JAXB datatypes - will that still work?
Meaning if I return JAXB datatypes encapsulated in QueryResponse - will that
work or would I have to return PO JAXB O? Maybe should come with an acronym
here - POXO? Plain Old XML Objects? :-)
3. Reference vs Wire - Thanks for the explanation. Just wanted to mention
that I like the aspect of <wire> being outside the <component> definition.
Reason, to me, is - as an app gets more complex and assuming multi-domain -
it would be good to see all linkage <wires>, <references> - in one place.
<reference> does not allow that to happen as it is always withing a
<component> definition. <wire> does but then limited by single-domain.
It would be good if <wire> (or some other similar) could do that too as - as
a developer could just go to the <wire> section and see what has been setup
- and not have to go through the <component> definitions. Hope its a valid
statement as I have not done a large scale SCA impl yet. But already I feel
I want to quickly see what is connected and deciphering <references> in each
<component> section becomes tedious. But that's just me, so its a
suggestion.
Great! Thanks again and look forward to contributing.
monosij
On Wed, May 4, 2011 at 5:19 AM, Simon Nash <na...@apache.org> wrote:
> Simon Laws wrote:
>
>> On Wed, May 4, 2011 at 9:14 AM, Millies, Sebastian
>> <Se...@ids-scheer.com> wrote:
>>
>>> 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
>>>
>>>
>>>
>>>
>> +1 from me. We should probably take a look at the wiki generally and
>> try and remove the cruft that has built up there.
>>
>> Simon
>>
>> +1 for adding information like this to the wiki.
>
> Simon
>
>
Re: Summary: Basic configuration aspects in SCA
Posted by Simon Nash <na...@apache.org>.
Simon Laws wrote:
> On Wed, May 4, 2011 at 9:14 AM, Millies, Sebastian
> <Se...@ids-scheer.com> wrote:
>> 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
>>
>>
>>
>
> +1 from me. We should probably take a look at the wiki generally and
> try and remove the cruft that has built up there.
>
> Simon
>
+1 for adding information like this to the wiki.
Simon
Re: Summary: Basic configuration aspects in SCA
Posted by Simon Laws <si...@googlemail.com>.
On Wed, May 4, 2011 at 9:14 AM, Millies, Sebastian
<Se...@ids-scheer.com> wrote:
> 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
>
>
>
+1 from me. We should probably take a look at the wiki generally and
try and remove the cruft that has built up there.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
RE: Summary: Basic configuration aspects in SCA
Posted by "Millies, Sebastian" <Se...@ids-scheer.com>.
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.forums@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.