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