On Oct 3, 2006, at 2:43 PM, Jeremy Boynes wrote:
On Oct 3, 2006, at 1:41 PM, Jim Marino wrote:
I like most types of cake too but I think we should really have
one way of doing this. I've vacillated in the past on whether
things such as DataSources, EntityManagers, etc. are modeled as
services in an *application* assembly or are contracts a
particular implementation may have with the container, i.e. a
property. I believe they are the second. My understanding of DAS
on the other hand is that it models data services which should be
represented as services in an application assembly. So, if someone
wants to model data access as a service then they should use DAS
(which could, as an implementation strategy, use JPA or DAS for
SQL data).
I think there's a big difference between something like
<implementation.jpa> and <implementation.das>
Agreed, that's what I said previously although I see I had a typo at
the end that may have confused things: DAS could use JPA or JDBC for
SQL data access.
I think <implementation.jpa> is about simplifying the configuration
of a complex component with a specific service interface (in this
case EntityManager). SCA assembly allows you to do this and
although it may seem odd, it is valid. We may suggest alternatives
but in the end providing the freedom for users to choose is
essential to our success.
DAS on the other hand is about declarative definition of data
access. Whereas in the <jpa> case the service contract is fixed,
DAS is about allowing the user to define data access in terms of a
service design pattern. The application developer defines the
service contract (as Java, WSDL, ...) with SCA supporting multiple
implementations of that contract. Someone may choose an
implementation based on JPA, JDO or some other programmatic
technology, or they can choose an implementation based on DAS's
declarative model.
This sounds like having cake, eating it, and also being able to
give it to a friend :-) We provide the flexibility for users:
1) to access infrastructure services through properties
Yes for things like JPA, JDBC, etc.
2) to reference infrastructure services through inclusion in their
assembly
If we do 1 I don't think we should do 2 (that doesn't stop someone
from extending Tuscany to do it though). See my comments below.
3) to access data through an application service with declarative
implementation by DAS
Yes, that's the value I see in DAS
IMO users will want to do all of these and we should not do
anything to stop them.
Allowing people to do it and facilitating it are two separate things.
We allow people to do it in that someone could come along an extend
the runtime in (almost) any way they please. I don't think we should
be facilitating it by doing it out of the box since having multiple
APIs/metadata for doing the same thing is generally not good
(although there are exceptions).
Also, in the spec group we have discussed use of Commons Annotations
@Resource for *property* injection, which includes things such as
DataSources. If we do this in the spec it would seem kind of funny to
implement the opposite. Another approach would be to entertain the
idea of eliminating the distinction between properties and references
altogether and just have "configuration sites" on components. I think
an argument can be made that a component implementation should only
care about a contract being fulfilled, not where it comes from.
<snip/>
The fact that Tuscany uses SCA "services" and assembly to
constitute the runtime is opaque to the application. Tuscany could
have chosen a different implementation strategy, for example using
PicoContainer, Spring, or Java "new", etc., but the application
does not need this knowledge. I believe it is important to
maintain this divide and that we do not cross namespaces. In
other words, it should not be possible to address a system service
*directly* from an application implementation.
I think this is a different issue. I agree that we do not want to
provide users with direct access to the services we use to create
the runtime, which I believe is what you mean by "cross
namespaces." However, we do not want to prevent users from defining
services in the application namespace that happen to use system- or
implementation-specific interfaces.
Of course, that's how @PersistenceContext would work. I believe
"crossing" namespaces (couldn't think of a better term) will become
something we will need to increasingly be aware of with autowire by
intent.
IOW, as a user I should be able to define a component with a
service of type "EntityManager" and provide my own Java
implementation for that component (for example using the
Persistence API directly). Someone else should also be able to
provide alternative implementation types for that (which is what
<implementation.jpa> is). This places all this function firmly in
the application space, maintaining separation from the runtime's
implementation.
I think what the user is doing there is configuring the runtime, not
configuring an application component. Specifically, they are
configuring a system service and that should be distinct from the
application. One of the specific things I don't like about frameworks
such as Spring and Dynamo (in general I really like them) is that
they conflate this.
I think the "property" style takes this even further, eliminating
the need for this kind of "infrastructure-esque" component to be
present /in application space./ It is providing a controlled way to
bridge from application space to runtime space, a way controlled by
the runtime itself.
Yes.
--
Jeremy
---------------------------------------------------------------------
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]
