On Oct 3, 2006, at 1:05 PM, Jeremy Boynes wrote:
I see wires in the assembly as representing the interaction between
application components. Properties on the other hand represent a
contract between the application component and the container (by
which I mean the container is responsible for configuring an
instance of the application component with the value of that
property).
One way to represent an EntityManager would be to add a component
to the system that exposed that as a service. You could then wire
components to it as normal.
That does seem a little odd to me in that you would probably need a
custom implementation type for such a component that allowed you to
specify the EntityManagerFactory configuration. It also seems odd
to be using EntityManager as a service interface (valid, but odd).
Less odd to me is the idea of things (like EntityManager) that are
services provided by the runtime environment where a component is
running. They are part of a contract between an implementation and
its environment rather than between an implementation and another
component. We have that concept already in the form of Property
(contract with the environment to instantiate a value) so extending
that concept to more complex things would seem natural.
This would allow me to change the implementation type for the
component without changing the business level services that it
connects to. I can swap the implementation from one that uses JPA
to one that uses JDO or JDBC or XML or C++ with ODBC without
removing/adding other components to my assembly.
Being of the "cake and eating it camp" I think we should do both:
* provide <implementation.jpa> that can be used to define a
component with an EntityManager service interface
* support properties with a type of "EntityManager" that can be
injected to a component
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).
Using lower-level technologies such as JPA, JDBC, etc. to me are
really about solving different use cases. For example, the
EntityManager API does not represent an "application service
contract"; it is a low-level technology one (I don't like the term
"business service contract" but it can be used instead of
"application service contract"). This could apply to a host of things
as mentioned below by Jeremy, including WorkManagers, JDO, etc. I
view this as analogous to newing up java.io.File in an
implementation: importing java.io.File is part of the
implementation's contract with the container (JVM, the SCA runtime
making java.io available) but it is not a "service" in the sense of
"PriceEngine". In our case, instead of newing up EntityManager, we
are using an annotation so that the container may choose an instance
to inject.
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.
Jim
The same would go for other similar things such as SDO Helpers, JDO
PersistenceManagers, ...
--
Jeremy
On Oct 3, 2006, at 9:29 AM, scabooz wrote:
Hmmmm...a service modeled as a property is
what seems odd. I'm trying to keep an open mind.
Imagine drawing a picture of this using the icons from
the SCA spec. You'd have some kind of a connection
from a component's property to a database? That's
what doesn't make sense. I need to think more on this,
and maybe I'll change my mind. Didn't want to let this
thread just die.
Dave
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, October 03, 2006 11:40 AM
Subject: Re: EJB3 (JPA) support
On Oct 3, 2006, at 7:44 AM, scabooz wrote:
Hi Jim,
Somewhere buried in your explanation is the answer to
my question, but I can't find it, so I'll have to ask. I'm
trying to understand how you have modeled this WRT
the assembly model. It looks like you've added in a
SCDL extension, and are playing with the semantics
of a property. I would have expected such a formal
part of the application to have been modeled in a
formal way, such as with an SCA component.
It's a property (or "resource") just like a datasource or type
system helper (e.g. SDO) would be. Modeling it as a service on a
component seems kind of odd. There's a system service
responsible for providing a value for the property (just like
all property values in Tuscany) but that's an implementation
detail. Make sense?
Am I
understanding this correctly? I'm asking from a spec
perspective, trying to make sure that we're clean.
Dave
<snip>
---------------------------------------------------------------------
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]
