I'm not convinced that DAS really requires it but I'll let them be the judge of
that. Just from what I remembered I didn't see the need so I questioned it. I
just think when possible it best to integrate at the highest level of the stack
that suits your needs.
Jim, you lost me and peeked my interest at the same time on the following could
you elaborate a little more:
> Not all extensions need to implement Tuscany SPIs. A Tuscany extension
> could have no dependencies on an Tuscany or SCA API or annotation; it
> could be just a simple POJO. When it needs to access specific runtime
> capabilities, it may need to use injection or lower level APIs.
Jim Marino wrote:
On Nov 9, 2006, at 11:34 AM, cr22rc wrote:
My understanding is you would need to implement classes from
tuscany-spi to implement your container. This is surely specific to
Tuscany. The work that was started by Luciano was as I understood it
a Pojo that was an SCA component. That should be able to work in any
other SCA implementation.
There may be a really good reason you need to go the container route
and I just possibly missed it.
Both conceptually and practically, I think we are modeling a component
implementation type. Conceptually, the implementation language is a
query language (e.g. SQL). Practically, we are likely going to want to
to do things that are most appropriately done by an extensions. For
example, at some point I imagine DAS will need to be integrated with the
DataSource and transactional infrastructure provided by the runtime.
One thing that has come up that may also have impact on this
configuration information. Other O/R engines like Hibernate and OpenJPA
have a model where there is a factory (in Hibernate it is the
SessionFactory) that is fairly heavyweight and is responsible for
processing configuration (i.e. mapping) information, hooking into the
runtime transactional mechanisms, etc. This factory is generally
thread-safe and is shared on a per-Application basis. There are
individual Sessions (or EntitManagers) which encapsulate a specific unit
of work, are therefore lightweight, and are not thread-safe. They are
used to maintain object-identity and changes and are provided by the
factory. I don't know much about how DAS works but if it is similar,
then a container extension would be the way to go to accommodate this:
there would be some sort of shared DAS object that was instantiated
once-per application composite and contained all of the configuration.
Kevin or Luciano, is there something analogous to what I outlined in DAS?
Spring 1.0 took the approach that its container was primarily extended
through additional beans, much like the "DAS as a POJO approach" The
problem with this was the configuration began to introduce
implementation details. For example to expose a Spring bean as a remote
service, I had to configure the bean then create another bean whose
implementation type was a Java class provided by the Spring container.
This had the effect of coupling the application configuration to the
internal implementation of the Spring container as well as making the
XML syntax less strongly typed. In 2.0 Spring fixed this by providing
extensible namespace handling where people could extend the container by
implementing a custom XML parser for this configuration information,
thereby providing a way to eliminate the need for the extra bean and
referencing an implementation class. Basically, I view this as analogous
to our extension SPI.
And that's all I'm asking for is why.
My overall concern is if every technology comes along needs to
implement tuscany-spis and can't achieve it through creating reusable
SCA components that can be configured through properties.
l APIs.Not all extensions need to implement Tuscany SPIs. A Tuscany extension
could have no dependencies on an Tuscany or SCA API or annotation; it
could be just a simple POJO. When it needs to access specific runtime
capabilities, it may need to use injection or lower leve
I'm not sure if I did a good job explaining this...
Jim
Kevin Williams 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]
---------------------------------------------------------------------
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]
