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>
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
2) to reference infrastructure services through inclusion in their
assembly
3) to access data through an application service with declarative
implementation by DAS
IMO users will want to do all of these and we should not do anything
to stop them.
<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.
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 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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
