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 <[email protected]
<mailto:[email protected]>> wrote:
Simon Laws wrote:
On Wed, May 4, 2011 at 9:14 AM, Millies, Sebastian
<[email protected]
<mailto:[email protected]>> 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
