I think the best possible solution would be what we have discussed as "Declarative DAS", where we would extend the programming model to expose services that interact with a persistent layer in a declarative fashion hiding the implementation details from the service developer, you can see some discussion around this available on the thread below :
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09978.html Yes, it's long and I'm supposed to summarize this over the Wiki, but haven't done that yet.... Going back to your question, we are trying to execute this idea incrementally, also giving different options of integration with SCA, and we have been doing this with the following contributions : - Expose DAS as an SCA service on the application layer (tuscany-898) - Create a DAS Container (tuscany-904) - Declarative DAS (coming) Altough, I wouldn't know how to answer your question regarding being able to use this in another SCA implementation, I'd say at least you would have DAS dependencies, and today that is Tuscany specific, if your question is more towards SCA container SPI, I'd leave the question to someone from SCA side, as I don't have a answer for you... - Luciano On 11/9/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
I absolutely want the best possible solution to integration and this discussion is helping quit a bit. I may misunderstand but, if we develop implementation.das and an associated container, wont this be usable in another SCA implementation? -- Kevin Rick wrote: > I quickly skimmed the threads on this and I didn't pick up what the > advantage was it making this a "container". The only thing I seen was > a tighter integration between DAS and SCA. But as I understand it me > this is really a tighter integration between DAS and Tuscany > implementation of SCA. In general I think we should be promoting > building services on SCA not Tuscany. When new bindings/containers > extension are proposed for Tuscany we should first consider why SCA/ > binding/components were inadequate and see if there is something the > SCA architecture can improve that would have made it possible. > The major down side I can see to the container approach is that it > can't be reused in another SCA implementation. > > Jim Marino wrote: > >> Hi Luciano, >> >> Is the DAS container a component or binding? If it is in the former, >> I would think it should go under container/container.das, otherwise >> binding/binding/das/ >> >> Also, the dependency in the module should be against a version of DAS >> and not the DAS project directly so that it is treated as an external >> dependency like Axis or OpenEJB. >> >> Jim >> >> On Nov 8, 2006, at 5:08 PM, Luciano Resende wrote: >> >>> Hi Guys >>> >>> Amita have started work to expose DAS as an SCA container, and we are >>> looking what would be the best way to get collaboration on >>> continuing the >>> task. One of the ways we were thinking was to clean-up what is >>> available >>> today and get it into the trunk, so we could share and continue >>> contributing >>> by submitting patches. Is that the way to go ? Any other ideas ? If >>> that's >>> the case, would the right place to have the container be around : >>> /java/sca/containers ? and then we would have a client available in >>> das/samples/das.container.client ? >>> >>> Toughts ? >>> >>> - Luciano Resende >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
