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.
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.
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]
