Hi guys,
Special attention for Jim toward the end of this.
There have been some branches in this email thread.
Apologies if I don't inject at the right point in the chain, but
much of the discussion is not related to the point I want to
make. I need to react to something that's been discussed
along the way.
The notion that a property somehow represents a contract
between the implementation and the container is quite a
stretch IMHO. The real purpose of a property is to
configure a business service so that the component
behaves as the business would expect. I can see your
perspective when viewed from the aspect of someone
developing the runtime. It is certainly true that the container
has responsibility for creating properties, BUT it has the exact
same responsibility for injecting business services onto
references. So, the argument you're making for using properties
to hold references to system services holds on water.
However, I do have sympathy with the idea that there are
built-in services which SCA business component
implementations can use. These built-in services live in
a kind of "no man's land" right now. On one hand
we have properties (which are defined by the both the
Java spec spec and the assembly spec as described by XML
schema) that are used to provide parameterization of business
logic and we have business services that are assembled into
compositions of SOA services. I agree with Jim that we
should maintain a clear separation of purpose between
property and reference. After thinking on this for a while,
I've decided that the spec has correctly defined the property
concept, therefore the use of property to hold references
to "system services" is inappropriate and actually
violates the spec. This comes across more harshly than
I am intending. Jim, I think you need to raise this issue
in the spec group, if you really think that properties
should have the semantics you want. Despite the
current lack of compliance language in the specs, I think
it's still very clear where the boundaries of properties are.
Dave Booz
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, October 03, 2006 8:26 PM
Subject: Re: Modeling persistence services, was Re: EJB3 (JPA) support
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
