I would suggest that we start right away with a RDBDAS-based solution.
I also think that the best place to start would be with an interface
that is weakly typed. That is, a service interface in terms of
dynamic SDO's. If we go this route we can avoid the generation (by hand
or otherwise) of
-
From: Jim Marino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
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
services, was Re: EJB3 (JPA) support
H...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
checked in.
Ta
Meeraj
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 03 October 2006 21:05
To: tuscany-dev@ws.apache.org
Subject: Re: Modeling persistence services, was Re: EJB3
(JPA) support
I see wires in the assembly as representing the interaction
At 22:43 03/10/2006, Jeremy Boynes wrote:
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).
Great. I would like to help with this. I have been thinking for awhile
about how to best integrate the RDB DAS within SCA. For example, the
current BBank scenario uses the RDB DAS as a utility but it would be
nice if it could wire in a RDB DAS service or be injected with a
configured DAS.
H...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
For JPA/Hibernate support I like the idea of extending code gen such that
static SDOs could be anotated for persistence using JPA. From my
perspective this would do a better job of maintaining seperation of
application logic, serivces and the data model.
thoughts . . . ?
Robbie
On 10/3/06,
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
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
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
On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
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
On Oct 3, 2006, at 6:17 PM, Jeremy Boynes wrote:
On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
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
13 matches
Mail list logo
