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 <[email protected]> wrote:

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

Reply via email to