You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2006/10/19 22:13:09 UTC
Declarative DAS, was Re: Modeling the RDB DAS in SCA, was Re: Modeling persistence services, was Re: EJB3 (JPA) support
Recently, people have been starting to talk about better DAS integration
with DAS, and below are some threads on the subject :
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08833.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08923.html
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09715.html
I'm new on the SCA side, so please help me make sure what I'm saying is not
yet available on SCA today.
Today, defining a service to work with a relational database, you will need
to code the persistence side of the service where CRUD operations to the
database will be done.
I was thinking on a simpler, easier way, where coding the CRUD operations on
the persistence layer would be avoided as much as possible.
The idea would be to have a more "declarative DAS" when defining SCA
Services, so you would either use some Annotations or SCDL to have the
"declarative DAS" configuration inside it.
I was thinking on something like....
SCDL Definition would look something like this :
<component name="AccountDataService">
<interface.java class="bigbank.account.services.account.AccountService"/>
<implementation.das="dasConfig.properties"
connection="java:comp/env/jdbc/bigbank"/>
</component>
The AccountService Interface would look like this (missing any SCA
annotations):
public interface AccountService {
public List getAllCustomers();
public Object getCustomerAccount(String accountNumber);
}
The DAS config would look like this, and would have the definition for the
"all companies" command.
<Config ...>
...
<ConnectionInfo dataSource="java:comp/env/jdbc/bigbank"/>
<Command name="getAllCustomers" SQL="select * from CUSTOMERS"
kind="Select"/>
<Command name="getCustomerAccount" SQL="SELECT accountNumber,
accountType, balance FROM accounts where accountNumber = ?" kind="Select" />
...
</Config>
Mapping between interface methods and DAS Commands
- If a DAS config file is provided, based on the SCDL definition, we
would look for "DAS command" based on the name of the getter
(e.ggetAllCustomers would map to getAllCustomers command)
- Otherwise, we would try to do a map directly to a stored procedure
- We could also have a way to force the mapping by using annotation
(e.g@Procedure on the method level)
Mapping between method parameter and command parameter
- We would need to define a method for mapping the method parameters to
the query paramters either based on position (e.g first method parameter
maps to the first command paramter), or we would do some mapping by name
(currently not available in Tuscany DAS)
Note:
- A SCDL connection information would override the DAS Config file
connection information.
Benefits
- It's All about simplicity and easy of use
- This would allow a user to define a service without having to
explicitly having to code any Data Access related code.
Implementation approaches
- Utilizing DAS : This approach would start from the current Tuscany DAS
implementation, where functionality would be already available, but the
service implementation would be tied to SDO and RDB as this is what DAS
supports today.
- Start simple and grow : We could start simple, by having a simple
implementation based on JDBC and would return some simple collection as a
return type (e.g List or a even a Recordset), this could give us a quick
start to flush implementation details and get a proven design, and this
could get evolved to use a DAS that would support multiple backends
(e.gRDB, XML, etc) and would create SDO as well as non-SDO types as a
command
result.
Toughts ?
- Luciano
On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
>
> 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. Another thing we want to eventually explore is exposing
> a DAS as REST-oriented services. As we have seen from the parent thread
> there are almost too many possible approaches.
>
> My first thought is to model the DAS as a service and create a new
> implementation kind (implementation.rdbdas). The main reason has to do
> with the potential declarative aspect of DAS that Jeremy mentioned which
> is all about creating data access services declaratively. A new
> component type and a service that we build by hand would be a good step
> in this direction.
>
> We might want to expose a DAS service with an interface like this:
>
> public interface RDBDASService
> void applyChanges(DataObject graphRoot);
> DataObject execute(String commandName);
> DataObject executeSQL(String abitrarySQL);
> }
>
> The service would be initialized with an optional RDB DAS config file
> that defines connection properties, a set of commands, etc. So,
> different services implementing the same interface could be initialized
> from separate config files.
>
> Eventually, we might want to build services like this:
>
> public interface Customers_RDBDASService
> void applyChanges(DataObject graphRoot);
> DataObject getAllCustomersWithLastName (String lastName);
> DataObject getAll CustomersAndOrdersForID (int customerId);
> }
>
> But, for this to be very useful would probably require some code
> generation tooling.
>
> Thoughts?
>
> --Kevin
>
>
> Luciano Resende wrote:
>
> > I'm starting to look in ways we could have a declarative DAS and will be
> > posting my progress into the list / wiki soon...
> >
> > - Luciano
> >
> > On 10/3/06, Jeremy Boynes <jb...@apache.org> 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 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.
> >>
> >> "Thanks for volunteering" :-)
> >> If someone wants to contribute these, I think we should welcome it
> >> like we would any other contribution.
> >>
> >> >> 3) to access data through an application service with declarative
> >> >> implementation by DAS
> >> > Yes, that's the value I see in DAS
> >>
> >> I think this is already on the DAS folks radar.
> >> --
> >> Jeremy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Luciano Resende <lu...@gmail.com>.
+1 I'll be available on IRC for chatting...
On 11/8/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Hi Amita,
> This sounds good. Thanks for getting up so early!
> --
> Kevin
>
>
> Amita Vadhavkar wrote:
>
> > Hello Kevin , Luciano,
> > Thanks a lot for all your suggestions and looking forward to have a
> > IRC chat
> > with you.
> > I am proposing 9th Nov 5.30 a.m. IST (8th Nov 4.00 p.m. PST) for
> > approx. 1
> > hr.
> > Please join the chat and we all can discuss -
> > 1) what we are trying to provide - service, container
> > 2) what all features can be provided
> > 3) any high level design suggestions ( sim. to Kevin's latest reply )
> > 4) any other suggestions
> > 5) we can try to come up with a list of work items
> > This will be very helpful in getting a clear picture of what all can
> > be done
> >
> > in SCA (as well as DAS) domain for our current work.
> >
> > Regards,
> > Amita
> >
> > On 11/8/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >>
> >> Hello Amita,
> >>
> >> This looks promising. I notice your test case uses explicit updates
> and
> >> inserts. While this is supported by the DAS it is not the preferred
> >> usage which is to allow the RDB DAS to generate the CUD statements from
> >> the SDO change history. Could you modify the example to read a data
> >> graph and then post the changes back via "applyChanges"? Maybe the
> >> equivalent of this simple test from the DAS test suite:
> >>
> >> public void testReadModifyApply4() throws Exception {
> >>
> >> DAS das = DAS.FACTORY.createDAS(getConfig("CustomerConfig.xml"),
> >> getConnection());
> >> // Read customer with particular ID
> >> Command select = das.getCommand("getCustomer");
> >> select.setParameter(1, 1);
> >> DataObject root = select.executeQuery();
> >>
> >> DataObject customer = (DataObject) root.get("CUSTOMER[1]");
> >>
> >> // Modify customer
> >> customer.set("LASTNAME", "Pavick");
> >>
> >> das.applyChanges(root);
> >>
> >> // Verify the change
> >> root = select.executeQuery();
> >> assertEquals("Pavick",
> >> root.getDataObject("CUSTOMER[1]").getString("LASTNAME"));
> >>
> >> }
> >>
> >> Also, this service interface seems difficult to work with since command
> >> identifiers and argument values are encoded in the params Vector
> >>
> >> public interface CustomersOrdersService {
> >>
> >> void execute(Vector params);
> >> DataObject executeQuery(Vector params);
> >> void applyChanges(Vector params);
> >> DataObject executeAdhoc(Vector params);//adhoc query
> >> implementation
> >>
> >> DataObject getAllCustomers(Vector paramsList);
> >>
> >> }
> >>
> >> Do you think it possible to implement something like the following
> >> interface:
> >>
> >> public interface DynamicRDBDASService {
> >>
> >> DataObject execute(String commandName, List params);
> >> DataObject executeAdHoc(String queryString, List params);
> >> void applyChanges();
> >> }
> >>
> >> The name is kind of long (suggestions welcome) but, I think this
> >> interface could be generic and set of available commands is driven by
> >> the provided DAS config file. I am not sure how we might support SP
> OUT
> >> parameters but we can think about that later.
> >>
> >> I does seem like you and Luciano should team up on this.
> >>
> >> Thanks!
> >> --
> >> Kevin
> >>
> >>
> >>
> >>
> >> Amita Vadhavkar wrote:
> >>
> >> > Hi Kevin,
> >> > Thanks a lot for the comments. I have posted the code and doc on
> >> JIRA-904
> >> > for the container work. Also, am most likely missing something in the
> >> > database
> >> > connection portion. Would like to discuss with you.
> >> >
> >> > Will you please provide feedback on JIRA-904 attachments?
> >> >
> >> > I am checking with Luciano for a convenient date/time when we can
> >> chat,
> >> > would
> >> > be great if you can also join. I am in IST timezone.
> >> >
> >> > Regards,
> >> > Amita
> >> >
> >> > On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >
> >> >>
> >> >> Hi Amita,
> >> >> This is looking good. Some comments inline:
> >> >>
> >> >> Amita Vadhavkar wrote:
> >> >>
> >> >> > Hi,
> >> >> > I am trying to create a container for DAS-SCA too (not just for
> >> stored
> >> >> > procedure) and will be able to send a working code in ML over the
> >> >> > weekend.
> >> >> >
> >> >> > Below is summary of what I got so far from the previous mail
> >> >> > discussions and
> >> >> > some questions.
> >> >> >
> >> >> >
> >> >> > The integration between DAS and SCA can happen at application
> level
> >> as
> >> >> > service or at container level.
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2 different possible approaches –
> >> >> >
> >> >> > static – e.g. getAllCustomers
> >> >> >
> >> >> > dynamic – e.g. execute("all customers");
> >> >> >
> >> >> >
> >> >> >
> >> >> > For application level service – it is the sample *
> >> >> > sample-StoredProcedureService.jar* or what Luciano is providing
> in
> >> >> more
> >> >> > details, is an example. In *sample-StoredProcedureService.jar*
> >> >> example
> >> >> > dynamic approach is followed
> >> >> >
> >> >> >
> >> >> >
> >> >> > For container approach – again static or dynamic approach can be
> >> >> > followed.
> >> >> > For static – it's like providing service for getAllCompanies(),
> >> >> > getAllCustomers() etc. whereas for dynamic its like
> >> execute(command)
> >> >> > where
> >> >> > command can be "getAllCompanies", "getAllCustomers". Etc.
> >> >> >
> >> >> >
> >> >> >
> >> >> > I am working on a container implementation where
> dynamic
> >> >> > approach is followed.
> >> >> >
> >> >> If I understand correctly, the container approach will provide the
> >> >> tightest integration with SCA and make things easier for
> >> end-users. Do
> >> >> you agree?
> >> >>
> >> >> >
> >> >> >
> >> >> > There are 2 places where extensibility is required –
> >> >> >
> >> >> > 1) for providing different data access mechanisms. i.e. today
> >> >> > there is
> >> >> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
> >> >> > scdl will
> >> >> > be same, but the exampleconfig.xml will change.
> >> >> >
> >> >> > In the container I am working on - Scdl has a new tag
> >> >> >
> >> >> > Scdl has a new tag
> >> >> > <da:implementation.dascript="customersOrders/CustomersOrders.xml"
> >> >> > dataAccessType="rdb"/>
> >> >> >
> >> >> >
> >> >> >
> >> >> > Here, dataAccessType – is the key which tells whether it's RDB or
> >> >> > something
> >> >> > else. And the xml script provides the connection and data store
> >> >> details.
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2) for RDB-DAS – providing support for different databases
> >> (this
> >> >> > portion should be part of DAS and not SCA.) In the current
> >> container
> >> >> > I am
> >> >> > working on it is provided as a package -
> >> >> > org.apache.tuscany.container.dataaccessshelper package - which
> >> should
> >> >> > finally go into DAS codeline(?).
> >> >> >
> >> >> >
> >> >> Currently, there are two ways to specify a particular database:
> >> first,
> >> >> the user can pass a JDBC Connection to the DAS Factory when
> >> creating a
> >> >> DAS instance. The second is that a DataSource can be specified in
> >> the
> >> >> DAS Config xml file in which case the DAS is responsible for getting
> >> the
> >> >> connection.
> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > For static approach we may need some code generation tooling.
> >> >>
> >> >> Right. That is why I think it best to start with dynamic. But, we
> >> will
> >> >> want static support as well.
> >> >>
> >> >> > Also could not
> >> >> > understand how this can be merged into RESTful interfaces. (this
> >> was
> >> >> > mentioned in some mail conversation)
> >> >> >
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Amita
> >> >> >
> >> >> >
> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >
> >> >> >>
> >> >> >> Luciano Resende wrote:
> >> >> >>
> >> >> >> > Comments in-line...
> >> >> >> >
> >> >> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> >> >> >> >>
> >> >> >> >> > Hi,
> >> >> >> >> >
> >> >> >> >> > I would also like to understand this a little better ...
> here
> >> >> I am
> >> >> >> >> > thinking
> >> >> >> >> > aloud and hope the others will help in getting my
> >> persceptions
> >> >> >> >> > right...
> >> >> >> >> >
> >> >> >> >> > I guess firstly it is a question of how or where we want to
> >> >> >> >> > position 'DAS
> >> >> >> >> > Integration' in SCA. Is is something we want to integrate
> as
> >> >> the
> >> >> >> >> > Application Layer, which I understand is what Amita is
> trying
> >> >> >> >> > presently and
> >> >> >> >> > which Jim refers to as component implementation. In this
> >> >> option
> >> >> >> >> > we get to
> >> >> >> >> > do some sort of a service wrapper to DAS and then it
> >> becomes a
> >> >> >> >> > demonstration
> >> >> >> >> > of two Tuscany subprojects integrating at application level.
> >> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Yes, I think we have space to position DAS both ways, and
> >> >> integrating
> >> >> >> > in the
> >> >> >> > application layer by exposing DAS as a service would be a very
> >> easy
> >> >> >> and
> >> >> >> > quick, this could be exposed as a sample app, and could show we
> >> are
> >> >> >> > working
> >> >> >> > on getting a better integration between DAS and SCA
> >> >> >> >
> >> >> >> >
> >> >> >> >> Or do we want to position DAS at the infrastructure layer as
> >> >> another
> >> >> >> >> > extension type (either container or binding). I guess
> >> this is
> >> >> >> >> > where Ant
> >> >> >> >> > started this - proposing a JDBC container / binding for
> >> >> component
> >> >> >> >> > implementation in StoredProcedures.
> >> >> >> >> I was thinking a DAS was a way to declaratively model
> >> >> heterogeneous
> >> >> >> >> data as a service and offer a mechanism for remoting that
> data.
> >> In
> >> >> >> >> other words, it provided the ability for an application to
> >> perform
> >> >> >> >> CRUD using a high-level contract (interface) and having those
> >> >> >> >> operations take place across a service network. How this is
> >> >> hooked
> >> >> >> >> into the SCA container is probably best done as an extension
> >> type,
> >> >> >> >> i.e. someone could specify:
> >> >> >> >>
> >> >> >> >> <component name="Foo">
> >> >> >> >> <implementation.das>
> >> >> >> >> <interface.java ....>
> >> >> >> >> </implementation.das>
> >> >> >> >> </component>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Yes, this goes back to the way I was thinking on my original
> >> >> proposal.
> >> >> >> >
> >> >> >> >
> >> >> >> >> If this is the path we should take
> >> >> >> >> > then we probably have to think beyond DAS - to something
> more
> >> >> >> >> > general - of
> >> >> >> >> > which DAS is just a special case. I suppose this is what
> Jim
> >> >> has
> >> >> >> also
> >> >> >> >> > suggested in trying to explore other persistence mechanisms.
> >> >> >> >> >
> >> >> >> >> This may be the crux of the confusion. I was thinking DAS
> >> >> provides a
> >> >> >> >> general mechanism for accessing heterogeneous data and is only
> >> >> right
> >> >> >> >> now tied to SQL because of resource constraints (i.e. we
> >> have to
> >> >> >> >> start somewhere). Ultimately, DAS should provide the
> >> >> infrastructure
> >> >> >> >> for dealing with multiple, varied data stores and mechanisms
> >> for
> >> >> >> >> querying across them. In other words, I guess I am saying DAS
> >> >> should
> >> >> >> >> be the general solution (declarative and heterogeneous) since
> >> >> if it
> >> >> >> >> is only a programmatic way to access relational data then its
> >> >> value
> >> >> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Yes, the current status of DAS implementation is RDB only. I
> >> would
> >> >> say
> >> >> >> > that,
> >> >> >> > in the future, I'd like to see a heterogeneous DAS that would
> >> give
> >> >> you
> >> >> >> > access to different data stores, and probably support non-SDO
> >> types
> >> >> as
> >> >> >> > well.
> >> >> >> >
> >> >> >> >> I too feel that this is something that must be done as an
> >> >> extension
> >> >> >> >> > type -
> >> >> >> >> > but yet to get my hands on the general scheme of things that
> >> DAS
> >> >> >> >> > can slip
> >> >> >> >> > into. Infact the other thread where Jeremy has taken
> >> forward a
> >> >> >> >> > proposal to
> >> >> >> >> > the specs group on resources tempts me to think that there
> is
> >> >> going
> >> >> >> >> > to be
> >> >> >> >> > something in that which we can leverage from.
> >> >> >> >> >
> >> >> >> >> I think resources are orthogonal as they are about a component
> >> >> >> >> implementation's contract with its container. Declarative data
> >> >> >> >> services on the other hand are about application constructs
> >> >> that can
> >> >> >> >> be wired to.
> >> >> >> >>
> >> >> >> >> > I hope to get a better understanding this as we go along in
> >> this
> >> >> >> >> > thread :)
> >> >> >> >> >
> >> >> >> >> Me too :-) As soon as I have trouble explaining technologies
> to
> >> >> .NET
> >> >> >> >> people and they say "you Unix/Java people are at it again
> >> with a
> >> >> >> >> thousand ways to do the same exact thing" it causes me to
> think
> >> >> that
> >> >> >> >> maybe we need to clarify our message.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > If we all think it would be useful, I could try to summarize
> the
> >> >> >> > thread on
> >> >> >> > the wiki with a more clean proposal incorporating all your
> >> >> feedback ,
> >> >> >> > what
> >> >> >> > you guys think ?
> >> >> >>
> >> >> >> Yes. Great idea.
> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > Jim
> >> >> >> >
> >> >> >> >> > Thanks
> >> >> >> >> >
> >> >> >> >> > - Venkat
> >> >> >> >> >
> >> >> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >> >>
> >> >> >> >> >> Jim Marino wrote:
> >> >> >> >> >>
> >> >> >> >> >> > When I first read the thread on this, I thought the DAS
> >> >> service
> >> >> >> >> >> would
> >> >> >> >> >> > be a component extension type (e.g. analogous to a
> >> >> >> >> >> > implementation.java or implementation.ejb) and not a
> >> >> component
> >> >> >> >> >> > implementation type, which would allow for dynamic and
> >> >> >> eventually
> >> >> >> >> >> > declarative configuration styles.
> >> >> >> >> >>
> >> >> >> >> >> I have not very familiar with the terminology so I am not
> >> sure
> >> >> >> what
> >> >> >> a
> >> >> >> >> >> "component extension type" is. But, I do think we
> >> eventually
> >> >> want
> >> >> >> >> >> "implementation.rdbdas". Wouldn't this be a new
> >> implementation
> >> >> >> type?
> >> >> >> >> >>
> >> >> >> >> >> It looks like Amita chose to start with a POJO. I notice
> >> >> the use
> >> >> >> >> >> of "
> >> >> >> >> >> implementation.java".
> >> >> >> >> >>
> >> >> >> >> >> > Either way, though, I am curious as to why
> >> >> >> >> >> >
> >> >> >> >> >> > public DAS configureService(String configFile);
> >> >> >> >> >> >
> >> >> >> >> >> > exists as part of the service definition? If the DAS
> >> service
> >> >> >> was a
> >> >> >> >> >> > component extension type, it could be handled as part
> >> of the
> >> >> >> >> >> > application bootstrap. If the DAS service was a component
> >> >> >> >> >> > implementation type, the configuration file URI could be
> >> >> passed
> >> >> >> >> >> in as
> >> >> >> >> >> > a property and then processed in an initializer method
> >> >> decorated
> >> >> >> by
> >> >> >> >> >> > the SCA @Init annotation. In the latter case, if the
> >> >> >> implementation
> >> >> >> >> >> > of DASService thread-safe (hopefully it is since
> >> >> configuration
> >> >> >> >> >> would
> >> >> >> >> >> > seem to be a heavyweight operation), then I would make
> the
> >> >> >> >> >> component
> >> >> >> >> >> > module scoped to avoid initialization overhead on every
> >> >> >> resolution.
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > In both approaches (extension vs. implementation type),
> >> >> having
> >> >> >> >> >> > configuration exposed to the application doesn't quite
> >> feel
> >> >> >> right,
> >> >> >> >> >> > since that is what DI tries to externalize.
> >> >> >> >> >>
> >> >> >> >> >> I agree. The configuration should be part of the
> >> >> >> initialization and
> >> >> >> >> >> should use SCA patterns to do this. I think that Amita
> >> meant
> >> >> >> to use
> >> >> >> >> >> eventually use a component property for the DAS config info
> >> but
> >> >> >> >> >> started
> >> >> >> >> >> with a method.
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > Also, I was thinking that in having this a component
> >> >> extension
> >> >> >> >> >> type,
> >> >> >> >> >> > the service interfaces returned from a resolution could
> >> >> include
> >> >> >> the
> >> >> >> >> >> > dynamic one described below or static ones people have
> >> >> >> mentioned.
> >> >> >> I
> >> >> >> >> >> > guess it is best to start with the easier-to-implement
> >> part
> >> >> >> >> >> first and
> >> >> >> >> >> > support the dynamic interface.
> >> >> >> >> >> >
> >> >> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be
> >> >> nice to
> >> >> >> >> >> > understand what DAS provides in relation to other
> >> persistence
> >> >> >> >> >> > technologies. Outside of the Java world, Microsoft is
> >> >> promoting
> >> >> >> >> >> LINQ
> >> >> >> >> >> > which is really interesting, and it would be
> >> informative to
> >> >> >> compare
> >> >> >> >> >> > the goals of DAS with that approach (there are obvious
> >> >> >> differences
> >> >> >> >> >> > such as having the query language a strongly-typed part
> of
> >> >> the
> >> >> >> >> >> > programming language, e.g. C#, and LINQ's use of
> >> closures).
> >> >> >> >> >> >
> >> >> >> >> >> > In contrasting DAS to O-R technologies, I see the primary
> >> use
> >> >> >> cases
> >> >> >> >> >> > for the former being a quick way to issue a query that
> may
> >> be
> >> >> >> >> >> > executed against *heterogeneous* data stores and have
> that
> >> >> data
> >> >> >> >> >> flow
> >> >> >> >> >> > remotely or to a client that is not necessarily
> >> >> Java-based. One
> >> >> >> key
> >> >> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> >> >> >> >> (Hibernate
> >> >> >> >> >> > and JPA are about as easy):
> >> >> >> >> >> >
> >> >> >> >> >> IMO the primary use case for DAS is an application that is
> >> SDO-
> >> >> >> >> >> centric
> >> >> >> >> >> and is taking advantage of its disconnected
> >> capabilities. The
> >> >> RDB
> >> >> >> >> >> DAS
> >> >> >> >> >> is built to work with SDO and uses the change summary to
> >> drive
> >> >> >> >> >> changes
> >> >> >> >> >> made to a disconnected data graph back to some store.
> >> This is
> >> >> not
> >> >> >> to
> >> >> >> >> >> say that a relational DAS could not be built on top of
> >> JPA, in
> >> >> >> fact,
> >> >> >> >> >> this might be a very useful thing to do. The
> implementation
> >> we
> >> >> >> >> >> currently have provides a very straightforward implicit
> >> mapping
> >> >> >> from
> >> >> >> >> >> DataObjects to Tables. If more capable mapping is needed
> >> >> then it
> >> >> >> >> >> makes
> >> >> >> >> >> sense to use the JPA-defined technology and artifacts. A
> >> >> modified
> >> >> >> >> >> Entity manager might be needed to take advantage of SDO's
> >> >> change
> >> >> >> >> >> summary.
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > public interface CustomerDao extends BaseQuery {
> >> >> >> >> >> > @Select("select * from customers where city = ?1")
> >> >> >> >> >> > DataSet<Customer> findCustomersFrom(String city);
> >> >> >> >> >> > }
> >> >> >> >> >> >
> >> >> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> >> >> >> >> > (CustomerDao.class, datasource);
> >> >> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > The other key is remote data and change lists. I think
> >> there
> >> >> >> are
> >> >> >> >> >> > (literally) about a thousand ways that already exist to
> >> >> >> handle the
> >> >> >> >> >> > "local" data case. For change lists, interop with
> >> ADO.NET's
> >> >> >> change
> >> >> >> >> >> > summary facilities would be interesting.
> >> >> >> >> >>
> >> >> >> >> >> I agree. Also, it looks like Xcalia may have a similar
> >> >> thought:
> >> >> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think
> >> >> it is
> >> >> >> >> >> > important we have a clear statement as to when it is
> >> >> appropriate
> >> >> >> >> >> and
> >> >> >> >> >> > not appropriate to use. One place to start would be to
> >> >> compare
> >> >> >> >> >> it to
> >> >> >> >> >> > JDBC 4 and JPA.
> >> >> >> >> >>
> >> >> >> >> >> We can get started with JPA:
> >> >> >> >> >>
> >> >> >> >> >> * JPA is java-specific, container-based, built around a
> >> >> >> connected
> >> >> >> >> >> data model and offers a complete O/R mapping for
> POJOs
> >> >> >> >> >>
> >> >> >> >> >> * The RDB DAS is a java implementation of a language -
> >> >> neutral
> >> >> >> >> >> concept (hopefully specified some day) that is
> >> >> >> containerless,
> >> >> >> >> >> assumes a disconnected data model and provides a
> >> simple,
> >> >> >> >> >> implicit
> >> >> >> >> >> mapping for SDO DataObjects (Dynamic or Static) to
> >> >> >> relational
> >> >> >> >> >> tables.
> >> >> >> >> >>
> >> >> >> >> >> Anything else?
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > Jim
> >> >> >> >> >> >
> >> >> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >> >> >> >> >
> >> >> >> >> >> >> Hi Amita
> >> >> >> >> >> >>
> >> >> >> >> >> >> I think we were both going on the same way, with the DAS
> >> >> >> Service
> >> >> >> >> >> >> sample,
> >> >> >> >> >> >> altough i had the interface more like this, to be more
> >> >> >> flexible :
> >> >> >> >> >> >>
> >> >> >> >> >> >> public interface DASService {
> >> >> >> >> >> >>
> >> >> >> >> >> >> public DAS configureService(String configFile);
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >> public DataObject executeCommand(String commandName);
> >> >> >> >> >> >> public DataObject execute(String newCommand);
> >> >> >> >> >> >> public void applyChanges(DataObject graphRoot);
> >> >> >> >> >> >> }
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> As for having it as a sample, maybe we could defined the
> >> >> >> >> >> DASService
> >> >> >> >> >> >> as one
> >> >> >> >> >> >> sample itself, and have a second version of companyWeb
> >> that
> >> >> >> would
> >> >> >> >> >> >> consume
> >> >> >> >> >> >> the service, something like :
> >> >> >> >> >> >>
> >> >> >> >> >> >> das\samples\companyWeb
> >> >> >> >> >> >> das\samples\dasService
> >> >> >> >> >> >> das\samples.companyWeb.service
> >> >> >> >> >> >>
> >> >> >> >> >> >> or, more like BigBank
> >> >> >> >> >> >>
> >> >> >> >> >> >> das\samples\companyweb.Service\dasService
> >> >> >> >> >> >> das\samples\companyweb.Service\webClient
> >> >> >> >> >> >>
> >> >> >> >> >> >> Or even in sampleApps...
> >> >> >> >> >> >>
> >> >> >> >> >> >> Toughts ?
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
> >> >> wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> Hi ,
> >> >> >> >> >> >>> I am also following up another thread
> >> >> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> >> msg09944.html
> >> >> >> >> >> >>> on the
> >> >> >> >> >> >>> similar issue (JDBC stored procedure container
> >> >> >> >> >> >>> using DAS)
> >> >> >> >> >> >>> Besides the fact that I am actively working on the
> >> >> container
> >> >> >> >> >> work,
> >> >> >> >> >> >>> I also
> >> >> >> >> >> >>> have tried to
> >> >> >> >> >> >>> develop a sample based on the below discussion,
> >> following
> >> >> >> dynamic
> >> >> >> >> >> >>> approach.
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> I am attaching the same here. Please take a look and
> >> give
> >> >> your
> >> >> >> >> >> >>> suggestions.
> >> >> >> >> >> >>> In this, StoredProcedureService implementation has
> >> >> >> >> >> setConfigInfo (DAS
> >> >> >> >> >> >>> Config) and
> >> >> >> >> >> >>> execute(Any SQL). This can be made more complete with
> >> >> >> >> >> executeSQL(),
> >> >> >> >> >> >>> applyChanges()
> >> >> >> >> >> >>> etc.
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> Can this be added to the existing set of samples?
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> Regards,
> >> >> >> >> >> >>> Amita
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > Luciano Resende wrote:
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > Kevin, from what I understood from your
> >> suggestion, it
> >> >> was
> >> >> >> >> >> >>> looking to
> >> >> >> >> >> >>> > me
> >> >> >> >> >> >>> > > more like exposing DAS as a service :
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > >>> public interface RDBDASService
> >> >> >> >> >> >>> > >>> DataObject execute(String commandName);
> >> >> >> >> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
> >> >> >> >> >> >>> > >>> void applyChanges(DataObject graphRoot);
> >> >> >> >> >> >>> > >>> }
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > Yes, I am talking about exposing a DAS Service
> >> configured
> >> >> >> >> >> with a
> >> >> >> >> >> >>> > specific set of capabilities/commands defined in
> >> the DAS
> >> >> >> config
> >> >> >> >> >> >>> file.
> >> >> >> >> >> >>> > So, if the implementation of the service interface
> >> above
> >> >> was
> >> >> >> >> >> >>> configured
> >> >> >> >> >> >>> > to work with Customers they would use the service
> like
> >> >> this:
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > List customers = myRDBDASService.execute
> >> >> >> ("getAllCustomers");
> >> >> >> >> >> >>> > String name = customers.get(0).getString("name");
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > This is not much different than the static
> >> interface you
> >> >> >> >> >> proposed,
> >> >> >> >> >> >>> > right?
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > And then, when a service developer defines the
> >> >> >> >> >> AccountService,
> >> >> >> >> >> >>> he will
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > have
> >> >> >> >> >> >>> > > to know about yet another service, about how DAS
> >> works,
> >> >> >> >> >> how it is
> >> >> >> >> >> >>> > > configured, etc, etc... is that right ?
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > The abilities of the service are defined by the DAS
> >> >> config
> >> >> >> >> >> file.
> >> >> >> >> >> >>> So,
> >> >> >> >> >> >>> > the person or tool that provides the config file must
> >> >> >> >> >> understand
> >> >> >> >> >> >>> how the
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > RDB DAS APIs work. There is no getting around this.
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > My proposal was going more towards allowing the
> >> service
> >> >> >> >> >> >>> developer to
> >> >> >> >> >> >>> > > focus
> >> >> >> >> >> >>> > > on defining the service, and let the "declarative
> >> >> das" to
> >> >> >> >> >> >>> handle the
> >> >> >> >> >> >>> > > persistent layer....
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > The DAS config file is the declaration of an
> >> instance of
> >> >> the
> >> >> >> >> >> >>> DAS. That
> >> >> >> >> >> >>> > instance can be exposed as a dynamic or typed
> service/
> >> >> >> >> >> interface.
> >> >> >> >> >> >>> That
> >> >> >> >> >> >>> > seems to be the main discussion we are having.
> >> >> Although, I
> >> >> >> >> >> may be
> >> >> >> >> >> >>> > missing something.
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > Also, by defining some conventions over
> >> configuration
> >> >> >> >> >> and/or using
> >> >> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a
> >> >> stored
> >> >> >> >> >> >>> procedure),
> >> >> >> >> >> >>> > the
> >> >> >> >> >> >>> > > service developer could really define a service
> that
> >> >> >> >> >> interacts
> >> >> >> >> >> >>> with a
> >> >> >> >> >> >>> > > RDB,
> >> >> >> >> >> >>> > > without having to code the service persistence
> >> layer.
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > There is a lot of potential for the use of
> >> annotations.
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > > - Luciano
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net>
> >> >> wrote:
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> The real difference between the two approaches is
> >> that
> >> >> >> >> >> one is
> >> >> >> >> >> >>> "Typed"
> >> >> >> >> >> >>> > or
> >> >> >> >> >> >>> > >> static and the other is dynamic. I think both are
> >> >> needed
> >> >> >> >> >> but was
> >> >> >> >> >> >>> > >> suggesting that we start with dynamic since it
> >> is the
> >> >> >> most
> >> >> >> >> >> >>> flexible
> >> >> >> >> >> >>> > and
> >> >> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a
> >> >> static
> >> >> >> >> >> >>> capability.
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> With either, the user does not need to know about
> >> >> >> >> >> traditional
> >> >> >> >> >> >>> > >> persistence frameworks. With the dynamic
> approach,
> >> >> >> however,
> >> >> >> >> >> >>> the user
> >> >> >> >> >> >>> > >> does need to know about the dynamic SDO API.
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> So, with the static interface the user might
> write:
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> List customers =
> accountService.getAllCustomers
> >> ();
> >> >> >> >> >> >>> > >> String name =
> >> >> ((Customer)customers.get(0)).getName();
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> The equivalent dynamic API might be:
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> List customers =
> >> >> >> dasService.execute("getAllCustomers");
> >> >> >> >> >> >>> > >> String name =
> >> >> >> ((DataObject)customers.get(0)).getString
> >> >> >> >> >> >>> ("name");
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> The first is probably a little easier for the
> >> >> application
> >> >> >> >> >> >>> developer
> >> >> >> >> >> >>> > but
> >> >> >> >> >> >>> > >> the second is much easier for the service
> >> developer.
> >> >> IMO,
> >> >> >> >> >> the
> >> >> >> >> >> >>> dynamic
> >> >> >> >> >> >>> > >> case is the best place to start and, again, we
> >> >> >> >> >> definitely will
> >> >> >> >> >> >>> want
> >> >> >> >> >> >>> > >> support for both.
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> Thanks.
> >> >> >> >> >> >>> > >> --
> >> >> >> >> >> >>> > >> Kevin
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> Jeremy Boynes wrote:
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> > I think this would be useful but it seems more
> >> >> like a
> >> >> >> >> >> >>> traditional
> >> >> >> >> >> >>> > >> > persistence API than what Luciano was
> suggesting.
> >> >> With
> >> >> >> >> >> this
> >> >> >> >> >> >>> one a
> >> >> >> >> >> >>> > >> > user needs to know about DataObject's, commands,
> >> SQL
> >> >> >> >> >> strings
> >> >> >> >> >> >>> etc.
> >> >> >> >> >> >>> > >> > just like they would if they were using raw
> >> JDBC or
> >> >> >> JPA.
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed
> more
> >> >> about
> >> >> >> >> >> >>> expressing
> >> >> >> >> >> >>> > >> > high-level CRUD operations as operations on a
> >> >> service
> >> >> >> >> >> >>> interface:
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> public List getAllCustomers();
> >> >> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
> >> >> >> >> >> accountNumber);
> >> >> >> >> >> >>> > >> >>> }
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > which is all application level concepts rather
> >> >> >> >> >> than persistence
> >> >> >> >> >> >>> > level
> >> >> >> >> >> >>> > >> > concepts. I'd actually go a little further and
> >> put
> >> >> that
> >> >> >> >> >> >>> right into
> >> >> >> >> >> >>> > >> > the service contract:
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > public interface AccountService {
> >> >> >> >> >> >>> > >> > List<Customer> getAllCustomers();
> >> >> >> >> >> >>> > >> > Account getCustomerAccount(String
> >> >> accountNumber);
> >> >> >> >> >> >>> > >> > }
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
> >> >> >> >> >> standardized
> >> >> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
> >> >> >> configuration
> >> >> >> >> >> >>> would be
> >> >> >> >> >> >>> > >> > needed except to add this to the logical
> >> assembly:
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > <component name="AccountStore">
> >> >> >> >> >> >>> > >> > <implementation.das
> >> resource="MySQLDatabase"/>
> >> >> >> >> >> >>> > >> > </component>
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > With SCA's ability to translate service
> >> contracts,
> >> >> this
> >> >> >> >> >> >>> should be
> >> >> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
> >> >> >> >> >> regardless of
> >> >> >> >> >> >>> > whether
> >> >> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by
> >> IIOP or
> >> >> >> >> >> running on
> >> >> >> >> >> a
> >> >> >> >> >> >>> > Java,
> >> >> >> >> >> >>> > >> > C++ or PHP platform.
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > The important thing here is that the client is
> >> >> >> >> >> isolated from
> >> >> >> >> >> >>> how
> >> >> >> >> >> >>> > the
> >> >> >> >> >> >>> > >> > DAS component is provided. We could have
> multiple
> >> >> >> >> >> declarative
> >> >> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and
> one
> >> >> that
> >> >> >> did
> >> >> >> >> >> >>> stuff
> >> >> >> >> >> >>> > with
> >> >> >> >> >> >>> > >> > XML databases like Xindice; alternatively,
> >> /without
> >> >> >> >> >> altering
> >> >> >> >> >> >>> the
> >> >> >> >> >> >>> > >> > client at all/ they could switch to a custom
> >> coded
> >> >> >> version
> >> >> >> >> >> >>> written
> >> >> >> >> >> >>> > in
> >> >> >> >> >> >>> > >> > Java, C++ or a store procedure language like
> >> PL/SQL.
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > --
> >> >> >> >> >> >>> > >> > Jeremy
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams
> >> wrote:
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >> 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 code
> >> >> specific to
> >> >> >> >> >> a new
> >> >> >> >> >> >>> > >> >> service. Instead, the service will be
> >> >> "instantiated"
> >> >> >> >> >> based
> >> >> >> >> >> >>> on the
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >> >> provided DAS config file. The service
> interface
> >> >> >> >> >> might look
> >> >> >> >> >> >>> like
> >> >> >> >> >> >>> > >> this:
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> public interface RDBDASService
> >> >> >> >> >> >>> > >> >> DataObject execute(String commandName);
> >> >> >> >> >> >>> > >> >> DataObject executeSQL(String
> >> abitrarySQL);
> >> >> >> >> >> >>> > >> >> void applyChanges(DataObject graphRoot);
> >> >> >> >> >> >>> > >> >> }
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> So, depending on the config file used to
> >> >> >> instantiate the
> >> >> >> >> >> >>> service,
> >> >> >> >> >> >>> > >> >> this interface could be used to return
> >> Customers/
> >> >> >> >> >> Accounts or
> >> >> >> >> >> >>> > >> >> Toasters. In fact, a lot could be achieved
> with
> >> no
> >> >> >> >> >> >>> > configuration at
> >> >> >> >> >> >>> > >> >> all by restricting use to: DataObject
> >> >> >> executeSQL(String
> >> >> >> >> >> >>> > >> abitrarySQL);
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> I expand a bit here:
> >> >> http://mail-archives.apache.org/
> >> >> >> >> >> >>> mod_mbox/ws-
> >> >> >> >> >> >>> > >> >>
> >> >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> Once this was working it should be
> >> >> straightforward to
> >> >> >> >> >> build
> >> >> >> >> >> >>> more
> >> >> >> >> >> >>> > >> >> strongly typed services and possible put
> >> together
> >> >> some
> >> >> >> >> >> >>> generation
> >> >> >> >> >> >>> > >> >> tooling. We could also start looking at
> support
> >> >> for
> >> >> a
> >> >> >> >> >> more
> >> >> >> >> >> >>> > RESTFul
> >> >> >> >> >> >>> > >> >> interface.
> >> >> >> >> >> >>> > >> >> --
> >> >> >> >> >> >>> > >> >> Kevin
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> Luciano Resende wrote:
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>> Recently, people have been starting to talk
> >> about
> >> >> >> >> >> better DAS
> >> >> >> >> >> >>> > >> >>> integration
> >> >> >> >> >> >>> > >> >>> with DAS, and below are some threads on the
> >> >> subject
> >> >> :
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> >> msg08833.html
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> >> msg08923.html
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >>
> >> >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >> >> >> >> >>> msg09715.html
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me
> make
> >> >> sure
> >> >> >> >> >> what I'm
> >> >> >> >> >> >>> > >> >>> saying is not
> >> >> >> >> >> >>> > >> >>> yet available on SCA today.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Today, defining a service to work with a
> >> >> relational
> >> >> >> >> >> >>> database, you
> >> >> >> >> >> >>> > >> >>> will need
> >> >> >> >> >> >>> > >> >>> to code the persistence side of the service
> >> where
> >> >> >> CRUD
> >> >> >> >> >> >>> operations
> >> >> >> >> >> >>> > >> >>> to the
> >> >> >> >> >> >>> > >> >>> database will be done.
> >> >> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
> >> >> coding
> >> >> >> >> >> the
> >> >> >> >> >> >>> CRUD
> >> >> >> >> >> >>> > >> >>> operations on
> >> >> >> >> >> >>> > >> >>> the persistence layer would be avoided as
> >> much as
> >> >> >> >> >> possible.
> >> >> >> >> >> >>> > >> >>> The idea would be to have a more "declarative
> >> DAS"
> >> >> >> when
> >> >> >> >> >> >>> defining
> >> >> >> >> >> >>> > SCA
> >> >> >> >> >> >>> > >> >>> Services, so you would either use some
> >> Annotations
> >> >> >> >> >> or SCDL
> >> >> >> >> >> to
> >> >> >> >> >> >>> > >> have the
> >> >> >> >> >> >>> > >> >>> "declarative DAS" configuration inside it.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> I was thinking on something like....
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> SCDL Definition would look something like
> >> this :
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> <component name="AccountDataService">
> >> >> >> >> >> >>> > >> >>> <interface.java
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> class="bigbank.account.services.account.AccountService"/>
> >> >> >> >> >> >>> > >> >>> <implementation.das="dasConfig.properties"
> >> >> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >> >> >> >> >>> > >> >>> </component>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> The AccountService Interface would look like
> >> this
> >> >> >> >> >> (missing
> >> >> >> >> >> >>> any
> >> >> >> >> >> >>> > SCA
> >> >> >> >> >> >>> > >> >>> annotations):
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> public List getAllCustomers();
> >> >> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
> >> >> >> >> >> accountNumber);
> >> >> >> >> >> >>> > >> >>> }
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> The DAS config would look like this, and would
> >> >> >> have the
> >> >> >> >> >> >>> > definition
> >> >> >> >> >> >>> > >> >>> for the
> >> >> >> >> >> >>> > >> >>> "all companies" command.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> <Config ...>
> >> >> >> >> >> >>> > >> >>> ...
> >> >> >> >> >> >>> > >> >>> <ConnectionInfo
> >> dataSource="java:comp/env/jdbc/
> >> >> >> >> >> bigbank"/>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select
> *
> >> >> from
> >> >> >> >> >> >>> CUSTOMERS"
> >> >> >> >> >> >>> > >> >>> kind="Select"/>
> >> >> >> >> >> >>> > >> >>> <Command name="getCustomerAccount"
> >> SQL="SELECT
> >> >> >> >> >> >>> accountNumber,
> >> >> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
> >> >> >> >> >> accountNumber = ?"
> >> >> >> >> >> >>> > >> >>> kind="Select" />
> >> >> >> >> >> >>> > >> >>> ...
> >> >> >> >> >> >>> > >> >>> </Config>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Mapping between interface methods and DAS
> >> Commands
> >> >> >> >> >> >>> > >> >>> - If a DAS config file is provided, based on
> >> the
> >> >> >> >> >> >>> > SCDL definition,
> >> >> >> >> >> >>> > >> we
> >> >> >> >> >> >>> > >> >>> would look for "DAS command" based on the
> >> name of
> >> >> the
> >> >> >> >> >> getter
> >> >> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to
> >> getAllCustomers
> >> >> >> >> >> command)
> >> >> >> >> >> >>> > >> >>> - Otherwise, we would try to do a map
> >> >> directly to
> >> >> a
> >> >> >> >> >> >>> > >> stored procedure
> >> >> >> >> >> >>> > >> >>> - We could also have a way to force the
> >> >> mapping by
> >> >> >> >> >> using
> >> >> >> >> >> >>> > >> annotation
> >> >> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Mapping between method parameter and command
> >> >> >> parameter
> >> >> >> >> >> >>> > >> >>> - We would need to define a method for
> >> >> mapping the
> >> >> >> >> >> method
> >> >> >> >> >> >>> > >> >>> parameters to
> >> >> >> >> >> >>> > >> >>> the query paramters either based on position (
> >> >> >> e.gfirst
> >> >> >> >> >> >>> method
> >> >> >> >> >> >>> > >> >>> parameter
> >> >> >> >> >> >>> > >> >>> maps to the first command paramter), or we
> >> >> would do
> >> >> >> some
> >> >> >> >> >> >>> > mapping by
> >> >> >> >> >> >>> > >> >>> name
> >> >> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Note:
> >> >> >> >> >> >>> > >> >>> - A SCDL connection information would
> >> >> override the
> >> >> >> DAS
> >> >> >> >> >> >>> Config
> >> >> >> >> >> >>> > file
> >> >> >> >> >> >>> > >> >>> connection information.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Benefits
> >> >> >> >> >> >>> > >> >>> - It's All about simplicity and easy of use
> >> >> >> >> >> >>> > >> >>> - This would allow a user to define a
> service
> >> >> >> without
> >> >> >> >> >> >>> having to
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >> >>> explicitly having to code any Data Access
> >> related
> >> >> >> code.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Implementation approaches
> >> >> >> >> >> >>> > >> >>> - Utilizing DAS : This approach would start
> >> from
> >> >> >> the
> >> >> >> >> >> >>> current
> >> >> >> >> >> >>> > >> >>> Tuscany DAS
> >> >> >> >> >> >>> > >> >>> implementation, where functionality would be
> >> >> already
> >> >> >> >> >> >>> > available, but
> >> >> >> >> >> >>> > >> >>> the
> >> >> >> >> >> >>> > >> >>> service implementation would be tied to SDO
> and
> >> >> RDB
> >> >> >> >> >> as this
> >> >> >> >> >> >>> > is what
> >> >> >> >> >> >>> > >> >>> DAS
> >> >> >> >> >> >>> > >> >>> supports today.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> - Start simple and grow : We could start
> >> simple,
> >> >> by
> >> >> >> >> >> >>> having a
> >> >> >> >> >> >>> > >> simple
> >> >> >> >> >> >>> > >> >>> implementation based on JDBC and would return
> >> some
> >> >> >> >> >> simple
> >> >> >> >> >> >>> > >> >>> collection as a
> >> >> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset),
> >> this
> >> >> >> could
> >> >> >> >> >> >>> give us
> >> >> >> >> >> >>> > a
> >> >> >> >> >> >>> > >> >>> quick
> >> >> >> >> >> >>> > >> >>> start to flush implementation details and get
> a
> >> >> >> proven
> >> >> >> >> >> >>> design,
> >> >> >> >> >> >>> > and
> >> >> >> >> >> >>> > >> >>> this
> >> >> >> >> >> >>> > >> >>> could get evolved to use a DAS that would
> >> support
> >> >> >> >> >> multiple
> >> >> >> >> >> >>> > backends
> >> >> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as
> well
> >> as
> >> >> >> >> >> non- SDO
> >> >> >> >> >> >>> types
> >> >> >> >> >> >>> > >> as a
> >> >> >> >> >> >>> > >> >>> command
> >> >> >> >> >> >>> > >> >>> result.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Toughts ?
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> - Luciano
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <kevincbw@qwest.net
> >
> >> >> >> wrote:
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> 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. Another thing we want to
> >> >> eventually
> >> >> >> >> >> >>> explore is
> >> >> >> >> >> >>> > >> >>>> exposing
> >> >> >> >> >> >>> > >> >>>> a DAS as REST-oriented services. As we have
> >> seen
> >> >> >> >> >> from the
> >> >> >> >> >> >>> > parent
> >> >> >> >> >> >>> > >> >>>> thread
> >> >> >> >> >> >>> > >> >>>> there are almost too many possible
> approaches.
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a
> >> service
> >> >> >> and
> >> >> >> >> >> >>> create a
> >> >> >> >> >> >>> > new
> >> >> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas
> >> ). The
> >> >> >> main
> >> >> >> >> >> >>> reason
> >> >> >> >> >> >>> > has
> >> >> >> >> >> >>> > >> >>>> to do
> >> >> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS
> >> that
> >> >> >> >> >> >>> > Jeremy mentioned
> >> >> >> >> >> >>> > >> >>>> which
> >> >> >> >> >> >>> > >> >>>> is all about creating data access services
> >> >> >> >> >> >>> declaratively. A new
> >> >> >> >> >> >>> > >> >>>> component type and a service that we build by
> >> >> hand
> >> >> >> >> >> would be
> >> >> >> >> >> >>> > a good
> >> >> >> >> >> >>> > >> >>>> step
> >> >> >> >> >> >>> > >> >>>> in this direction.
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> >> >> >> >> interface like
> >> >> >> >> >> >>> > this:
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> public interface RDBDASService
> >> >> >> >> >> >>> > >> >>>> void applyChanges(DataObject
> >> graphRoot);
> >> >> >> >> >> >>> > >> >>>> DataObject execute(String
> >> commandName);
> >> >> >> >> >> >>> > >> >>>> DataObject executeSQL(String
> >> >> abitrarySQL);
> >> >> >> >> >> >>> > >> >>>> }
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> The service would be initialized with an
> >> optional
> >> >> >> >> >> RDB DAS
> >> >> >> >> >> >>> > >> config file
> >> >> >> >> >> >>> > >> >>>> that defines connection properties, a set of
> >> >> >> commands,
> >> >> >> >> >> >>> etc. So,
> >> >> >> >> >> >>> > >> >>>> different services implementing the same
> >> >> interface
> >> >> >> >> >> could be
> >> >> >> >> >> >>> > >> >>>> initialized
> >> >> >> >> >> >>> > >> >>>> from separate config files.
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> Eventually, we might want to build services
> >> like
> >> >> >> this:
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> public interface Customers_RDBDASService
> >> >> >> >> >> >>> > >> >>>> void applyChanges(DataObject
> >> graphRoot);
> >> >> >> >> >> >>> > >> >>>> DataObject
> getAllCustomersWithLastName
> >> >> >> (String
> >> >> >> >> >> >>> > lastName);
> >> >> >> >> >> >>> > >> >>>> DataObject getAll
> >> CustomersAndOrdersForID
> >> >> >> (int
> >> >> >> >> >> >>> > customerId);
> >> >> >> >> >> >>> > >> >>>> }
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> But, for this to be very useful would
> probably
> >> >> >> require
> >> >> >> >> >> >>> some code
> >> >> >> >> >> >>> > >> >>>> generation tooling.
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> Thoughts?
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> --Kevin
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> Luciano Resende wrote:
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have
> a
> >> >> >> >> >> declarative
> >> >> >> >> >> >>> > DAS and
> >> >> >> >> >> >>> > >> >>>> will be
> >> >> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki
> >> >> soon...
> >> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >> >>> > >> >>>> > - Luciano
> >> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes
> >> <jb...@apache.org>
> >> >> >> >> >> 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 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.
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I
> >> >> think we
> >> >> >> >> >> >>> > should welcome
> >> >> >> >> >> >>> > >> it
> >> >> >> >> >> >>> > >> >>>> >> like we would any other contribution.
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >> >> 3) to access data through an
> application
> >> >> >> >> >> service with
> >> >> >> >> >> >>> > >> >>>> declarative
> >> >> >> >> >> >>> > >> >>>> >> >> implementation by DAS
> >> >> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks
> >> >> radar.
> >> >> >> >> >> >>> > >> >>>> >> --
> >> >> >> >> >> >>> > >> >>>> >> Jeremy
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> --------------------------------------------------------------------
> >> >> >> >> >> >>> > >> -
> >> >> >> >> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> >> >>> unsubscribe@ws.apache.org
> >> >> >> >> >> >>> > >> >>>> >> For additional commands, e-mail:
> >> >> >> >> >> >>> > tuscany-dev-help@ws.apache.org
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> --------------------------------------------------------------------
> >> >> >> >> >> >>> > >> -
> >> >> >> >> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> >> >>> unsubscribe@ws.apache.org
> >> >> >> >> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
> >> >> >> >> >> >>> help@ws.apache.org
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
> >> >> >> >> >> >>> help@ws.apache.org
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
> >> >> >> >> >> help@ws.apache.org
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >> >> >>> > >> For additional commands, e-mail: tuscany-dev-
> >> >> >> >> >> help@ws.apache.org
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >>> > To unsubscribe, e-mail:
> >> >> >> tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> >> >>> > For additional commands, e-mail:
> >> >> >> tuscany-dev-help@ws.apache.org
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>>
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >>> To unsubscribe, e-mail:
> >> >> tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> >> >>> For additional commands, e-mail:
> >> >> >> tuscany-dev-help@ws.apache.org
> >> >> >> >> >> >>>
> >> >> >> >> >> >>>
> >> >> >> >> >> >>>
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> > To unsubscribe, e-mail:
> >> tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> >> > For additional commands, e-mail:
> >> >> tuscany-dev-help@ws.apache.org
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail:
> >> tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> >> For additional commands, e-mail:
> >> tuscany-dev-help@ws.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi Luciano,
I have attached code jar and doc today to
https://issues.apache.org/jira/browse/TUSCANY-898
Here I am trying to follow the approach of implementing SCA container for DAS.
Will you please go through the same and let me know if there is some
overlap in what you are developing with this? Also please let me know
if we can have an IRC chat to discuss this in more details and see how
we can work together on this by splitting the work items etc.
Regards,
Amita
On 11/3/06, Amita Vadhavkar <am...@gmail.com> wrote:
> Hi,
> I am trying to create a container for DAS-SCA too (not just for stored
> procedure) and will be able to send a working code in ML over the weekend.
>
> Below is summary of what I got so far from the previous mail discussions
> and
> some questions.
>
>
> The integration between DAS and SCA can happen at application level as
> service or at container level.
>
>
>
> 2 different possible approaches –
>
> static – e.g. getAllCustomers
>
> dynamic – e.g. execute("all customers");
>
>
>
> For application level service – it is the sample *
> sample-StoredProcedureService.jar* or what Luciano is providing in more
> details, is an example. In *sample-StoredProcedureService.jar* example
> dynamic approach is followed
>
>
>
> For container approach – again static or dynamic approach can be followed.
> For static – it's like providing service for getAllCompanies(),
> getAllCustomers() etc. whereas for dynamic its like execute(command) where
> command can be "getAllCompanies", "getAllCustomers". Etc.
>
>
>
> I am working on a container implementation where dynamic
> approach is followed.
>
>
>
> There are 2 places where extensibility is required –
>
> 1) for providing different data access mechanisms. i.e. today there is
> RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the scdl
> will
> be same, but the exampleconfig.xml will change.
>
> In the container I am working on - Scdl has a new tag
>
> Scdl has a new tag
> <da:implementation.da script="customersOrders/CustomersOrders.xml"
> dataAccessType="rdb"/>
>
>
>
> Here, dataAccessType – is the key which tells whether it's RDB or something
> else. And the xml script provides the connection and data store details.
>
>
>
> 2) for RDB-DAS – providing support for different databases (this
> portion should be part of DAS and not SCA.) In the current container I am
> working on it is provided as a package -
> org.apache.tuscany.container.dataaccessshelper package - which should
> finally go into DAS codeline(?).
>
>
>
>
>
> For static approach we may need some code generation tooling. Also could
> not
> understand how this can be merged into RESTful interfaces. (this was
> mentioned in some mail conversation)
>
>
>
> Regards,
>
> Amita
>
>
> On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> > Luciano Resende wrote:
> >
> > > Comments in-line...
> > >
> > > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> > >
> > >>
> > >>
> > >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > I would also like to understand this a little better ... here I am
> > >> > thinking
> > >> > aloud and hope the others will help in getting my persceptions
> > >> > right...
> > >> >
> > >> > I guess firstly it is a question of how or where we want to
> > >> > position 'DAS
> > >> > Integration' in SCA. Is is something we want to integrate as the
> > >> > Application Layer, which I understand is what Amita is trying
> > >> > presently and
> > >> > which Jim refers to as component implementation. In this option
> > >> > we get to
> > >> > do some sort of a service wrapper to DAS and then it becomes a
> > >> > demonstration
> > >> > of two Tuscany subprojects integrating at application level.
> > >> >
> > >
> > >
> > >
> > > Yes, I think we have space to position DAS both ways, and integrating
> > > in the
> > > application layer by exposing DAS as a service would be a very easy and
> > > quick, this could be exposed as a sample app, and could show we are
> > > working
> > > on getting a better integration between DAS and SCA
> > >
> > >
> > >> Or do we want to position DAS at the infrastructure layer as another
> > >> > extension type (either container or binding). I guess this is
> > >> > where Ant
> > >> > started this - proposing a JDBC container / binding for component
> > >> > implementation in StoredProcedures.
> > >> I was thinking a DAS was a way to declaratively model heterogeneous
> > >> data as a service and offer a mechanism for remoting that data. In
> > >> other words, it provided the ability for an application to perform
> > >> CRUD using a high-level contract (interface) and having those
> > >> operations take place across a service network. How this is hooked
> > >> into the SCA container is probably best done as an extension type,
> > >> i.e. someone could specify:
> > >>
> > >> <component name="Foo">
> > >> <implementation.das>
> > >> <interface.java ....>
> > >> </implementation.das>
> > >> </component>
> > >
> > >
> > >
> > >
> > > Yes, this goes back to the way I was thinking on my original proposal.
> > >
> > >
> > >> If this is the path we should take
> > >> > then we probably have to think beyond DAS - to something more
> > >> > general - of
> > >> > which DAS is just a special case. I suppose this is what Jim has
> > also
> > >> > suggested in trying to explore other persistence mechanisms.
> > >> >
> > >> This may be the crux of the confusion. I was thinking DAS provides a
> > >> general mechanism for accessing heterogeneous data and is only right
> > >> now tied to SQL because of resource constraints (i.e. we have to
> > >> start somewhere). Ultimately, DAS should provide the infrastructure
> > >> for dealing with multiple, varied data stores and mechanisms for
> > >> querying across them. In other words, I guess I am saying DAS should
> > >> be the general solution (declarative and heterogeneous) since if it
> > >> is only a programmatic way to access relational data then its value
> > >> is less clear in comparison to things such as JDBC 4 or JPA.
> > >
> > >
> > >
> > >
> > > Yes, the current status of DAS implementation is RDB only. I would say
> > > that,
> > > in the future, I'd like to see a heterogeneous DAS that would give you
> > > access to different data stores, and probably support non-SDO types as
> > > well.
> > >
> > >> I too feel that this is something that must be done as an extension
> > >> > type -
> > >> > but yet to get my hands on the general scheme of things that DAS
> > >> > can slip
> > >> > into. Infact the other thread where Jeremy has taken forward a
> > >> > proposal to
> > >> > the specs group on resources tempts me to think that there is going
> > >> > to be
> > >> > something in that which we can leverage from.
> > >> >
> > >> I think resources are orthogonal as they are about a component
> > >> implementation's contract with its container. Declarative data
> > >> services on the other hand are about application constructs that can
> > >> be wired to.
> > >>
> > >> > I hope to get a better understanding this as we go along in this
> > >> > thread :)
> > >> >
> > >> Me too :-) As soon as I have trouble explaining technologies to .NET
> > >> people and they say "you Unix/Java people are at it again with a
> > >> thousand ways to do the same exact thing" it causes me to think that
> > >> maybe we need to clarify our message.
> > >
> > >
> > >
> > >
> > > If we all think it would be useful, I could try to summarize the
> > > thread on
> > > the wiki with a more clean proposal incorporating all your feedback ,
> > > what
> > > you guys think ?
> >
> > Yes. Great idea.
> >
> > >
> > >
> > > Jim
> > >
> > >> > Thanks
> > >> >
> > >> > - Venkat
> > >> >
> > >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> > >> >>
> > >> >> Jim Marino wrote:
> > >> >>
> > >> >> > When I first read the thread on this, I thought the DAS service
> > >> >> would
> > >> >> > be a component extension type (e.g. analogous to a
> > >> >> > implementation.java or implementation.ejb) and not a component
> > >> >> > implementation type, which would allow for dynamic and eventually
> > >> >> > declarative configuration styles.
> > >> >>
> > >> >> I have not very familiar with the terminology so I am not sure what
> > a
> > >> >> "component extension type" is. But, I do think we eventually want
> > >> >> "implementation.rdbdas". Wouldn't this be a new implementation
> > type?
> > >> >>
> > >> >> It looks like Amita chose to start with a POJO. I notice the use
> > >> >> of "
> > >> >> implementation.java".
> > >> >>
> > >> >> > Either way, though, I am curious as to why
> > >> >> >
> > >> >> > public DAS configureService(String configFile);
> > >> >> >
> > >> >> > exists as part of the service definition? If the DAS service was
> a
> > >> >> > component extension type, it could be handled as part of the
> > >> >> > application bootstrap. If the DAS service was a component
> > >> >> > implementation type, the configuration file URI could be passed
> > >> >> in as
> > >> >> > a property and then processed in an initializer method decorated
> > by
> > >> >> > the SCA @Init annotation. In the latter case, if the
> > implementation
> > >> >> > of DASService thread-safe (hopefully it is since configuration
> > >> >> would
> > >> >> > seem to be a heavyweight operation), then I would make the
> > >> >> component
> > >> >> > module scoped to avoid initialization overhead on every
> > resolution.
> > >> >>
> > >> >> >
> > >> >> > In both approaches (extension vs. implementation type), having
> > >> >> > configuration exposed to the application doesn't quite feel
> right,
> > >> >> > since that is what DI tries to externalize.
> > >> >>
> > >> >> I agree. The configuration should be part of the initialization
> and
> > >> >> should use SCA patterns to do this. I think that Amita meant to
> use
> > >> >> eventually use a component property for the DAS config info but
> > >> >> started
> > >> >> with a method.
> > >> >>
> > >> >> >
> > >> >> > Also, I was thinking that in having this a component extension
> > >> >> type,
> > >> >> > the service interfaces returned from a resolution could include
> > the
> > >> >> > dynamic one described below or static ones people have mentioned.
> > I
> > >> >> > guess it is best to start with the easier-to-implement part
> > >> >> first and
> > >> >> > support the dynamic interface.
> > >> >> >
> > >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> > >> >> > understand what DAS provides in relation to other persistence
> > >> >> > technologies. Outside of the Java world, Microsoft is promoting
> > >> >> LINQ
> > >> >> > which is really interesting, and it would be informative to
> > compare
> > >> >> > the goals of DAS with that approach (there are obvious
> differences
> > >> >> > such as having the query language a strongly-typed part of the
> > >> >> > programming language, e.g. C#, and LINQ's use of closures).
> > >> >> >
> > >> >> > In contrasting DAS to O-R technologies, I see the primary use
> > cases
> > >> >> > for the former being a quick way to issue a query that may be
> > >> >> > executed against *heterogeneous* data stores and have that data
> > >> >> flow
> > >> >> > remotely or to a client that is not necessarily Java-based. One
> > key
> > >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> > >> >> (Hibernate
> > >> >> > and JPA are about as easy):
> > >> >> >
> > >> >> IMO the primary use case for DAS is an application that is SDO-
> > >> >> centric
> > >> >> and is taking advantage of its disconnected capabilities. The RDB
> > >> >> DAS
> > >> >> is built to work with SDO and uses the change summary to drive
> > >> >> changes
> > >> >> made to a disconnected data graph back to some store. This is not
> > to
> > >> >> say that a relational DAS could not be built on top of JPA, in
> fact,
> > >> >> this might be a very useful thing to do. The implementation we
> > >> >> currently have provides a very straightforward implicit mapping
> from
> > >> >> DataObjects to Tables. If more capable mapping is needed then it
> > >> >> makes
> > >> >> sense to use the JPA-defined technology and artifacts. A modified
> > >> >> Entity manager might be needed to take advantage of SDO's change
> > >> >> summary.
> > >> >>
> > >> >> >
> > >> >> > public interface CustomerDao extends BaseQuery {
> > >> >> > @Select("select * from customers where city = ?1")
> > >> >> > DataSet<Customer> findCustomersFrom(String city);
> > >> >> > }
> > >> >> >
> > >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> > >> >> > (CustomerDao.class, datasource);
> > >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> > >> >> >
> > >> >> >
> > >> >> > The other key is remote data and change lists. I think there are
> > >> >> > (literally) about a thousand ways that already exist to handle
> the
> > >> >> > "local" data case. For change lists, interop with ADO.NET's
> change
> > >> >> > summary facilities would be interesting.
> > >> >>
> > >> >> I agree. Also, it looks like Xcalia may have a similar thought:
> > >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> > >> >>
> > >> >> >
> > >> >> > I'm playing devil's advocate a bit with DAS, but I think it is
> > >> >> > important we have a clear statement as to when it is appropriate
> > >> >> and
> > >> >> > not appropriate to use. One place to start would be to compare
> > >> >> it to
> > >> >> > JDBC 4 and JPA.
> > >> >>
> > >> >> We can get started with JPA:
> > >> >>
> > >> >> * JPA is java-specific, container-based, built around a
> > connected
> > >> >> data model and offers a complete O/R mapping for POJOs
> > >> >>
> > >> >> * The RDB DAS is a java implementation of a language - neutral
> > >> >> concept (hopefully specified some day) that is containerless,
> > >> >> assumes a disconnected data model and provides a simple,
> > >> >> implicit
> > >> >> mapping for SDO DataObjects (Dynamic or Static) to relational
> > >> >> tables.
> > >> >>
> > >> >> Anything else?
> > >> >>
> > >> >> >
> > >> >> > Jim
> > >> >> >
> > >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> > >> >> >
> > >> >> >> Hi Amita
> > >> >> >>
> > >> >> >> I think we were both going on the same way, with the DAS Service
> > >> >> >> sample,
> > >> >> >> altough i had the interface more like this, to be more flexible
> :
> > >> >> >>
> > >> >> >> public interface DASService {
> > >> >> >>
> > >> >> >> public DAS configureService(String configFile);
> > >> >> >
> > >> >> >
> > >> >> >> public DataObject executeCommand(String commandName);
> > >> >> >> public DataObject execute(String newCommand);
> > >> >> >> public void applyChanges(DataObject graphRoot);
> > >> >> >> }
> > >> >> >>
> > >> >> >>
> > >> >> >> As for having it as a sample, maybe we could defined the
> > >> >> DASService
> > >> >> >> as one
> > >> >> >> sample itself, and have a second version of companyWeb that
> would
> > >> >> >> consume
> > >> >> >> the service, something like :
> > >> >> >>
> > >> >> >> das\samples\companyWeb
> > >> >> >> das\samples\dasService
> > >> >> >> das\samples.companyWeb.service
> > >> >> >>
> > >> >> >> or, more like BigBank
> > >> >> >>
> > >> >> >> das\samples\companyweb.Service\dasService
> > >> >> >> das\samples\companyweb.Service\webClient
> > >> >> >>
> > >> >> >> Or even in sampleApps...
> > >> >> >>
> > >> >> >> Toughts ?
> > >> >> >>
> > >> >> >>
> > >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
> > >> >> >>
> > >> >> >>>
> > >> >> >>> Hi ,
> > >> >> >>> I am also following up another thread
> > >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> > >> >> msg09944.html
> > >> >> >>> on the
> > >> >> >>> similar issue (JDBC stored procedure container
> > >> >> >>> using DAS)
> > >> >> >>> Besides the fact that I am actively working on the container
> > >> >> work,
> > >> >> >>> I also
> > >> >> >>> have tried to
> > >> >> >>> develop a sample based on the below discussion, following
> > dynamic
> > >> >> >>> approach.
> > >> >> >>>
> > >> >> >>> I am attaching the same here. Please take a look and give your
> > >> >> >>> suggestions.
> > >> >> >>> In this, StoredProcedureService implementation has
> > >> >> setConfigInfo (DAS
> > >> >> >>> Config) and
> > >> >> >>> execute(Any SQL). This can be made more complete with
> > >> >> executeSQL(),
> > >> >> >>> applyChanges()
> > >> >> >>> etc.
> > >> >> >>>
> > >> >> >>> Can this be added to the existing set of samples?
> > >> >> >>>
> > >> >> >>> Regards,
> > >> >> >>> Amita
> > >> >> >>>
> > >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> > >> >> >>> >
> > >> >> >>> > Luciano Resende wrote:
> > >> >> >>> >
> > >> >> >>> > > Kevin, from what I understood from your suggestion, it was
> > >> >> >>> looking to
> > >> >> >>> > me
> > >> >> >>> > > more like exposing DAS as a service :
> > >> >> >>> > >
> > >> >> >>> > >>> public interface RDBDASService
> > >> >> >>> > >>> DataObject execute(String commandName);
> > >> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
> > >> >> >>> > >>> void applyChanges(DataObject graphRoot);
> > >> >> >>> > >>> }
> > >> >> >>> > >>
> > >> >> >>> > Yes, I am talking about exposing a DAS Service configured
> > >> >> with a
> > >> >> >>> > specific set of capabilities/commands defined in the DAS
> > config
> > >> >> >>> file.
> > >> >> >>> > So, if the implementation of the service interface above was
> > >> >> >>> configured
> > >> >> >>> > to work with Customers they would use the service like this:
> > >> >> >>> >
> > >> >> >>> > List customers = myRDBDASService.execute
> > ("getAllCustomers");
> > >> >> >>> > String name = customers.get(0).getString("name");
> > >> >> >>> >
> > >> >> >>> > This is not much different than the static interface you
> > >> >> proposed,
> > >> >> >>> > right?
> > >> >> >>> >
> > >> >> >>> > > And then, when a service developer defines the
> > >> >> AccountService,
> > >> >> >>> he will
> > >> >> >>> >
> > >> >> >>> > > have
> > >> >> >>> > > to know about yet another service, about how DAS works,
> > >> >> how it is
> > >> >> >>> > > configured, etc, etc... is that right ?
> > >> >> >>> > >
> > >> >> >>> > The abilities of the service are defined by the DAS config
> > >> >> file.
> > >> >> >>> So,
> > >> >> >>> > the person or tool that provides the config file must
> > >> >> understand
> > >> >> >>> how the
> > >> >> >>> >
> > >> >> >>> > RDB DAS APIs work. There is no getting around this.
> > >> >> >>> >
> > >> >> >>> > > My proposal was going more towards allowing the service
> > >> >> >>> developer to
> > >> >> >>> > > focus
> > >> >> >>> > > on defining the service, and let the "declarative das" to
> > >> >> >>> handle the
> > >> >> >>> > > persistent layer....
> > >> >> >>> > >
> > >> >> >>> > The DAS config file is the declaration of an instance of the
> > >> >> >>> DAS. That
> > >> >> >>> > instance can be exposed as a dynamic or typed service/
> > >> >> interface.
> > >> >> >>> That
> > >> >> >>> > seems to be the main discussion we are having. Although, I
> > >> >> may be
> > >> >> >>> > missing something.
> > >> >> >>> >
> > >> >> >>> > > Also, by defining some conventions over configuration
> > >> >> and/or using
> > >> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
> > >> >> >>> procedure),
> > >> >> >>> > the
> > >> >> >>> > > service developer could really define a service that
> > >> >> interacts
> > >> >> >>> with a
> > >> >> >>> > > RDB,
> > >> >> >>> > > without having to code the service persistence layer.
> > >> >> >>> > >
> > >> >> >>> > There is a lot of potential for the use of annotations.
> > >> >> >>> >
> > >> >> >>> > >
> > >> >> >>> > > - Luciano
> > >> >> >>> > >
> > >> >> >>> > >
> > >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
> > >> >> >>> > >
> > >> >> >>> > >>
> > >> >> >>> > >> The real difference between the two approaches is that
> > >> >> one is
> > >> >> >>> "Typed"
> > >> >> >>> > or
> > >> >> >>> > >> static and the other is dynamic. I think both are needed
> > >> >> but was
> > >> >> >>> > >> suggesting that we start with dynamic since it is the most
> > >> >> >>> flexible
> > >> >> >>> > and
> > >> >> >>> > >> seems to be a reasonable stepping stone towards a static
> > >> >> >>> capability.
> > >> >> >>> > >>
> > >> >> >>> > >> With either, the user does not need to know about
> > >> >> traditional
> > >> >> >>> > >> persistence frameworks. With the dynamic approach,
> > however,
> > >> >> >>> the user
> > >> >> >>> > >> does need to know about the dynamic SDO API.
> > >> >> >>> > >>
> > >> >> >>> > >> So, with the static interface the user might write:
> > >> >> >>> > >>
> > >> >> >>> > >> List customers = accountService.getAllCustomers();
> > >> >> >>> > >> String name = ((Customer)customers.get(0)).getName();
> > >> >> >>> > >>
> > >> >> >>> > >> The equivalent dynamic API might be:
> > >> >> >>> > >>
> > >> >> >>> > >> List customers =
> dasService.execute("getAllCustomers");
> > >> >> >>> > >> String name = ((DataObject)customers.get(0)).getString
> > >> >> >>> ("name");
> > >> >> >>> > >>
> > >> >> >>> > >> The first is probably a little easier for the application
> > >> >> >>> developer
> > >> >> >>> > but
> > >> >> >>> > >> the second is much easier for the service developer. IMO,
> > >> >> the
> > >> >> >>> dynamic
> > >> >> >>> > >> case is the best place to start and, again, we
> > >> >> definitely will
> > >> >> >>> want
> > >> >> >>> > >> support for both.
> > >> >> >>> > >>
> > >> >> >>> > >> Thanks.
> > >> >> >>> > >> --
> > >> >> >>> > >> Kevin
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >> Jeremy Boynes wrote:
> > >> >> >>> > >>
> > >> >> >>> > >> > I think this would be useful but it seems more like a
> > >> >> >>> traditional
> > >> >> >>> > >> > persistence API than what Luciano was suggesting. With
> > >> >> this
> > >> >> >>> one a
> > >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
> > >> >> strings
> > >> >> >>> etc.
> > >> >> >>> > >> > just like they would if they were using raw JDBC or JPA.
> > >> >> >>> > >> >
> > >> >> >>> > >> > On the other hand, Luciano's proposal seemed more about
> > >> >> >>> expressing
> > >> >> >>> > >> > high-level CRUD operations as operations on a service
> > >> >> >>> interface:
> > >> >> >>> > >> >
> > >> >> >>> > >> >>> public interface AccountService {
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> public List getAllCustomers();
> > >> >> >>> > >> >>> public Object getCustomerAccount(String
> > >> >> accountNumber);
> > >> >> >>> > >> >>> }
> > >> >> >>> > >> >>
> > >> >> >>> > >> >
> > >> >> >>> > >> > which is all application level concepts rather
> > >> >> than persistence
> > >> >> >>> > level
> > >> >> >>> > >> > concepts. I'd actually go a little further and put that
> > >> >> >>> right into
> > >> >> >>> > >> > the service contract:
> > >> >> >>> > >> >
> > >> >> >>> > >> > public interface AccountService {
> > >> >> >>> > >> > List<Customer> getAllCustomers();
> > >> >> >>> > >> > Account getCustomerAccount(String accountNumber);
> > >> >> >>> > >> > }
> > >> >> >>> > >> >
> > >> >> >>> > >> > In a ideal world, if the user was able to accept
> > >> >> standardized
> > >> >> >>> > >> > mappings (a la Rails et al) then no further
> configuration
> > >> >> >>> would be
> > >> >> >>> > >> > needed except to add this to the logical assembly:
> > >> >> >>> > >> >
> > >> >> >>> > >> > <component name="AccountStore">
> > >> >> >>> > >> > <implementation.das resource="MySQLDatabase"/>
> > >> >> >>> > >> > </component>
> > >> >> >>> > >> >
> > >> >> >>> > >> > With SCA's ability to translate service contracts, this
> > >> >> >>> should be
> > >> >> >>> > >> > callable from and deployable to any SCA runtime
> > >> >> regardless of
> > >> >> >>> > whether
> > >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> > >> >> running on
> > >> >> a
> > >> >> >>> > Java,
> > >> >> >>> > >> > C++ or PHP platform.
> > >> >> >>> > >> >
> > >> >> >>> > >> > The important thing here is that the client is
> > >> >> isolated from
> > >> >> >>> how
> > >> >> >>> > the
> > >> >> >>> > >> > DAS component is provided. We could have multiple
> > >> >> declarative
> > >> >> >>> > >> > implementations, say one based on RDB-DAS and one that
> > did
> > >> >> >>> stuff
> > >> >> >>> > with
> > >> >> >>> > >> > XML databases like Xindice; alternatively, /without
> > >> >> altering
> > >> >> >>> the
> > >> >> >>> > >> > client at all/ they could switch to a custom coded
> > version
> > >> >> >>> written
> > >> >> >>> > in
> > >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
> > >> >> >>> > >> >
> > >> >> >>> > >> > --
> > >> >> >>> > >> > Jeremy
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> > >> >> >>> > >> >
> > >> >> >>> > >> >> 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 code specific to
> > >> >> a new
> > >> >> >>> > >> >> service. Instead, the service will be "instantiated"
> > >> >> based
> > >> >> >>> on the
> > >> >> >>> >
> > >> >> >>> > >> >> provided DAS config file. The service interface
> > >> >> might look
> > >> >> >>> like
> > >> >> >>> > >> this:
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> public interface RDBDASService
> > >> >> >>> > >> >> DataObject execute(String commandName);
> > >> >> >>> > >> >> DataObject executeSQL(String abitrarySQL);
> > >> >> >>> > >> >> void applyChanges(DataObject graphRoot);
> > >> >> >>> > >> >> }
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> So, depending on the config file used to instantiate
> the
> > >> >> >>> service,
> > >> >> >>> > >> >> this interface could be used to return Customers/
> > >> >> Accounts or
> > >> >> >>> > >> >> Toasters. In fact, a lot could be achieved with no
> > >> >> >>> > configuration at
> > >> >> >>> > >> >> all by restricting use to: DataObject
> executeSQL(String
> > >> >> >>> > >> abitrarySQL);
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
> > >> >> >>> mod_mbox/ws-
> > >> >> >>> > >> >>
> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> Once this was working it should be straightforward to
> > >> >> build
> > >> >> >>> more
> > >> >> >>> > >> >> strongly typed services and possible put together some
> > >> >> >>> generation
> > >> >> >>> > >> >> tooling. We could also start looking at support for a
> > >> >> more
> > >> >> >>> > RESTFul
> > >> >> >>> > >> >> interface.
> > >> >> >>> > >> >> --
> > >> >> >>> > >> >> Kevin
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> Luciano Resende wrote:
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>> Recently, people have been starting to talk about
> > >> >> better DAS
> > >> >> >>> > >> >>> integration
> > >> >> >>> > >> >>> with DAS, and below are some threads on the subject :
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> > >> >> msg08833.html
> > >> >> >>> > >> >>>
> > >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> > >> >> msg08923.html
> > >> >> >>> > >> >>>
> > >> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> > >> >> >>> msg09715.html
> > >> >> >>> >
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
> > >> >> what I'm
> > >> >> >>> > >> >>> saying is not
> > >> >> >>> > >> >>> yet available on SCA today.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Today, defining a service to work with a relational
> > >> >> >>> database, you
> > >> >> >>> > >> >>> will need
> > >> >> >>> > >> >>> to code the persistence side of the service where CRUD
> > >> >> >>> operations
> > >> >> >>> > >> >>> to the
> > >> >> >>> > >> >>> database will be done.
> > >> >> >>> > >> >>> I was thinking on a simpler, easier way, where coding
> > >> >> the
> > >> >> >>> CRUD
> > >> >> >>> > >> >>> operations on
> > >> >> >>> > >> >>> the persistence layer would be avoided as much as
> > >> >> possible.
> > >> >> >>> > >> >>> The idea would be to have a more "declarative DAS"
> when
> > >> >> >>> defining
> > >> >> >>> > SCA
> > >> >> >>> > >> >>> Services, so you would either use some Annotations
> > >> >> or SCDL
> > >> >> to
> > >> >> >>> > >> have the
> > >> >> >>> > >> >>> "declarative DAS" configuration inside it.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> I was thinking on something like....
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> SCDL Definition would look something like this :
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> <component name="AccountDataService">
> > >> >> >>> > >> >>> <interface.java
> > >> >> >>> > >> >>>
> > >> >> class="bigbank.account.services.account.AccountService"/>
> > >> >> >>> > >> >>> <implementation.das="dasConfig.properties"
> > >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> > >> >> >>> > >> >>> </component>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> The AccountService Interface would look like this
> > >> >> (missing
> > >> >> >>> any
> > >> >> >>> > SCA
> > >> >> >>> > >> >>> annotations):
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> public interface AccountService {
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> public List getAllCustomers();
> > >> >> >>> > >> >>> public Object getCustomerAccount(String
> > >> >> accountNumber);
> > >> >> >>> > >> >>> }
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> The DAS config would look like this, and would have
> the
> > >> >> >>> > definition
> > >> >> >>> > >> >>> for the
> > >> >> >>> > >> >>> "all companies" command.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> <Config ...>
> > >> >> >>> > >> >>> ...
> > >> >> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
> > >> >> bigbank"/>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select * from
> > >> >> >>> CUSTOMERS"
> > >> >> >>> > >> >>> kind="Select"/>
> > >> >> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
> > >> >> >>> accountNumber,
> > >> >> >>> > >> >>> accountType, balance FROM accounts where
> > >> >> accountNumber = ?"
> > >> >> >>> > >> >>> kind="Select" />
> > >> >> >>> > >> >>> ...
> > >> >> >>> > >> >>> </Config>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
> > >> >> >>> > >> >>> - If a DAS config file is provided, based on the
> > >> >> >>> > SCDL definition,
> > >> >> >>> > >> we
> > >> >> >>> > >> >>> would look for "DAS command" based on the name of the
> > >> >> getter
> > >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> > >> >> command)
> > >> >> >>> > >> >>> - Otherwise, we would try to do a map directly to a
> > >> >> >>> > >> stored procedure
> > >> >> >>> > >> >>> - We could also have a way to force the mapping by
> > >> >> using
> > >> >> >>> > >> annotation
> > >> >> >>> > >> >>> (e.g@Procedure on the method level)
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Mapping between method parameter and command parameter
> > >> >> >>> > >> >>> - We would need to define a method for mapping the
> > >> >> method
> > >> >> >>> > >> >>> parameters to
> > >> >> >>> > >> >>> the query paramters either based on position (
> e.gfirst
> > >> >> >>> method
> > >> >> >>> > >> >>> parameter
> > >> >> >>> > >> >>> maps to the first command paramter), or we would do
> > some
> > >> >> >>> > mapping by
> > >> >> >>> > >> >>> name
> > >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Note:
> > >> >> >>> > >> >>> - A SCDL connection information would override the
> > DAS
> > >> >> >>> Config
> > >> >> >>> > file
> > >> >> >>> > >> >>> connection information.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Benefits
> > >> >> >>> > >> >>> - It's All about simplicity and easy of use
> > >> >> >>> > >> >>> - This would allow a user to define a service
> without
> > >> >> >>> having to
> > >> >> >>> >
> > >> >> >>> > >> >>> explicitly having to code any Data Access related
> code.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Implementation approaches
> > >> >> >>> > >> >>> - Utilizing DAS : This approach would start from the
> > >> >> >>> current
> > >> >> >>> > >> >>> Tuscany DAS
> > >> >> >>> > >> >>> implementation, where functionality would be already
> > >> >> >>> > available, but
> > >> >> >>> > >> >>> the
> > >> >> >>> > >> >>> service implementation would be tied to SDO and RDB
> > >> >> as this
> > >> >> >>> > is what
> > >> >> >>> > >> >>> DAS
> > >> >> >>> > >> >>> supports today.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> - Start simple and grow : We could start simple, by
> > >> >> >>> having a
> > >> >> >>> > >> simple
> > >> >> >>> > >> >>> implementation based on JDBC and would return some
> > >> >> simple
> > >> >> >>> > >> >>> collection as a
> > >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
> > could
> > >> >> >>> give us
> > >> >> >>> > a
> > >> >> >>> > >> >>> quick
> > >> >> >>> > >> >>> start to flush implementation details and get a proven
> > >> >> >>> design,
> > >> >> >>> > and
> > >> >> >>> > >> >>> this
> > >> >> >>> > >> >>> could get evolved to use a DAS that would support
> > >> >> multiple
> > >> >> >>> > backends
> > >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
> > >> >> non- SDO
> > >> >> >>> types
> > >> >> >>> > >> as a
> > >> >> >>> > >> >>> command
> > >> >> >>> > >> >>> result.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Toughts ?
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> - Luciano
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> 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. Another thing we want to eventually
> > >> >> >>> explore is
> > >> >> >>> > >> >>>> exposing
> > >> >> >>> > >> >>>> a DAS as REST-oriented services. As we have seen
> > >> >> from the
> > >> >> >>> > parent
> > >> >> >>> > >> >>>> thread
> > >> >> >>> > >> >>>> there are almost too many possible approaches.
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> My first thought is to model the DAS as a service and
> > >> >> >>> create a
> > >> >> >>> > new
> > >> >> >>> > >> >>>> implementation kind (implementation.rdbdas). The
> main
> > >> >> >>> reason
> > >> >> >>> > has
> > >> >> >>> > >> >>>> to do
> > >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
> > >> >> >>> > Jeremy mentioned
> > >> >> >>> > >> >>>> which
> > >> >> >>> > >> >>>> is all about creating data access services
> > >> >> >>> declaratively. A new
> > >> >> >>> > >> >>>> component type and a service that we build by hand
> > >> >> would be
> > >> >> >>> > a good
> > >> >> >>> > >> >>>> step
> > >> >> >>> > >> >>>> in this direction.
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> We might want to expose a DAS service with an
> > >> >> interface like
> > >> >> >>> > this:
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> public interface RDBDASService
> > >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> > >> >> >>> > >> >>>> DataObject execute(String commandName);
> > >> >> >>> > >> >>>> DataObject executeSQL(String abitrarySQL);
> > >> >> >>> > >> >>>> }
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> The service would be initialized with an optional
> > >> >> RDB DAS
> > >> >> >>> > >> config file
> > >> >> >>> > >> >>>> that defines connection properties, a set of
> commands,
> > >> >> >>> etc. So,
> > >> >> >>> > >> >>>> different services implementing the same interface
> > >> >> could be
> > >> >> >>> > >> >>>> initialized
> > >> >> >>> > >> >>>> from separate config files.
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> Eventually, we might want to build services like
> this:
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> public interface Customers_RDBDASService
> > >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> > >> >> >>> > >> >>>> DataObject getAllCustomersWithLastName
> (String
> > >> >> >>> > lastName);
> > >> >> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID
> (int
> > >> >> >>> > customerId);
> > >> >> >>> > >> >>>> }
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> But, for this to be very useful would probably
> require
> > >> >> >>> some code
> > >> >> >>> > >> >>>> generation tooling.
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> Thoughts?
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> --Kevin
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> Luciano Resende wrote:
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> > >> >> declarative
> > >> >> >>> > DAS and
> > >> >> >>> > >> >>>> will be
> > >> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
> > >> >> >>> > >> >>>> >
> > >> >> >>> > >> >>>> > - Luciano
> > >> >> >>> > >> >>>> >
> > >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
> > >> >> 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 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.
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> > >> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
> > >> >> >>> > should welcome
> > >> >> >>> > >> it
> > >> >> >>> > >> >>>> >> like we would any other contribution.
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >> >> 3) to access data through an application
> > >> >> service with
> > >> >> >>> > >> >>>> declarative
> > >> >> >>> > >> >>>> >> >> implementation by DAS
> > >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
> > >> >> >>> > >> >>>> >> --
> > >> >> >>> > >> >>>> >> Jeremy
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >>
> > >> >> >>>
> > >> >>
> --------------------------------------------------------------------
> > >> >> >>> > >> -
> > >> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
> > >> >> >>> unsubscribe@ws.apache.org
> > >> >> >>> > >> >>>> >> For additional commands, e-mail:
> > >> >> >>> > tuscany-dev-help@ws.apache.org
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >>
> > >> >> >>>
> > >> >>
> --------------------------------------------------------------------
> > >> >> >>> > >> -
> > >> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
> > >> >> >>> unsubscribe@ws.apache.org
> > >> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
> > >> >> >>> help@ws.apache.org
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> >
> > >> >> >>>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
> > >> >> unsubscribe@ws.apache.org
> > >> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
> > >> >> >>> help@ws.apache.org
> > >> >> >>> > >> >>
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> >
> > >> >> >>>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
> > >> >> unsubscribe@ws.apache.org
> > >> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
> > >> >> help@ws.apache.org
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
> > >> >> unsubscribe@ws.apache.org
> > >> >> >>> > >> For additional commands, e-mail: tuscany-dev-
> > >> >> help@ws.apache.org
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> >> >>> > For additional commands, e-mail:
> > tuscany-dev-help@ws.apache.org
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>>
> > >> >> >>>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> >> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >> >> >>>
> > >> >> >>>
> > >> >> >>>
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >> >>
> > >> >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Kevin Williams <ke...@qwest.net>.
Hi Amita,
This sounds good. Thanks for getting up so early!
--
Kevin
Amita Vadhavkar wrote:
> Hello Kevin , Luciano,
> Thanks a lot for all your suggestions and looking forward to have a
> IRC chat
> with you.
> I am proposing 9th Nov 5.30 a.m. IST (8th Nov 4.00 p.m. PST) for
> approx. 1
> hr.
> Please join the chat and we all can discuss -
> 1) what we are trying to provide - service, container
> 2) what all features can be provided
> 3) any high level design suggestions ( sim. to Kevin's latest reply )
> 4) any other suggestions
> 5) we can try to come up with a list of work items
> This will be very helpful in getting a clear picture of what all can
> be done
>
> in SCA (as well as DAS) domain for our current work.
>
> Regards,
> Amita
>
> On 11/8/06, Kevin Williams <ke...@qwest.net> wrote:
>
>>
>> Hello Amita,
>>
>> This looks promising. I notice your test case uses explicit updates and
>> inserts. While this is supported by the DAS it is not the preferred
>> usage which is to allow the RDB DAS to generate the CUD statements from
>> the SDO change history. Could you modify the example to read a data
>> graph and then post the changes back via "applyChanges"? Maybe the
>> equivalent of this simple test from the DAS test suite:
>>
>> public void testReadModifyApply4() throws Exception {
>>
>> DAS das = DAS.FACTORY.createDAS(getConfig("CustomerConfig.xml"),
>> getConnection());
>> // Read customer with particular ID
>> Command select = das.getCommand("getCustomer");
>> select.setParameter(1, 1);
>> DataObject root = select.executeQuery();
>>
>> DataObject customer = (DataObject) root.get("CUSTOMER[1]");
>>
>> // Modify customer
>> customer.set("LASTNAME", "Pavick");
>>
>> das.applyChanges(root);
>>
>> // Verify the change
>> root = select.executeQuery();
>> assertEquals("Pavick",
>> root.getDataObject("CUSTOMER[1]").getString("LASTNAME"));
>>
>> }
>>
>> Also, this service interface seems difficult to work with since command
>> identifiers and argument values are encoded in the params Vector
>>
>> public interface CustomersOrdersService {
>>
>> void execute(Vector params);
>> DataObject executeQuery(Vector params);
>> void applyChanges(Vector params);
>> DataObject executeAdhoc(Vector params);//adhoc query
>> implementation
>>
>> DataObject getAllCustomers(Vector paramsList);
>>
>> }
>>
>> Do you think it possible to implement something like the following
>> interface:
>>
>> public interface DynamicRDBDASService {
>>
>> DataObject execute(String commandName, List params);
>> DataObject executeAdHoc(String queryString, List params);
>> void applyChanges();
>> }
>>
>> The name is kind of long (suggestions welcome) but, I think this
>> interface could be generic and set of available commands is driven by
>> the provided DAS config file. I am not sure how we might support SP OUT
>> parameters but we can think about that later.
>>
>> I does seem like you and Luciano should team up on this.
>>
>> Thanks!
>> --
>> Kevin
>>
>>
>>
>>
>> Amita Vadhavkar wrote:
>>
>> > Hi Kevin,
>> > Thanks a lot for the comments. I have posted the code and doc on
>> JIRA-904
>> > for the container work. Also, am most likely missing something in the
>> > database
>> > connection portion. Would like to discuss with you.
>> >
>> > Will you please provide feedback on JIRA-904 attachments?
>> >
>> > I am checking with Luciano for a convenient date/time when we can
>> chat,
>> > would
>> > be great if you can also join. I am in IST timezone.
>> >
>> > Regards,
>> > Amita
>> >
>> > On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
>> >
>> >>
>> >> Hi Amita,
>> >> This is looking good. Some comments inline:
>> >>
>> >> Amita Vadhavkar wrote:
>> >>
>> >> > Hi,
>> >> > I am trying to create a container for DAS-SCA too (not just for
>> stored
>> >> > procedure) and will be able to send a working code in ML over the
>> >> > weekend.
>> >> >
>> >> > Below is summary of what I got so far from the previous mail
>> >> > discussions and
>> >> > some questions.
>> >> >
>> >> >
>> >> > The integration between DAS and SCA can happen at application level
>> as
>> >> > service or at container level.
>> >> >
>> >> >
>> >> >
>> >> > 2 different possible approaches –
>> >> >
>> >> > static – e.g. getAllCustomers
>> >> >
>> >> > dynamic – e.g. execute("all customers");
>> >> >
>> >> >
>> >> >
>> >> > For application level service – it is the sample *
>> >> > sample-StoredProcedureService.jar* or what Luciano is providing in
>> >> more
>> >> > details, is an example. In *sample-StoredProcedureService.jar*
>> >> example
>> >> > dynamic approach is followed
>> >> >
>> >> >
>> >> >
>> >> > For container approach – again static or dynamic approach can be
>> >> > followed.
>> >> > For static – it's like providing service for getAllCompanies(),
>> >> > getAllCustomers() etc. whereas for dynamic its like
>> execute(command)
>> >> > where
>> >> > command can be "getAllCompanies", "getAllCustomers". Etc.
>> >> >
>> >> >
>> >> >
>> >> > I am working on a container implementation where dynamic
>> >> > approach is followed.
>> >> >
>> >> If I understand correctly, the container approach will provide the
>> >> tightest integration with SCA and make things easier for
>> end-users. Do
>> >> you agree?
>> >>
>> >> >
>> >> >
>> >> > There are 2 places where extensibility is required –
>> >> >
>> >> > 1) for providing different data access mechanisms. i.e. today
>> >> > there is
>> >> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
>> >> > scdl will
>> >> > be same, but the exampleconfig.xml will change.
>> >> >
>> >> > In the container I am working on - Scdl has a new tag
>> >> >
>> >> > Scdl has a new tag
>> >> > <da:implementation.da script="customersOrders/CustomersOrders.xml"
>> >> > dataAccessType="rdb"/>
>> >> >
>> >> >
>> >> >
>> >> > Here, dataAccessType – is the key which tells whether it's RDB or
>> >> > something
>> >> > else. And the xml script provides the connection and data store
>> >> details.
>> >> >
>> >> >
>> >> >
>> >> > 2) for RDB-DAS – providing support for different databases
>> (this
>> >> > portion should be part of DAS and not SCA.) In the current
>> container
>> >> > I am
>> >> > working on it is provided as a package -
>> >> > org.apache.tuscany.container.dataaccessshelper package - which
>> should
>> >> > finally go into DAS codeline(?).
>> >> >
>> >> >
>> >> Currently, there are two ways to specify a particular database:
>> first,
>> >> the user can pass a JDBC Connection to the DAS Factory when
>> creating a
>> >> DAS instance. The second is that a DataSource can be specified in
>> the
>> >> DAS Config xml file in which case the DAS is responsible for getting
>> the
>> >> connection.
>> >>
>> >> >
>> >> >
>> >> >
>> >> > For static approach we may need some code generation tooling.
>> >>
>> >> Right. That is why I think it best to start with dynamic. But, we
>> will
>> >> want static support as well.
>> >>
>> >> > Also could not
>> >> > understand how this can be merged into RESTful interfaces. (this
>> was
>> >> > mentioned in some mail conversation)
>> >> >
>> >> >
>> >> >
>> >> > Regards,
>> >> >
>> >> > Amita
>> >> >
>> >> >
>> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >
>> >> >>
>> >> >> Luciano Resende wrote:
>> >> >>
>> >> >> > Comments in-line...
>> >> >> >
>> >> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
>> >> >> >>
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > I would also like to understand this a little better ... here
>> >> I am
>> >> >> >> > thinking
>> >> >> >> > aloud and hope the others will help in getting my
>> persceptions
>> >> >> >> > right...
>> >> >> >> >
>> >> >> >> > I guess firstly it is a question of how or where we want to
>> >> >> >> > position 'DAS
>> >> >> >> > Integration' in SCA. Is is something we want to integrate as
>> >> the
>> >> >> >> > Application Layer, which I understand is what Amita is trying
>> >> >> >> > presently and
>> >> >> >> > which Jim refers to as component implementation. In this
>> >> option
>> >> >> >> > we get to
>> >> >> >> > do some sort of a service wrapper to DAS and then it
>> becomes a
>> >> >> >> > demonstration
>> >> >> >> > of two Tuscany subprojects integrating at application level.
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Yes, I think we have space to position DAS both ways, and
>> >> integrating
>> >> >> > in the
>> >> >> > application layer by exposing DAS as a service would be a very
>> easy
>> >> >> and
>> >> >> > quick, this could be exposed as a sample app, and could show we
>> are
>> >> >> > working
>> >> >> > on getting a better integration between DAS and SCA
>> >> >> >
>> >> >> >
>> >> >> >> Or do we want to position DAS at the infrastructure layer as
>> >> another
>> >> >> >> > extension type (either container or binding). I guess
>> this is
>> >> >> >> > where Ant
>> >> >> >> > started this - proposing a JDBC container / binding for
>> >> component
>> >> >> >> > implementation in StoredProcedures.
>> >> >> >> I was thinking a DAS was a way to declaratively model
>> >> heterogeneous
>> >> >> >> data as a service and offer a mechanism for remoting that data.
>> In
>> >> >> >> other words, it provided the ability for an application to
>> perform
>> >> >> >> CRUD using a high-level contract (interface) and having those
>> >> >> >> operations take place across a service network. How this is
>> >> hooked
>> >> >> >> into the SCA container is probably best done as an extension
>> type,
>> >> >> >> i.e. someone could specify:
>> >> >> >>
>> >> >> >> <component name="Foo">
>> >> >> >> <implementation.das>
>> >> >> >> <interface.java ....>
>> >> >> >> </implementation.das>
>> >> >> >> </component>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Yes, this goes back to the way I was thinking on my original
>> >> proposal.
>> >> >> >
>> >> >> >
>> >> >> >> If this is the path we should take
>> >> >> >> > then we probably have to think beyond DAS - to something more
>> >> >> >> > general - of
>> >> >> >> > which DAS is just a special case. I suppose this is what Jim
>> >> has
>> >> >> also
>> >> >> >> > suggested in trying to explore other persistence mechanisms.
>> >> >> >> >
>> >> >> >> This may be the crux of the confusion. I was thinking DAS
>> >> provides a
>> >> >> >> general mechanism for accessing heterogeneous data and is only
>> >> right
>> >> >> >> now tied to SQL because of resource constraints (i.e. we
>> have to
>> >> >> >> start somewhere). Ultimately, DAS should provide the
>> >> infrastructure
>> >> >> >> for dealing with multiple, varied data stores and mechanisms
>> for
>> >> >> >> querying across them. In other words, I guess I am saying DAS
>> >> should
>> >> >> >> be the general solution (declarative and heterogeneous) since
>> >> if it
>> >> >> >> is only a programmatic way to access relational data then its
>> >> value
>> >> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Yes, the current status of DAS implementation is RDB only. I
>> would
>> >> say
>> >> >> > that,
>> >> >> > in the future, I'd like to see a heterogeneous DAS that would
>> give
>> >> you
>> >> >> > access to different data stores, and probably support non-SDO
>> types
>> >> as
>> >> >> > well.
>> >> >> >
>> >> >> >> I too feel that this is something that must be done as an
>> >> extension
>> >> >> >> > type -
>> >> >> >> > but yet to get my hands on the general scheme of things that
>> DAS
>> >> >> >> > can slip
>> >> >> >> > into. Infact the other thread where Jeremy has taken
>> forward a
>> >> >> >> > proposal to
>> >> >> >> > the specs group on resources tempts me to think that there is
>> >> going
>> >> >> >> > to be
>> >> >> >> > something in that which we can leverage from.
>> >> >> >> >
>> >> >> >> I think resources are orthogonal as they are about a component
>> >> >> >> implementation's contract with its container. Declarative data
>> >> >> >> services on the other hand are about application constructs
>> >> that can
>> >> >> >> be wired to.
>> >> >> >>
>> >> >> >> > I hope to get a better understanding this as we go along in
>> this
>> >> >> >> > thread :)
>> >> >> >> >
>> >> >> >> Me too :-) As soon as I have trouble explaining technologies to
>> >> .NET
>> >> >> >> people and they say "you Unix/Java people are at it again
>> with a
>> >> >> >> thousand ways to do the same exact thing" it causes me to think
>> >> that
>> >> >> >> maybe we need to clarify our message.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > If we all think it would be useful, I could try to summarize the
>> >> >> > thread on
>> >> >> > the wiki with a more clean proposal incorporating all your
>> >> feedback ,
>> >> >> > what
>> >> >> > you guys think ?
>> >> >>
>> >> >> Yes. Great idea.
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > Jim
>> >> >> >
>> >> >> >> > Thanks
>> >> >> >> >
>> >> >> >> > - Venkat
>> >> >> >> >
>> >> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >> >>
>> >> >> >> >> Jim Marino wrote:
>> >> >> >> >>
>> >> >> >> >> > When I first read the thread on this, I thought the DAS
>> >> service
>> >> >> >> >> would
>> >> >> >> >> > be a component extension type (e.g. analogous to a
>> >> >> >> >> > implementation.java or implementation.ejb) and not a
>> >> component
>> >> >> >> >> > implementation type, which would allow for dynamic and
>> >> >> eventually
>> >> >> >> >> > declarative configuration styles.
>> >> >> >> >>
>> >> >> >> >> I have not very familiar with the terminology so I am not
>> sure
>> >> >> what
>> >> >> a
>> >> >> >> >> "component extension type" is. But, I do think we
>> eventually
>> >> want
>> >> >> >> >> "implementation.rdbdas". Wouldn't this be a new
>> implementation
>> >> >> type?
>> >> >> >> >>
>> >> >> >> >> It looks like Amita chose to start with a POJO. I notice
>> >> the use
>> >> >> >> >> of "
>> >> >> >> >> implementation.java".
>> >> >> >> >>
>> >> >> >> >> > Either way, though, I am curious as to why
>> >> >> >> >> >
>> >> >> >> >> > public DAS configureService(String configFile);
>> >> >> >> >> >
>> >> >> >> >> > exists as part of the service definition? If the DAS
>> service
>> >> >> was a
>> >> >> >> >> > component extension type, it could be handled as part
>> of the
>> >> >> >> >> > application bootstrap. If the DAS service was a component
>> >> >> >> >> > implementation type, the configuration file URI could be
>> >> passed
>> >> >> >> >> in as
>> >> >> >> >> > a property and then processed in an initializer method
>> >> decorated
>> >> >> by
>> >> >> >> >> > the SCA @Init annotation. In the latter case, if the
>> >> >> implementation
>> >> >> >> >> > of DASService thread-safe (hopefully it is since
>> >> configuration
>> >> >> >> >> would
>> >> >> >> >> > seem to be a heavyweight operation), then I would make the
>> >> >> >> >> component
>> >> >> >> >> > module scoped to avoid initialization overhead on every
>> >> >> resolution.
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > In both approaches (extension vs. implementation type),
>> >> having
>> >> >> >> >> > configuration exposed to the application doesn't quite
>> feel
>> >> >> right,
>> >> >> >> >> > since that is what DI tries to externalize.
>> >> >> >> >>
>> >> >> >> >> I agree. The configuration should be part of the
>> >> >> initialization and
>> >> >> >> >> should use SCA patterns to do this. I think that Amita
>> meant
>> >> >> to use
>> >> >> >> >> eventually use a component property for the DAS config info
>> but
>> >> >> >> >> started
>> >> >> >> >> with a method.
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > Also, I was thinking that in having this a component
>> >> extension
>> >> >> >> >> type,
>> >> >> >> >> > the service interfaces returned from a resolution could
>> >> include
>> >> >> the
>> >> >> >> >> > dynamic one described below or static ones people have
>> >> >> mentioned.
>> >> >> I
>> >> >> >> >> > guess it is best to start with the easier-to-implement
>> part
>> >> >> >> >> first and
>> >> >> >> >> > support the dynamic interface.
>> >> >> >> >> >
>> >> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be
>> >> nice to
>> >> >> >> >> > understand what DAS provides in relation to other
>> persistence
>> >> >> >> >> > technologies. Outside of the Java world, Microsoft is
>> >> promoting
>> >> >> >> >> LINQ
>> >> >> >> >> > which is really interesting, and it would be
>> informative to
>> >> >> compare
>> >> >> >> >> > the goals of DAS with that approach (there are obvious
>> >> >> differences
>> >> >> >> >> > such as having the query language a strongly-typed part of
>> >> the
>> >> >> >> >> > programming language, e.g. C#, and LINQ's use of
>> closures).
>> >> >> >> >> >
>> >> >> >> >> > In contrasting DAS to O-R technologies, I see the primary
>> use
>> >> >> cases
>> >> >> >> >> > for the former being a quick way to issue a query that may
>> be
>> >> >> >> >> > executed against *heterogeneous* data stores and have that
>> >> data
>> >> >> >> >> flow
>> >> >> >> >> > remotely or to a client that is not necessarily
>> >> Java-based. One
>> >> >> key
>> >> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
>> >> >> >> >> (Hibernate
>> >> >> >> >> > and JPA are about as easy):
>> >> >> >> >> >
>> >> >> >> >> IMO the primary use case for DAS is an application that is
>> SDO-
>> >> >> >> >> centric
>> >> >> >> >> and is taking advantage of its disconnected
>> capabilities. The
>> >> RDB
>> >> >> >> >> DAS
>> >> >> >> >> is built to work with SDO and uses the change summary to
>> drive
>> >> >> >> >> changes
>> >> >> >> >> made to a disconnected data graph back to some store.
>> This is
>> >> not
>> >> >> to
>> >> >> >> >> say that a relational DAS could not be built on top of
>> JPA, in
>> >> >> fact,
>> >> >> >> >> this might be a very useful thing to do. The implementation
>> we
>> >> >> >> >> currently have provides a very straightforward implicit
>> mapping
>> >> >> from
>> >> >> >> >> DataObjects to Tables. If more capable mapping is needed
>> >> then it
>> >> >> >> >> makes
>> >> >> >> >> sense to use the JPA-defined technology and artifacts. A
>> >> modified
>> >> >> >> >> Entity manager might be needed to take advantage of SDO's
>> >> change
>> >> >> >> >> summary.
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > public interface CustomerDao extends BaseQuery {
>> >> >> >> >> > @Select("select * from customers where city = ?1")
>> >> >> >> >> > DataSet<Customer> findCustomersFrom(String city);
>> >> >> >> >> > }
>> >> >> >> >> >
>> >> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
>> >> >> >> >> > (CustomerDao.class, datasource);
>> >> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > The other key is remote data and change lists. I think
>> there
>> >> >> are
>> >> >> >> >> > (literally) about a thousand ways that already exist to
>> >> >> handle the
>> >> >> >> >> > "local" data case. For change lists, interop with
>> ADO.NET's
>> >> >> change
>> >> >> >> >> > summary facilities would be interesting.
>> >> >> >> >>
>> >> >> >> >> I agree. Also, it looks like Xcalia may have a similar
>> >> thought:
>> >> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think
>> >> it is
>> >> >> >> >> > important we have a clear statement as to when it is
>> >> appropriate
>> >> >> >> >> and
>> >> >> >> >> > not appropriate to use. One place to start would be to
>> >> compare
>> >> >> >> >> it to
>> >> >> >> >> > JDBC 4 and JPA.
>> >> >> >> >>
>> >> >> >> >> We can get started with JPA:
>> >> >> >> >>
>> >> >> >> >> * JPA is java-specific, container-based, built around a
>> >> >> connected
>> >> >> >> >> data model and offers a complete O/R mapping for POJOs
>> >> >> >> >>
>> >> >> >> >> * The RDB DAS is a java implementation of a language -
>> >> neutral
>> >> >> >> >> concept (hopefully specified some day) that is
>> >> >> containerless,
>> >> >> >> >> assumes a disconnected data model and provides a
>> simple,
>> >> >> >> >> implicit
>> >> >> >> >> mapping for SDO DataObjects (Dynamic or Static) to
>> >> >> relational
>> >> >> >> >> tables.
>> >> >> >> >>
>> >> >> >> >> Anything else?
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > Jim
>> >> >> >> >> >
>> >> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>> >> >> >> >> >
>> >> >> >> >> >> Hi Amita
>> >> >> >> >> >>
>> >> >> >> >> >> I think we were both going on the same way, with the DAS
>> >> >> Service
>> >> >> >> >> >> sample,
>> >> >> >> >> >> altough i had the interface more like this, to be more
>> >> >> flexible :
>> >> >> >> >> >>
>> >> >> >> >> >> public interface DASService {
>> >> >> >> >> >>
>> >> >> >> >> >> public DAS configureService(String configFile);
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >> public DataObject executeCommand(String commandName);
>> >> >> >> >> >> public DataObject execute(String newCommand);
>> >> >> >> >> >> public void applyChanges(DataObject graphRoot);
>> >> >> >> >> >> }
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> As for having it as a sample, maybe we could defined the
>> >> >> >> >> DASService
>> >> >> >> >> >> as one
>> >> >> >> >> >> sample itself, and have a second version of companyWeb
>> that
>> >> >> would
>> >> >> >> >> >> consume
>> >> >> >> >> >> the service, something like :
>> >> >> >> >> >>
>> >> >> >> >> >> das\samples\companyWeb
>> >> >> >> >> >> das\samples\dasService
>> >> >> >> >> >> das\samples.companyWeb.service
>> >> >> >> >> >>
>> >> >> >> >> >> or, more like BigBank
>> >> >> >> >> >>
>> >> >> >> >> >> das\samples\companyweb.Service\dasService
>> >> >> >> >> >> das\samples\companyweb.Service\webClient
>> >> >> >> >> >>
>> >> >> >> >> >> Or even in sampleApps...
>> >> >> >> >> >>
>> >> >> >> >> >> Toughts ?
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
>> >> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >>>
>> >> >> >> >> >>> Hi ,
>> >> >> >> >> >>> I am also following up another thread
>> >> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> >> msg09944.html
>> >> >> >> >> >>> on the
>> >> >> >> >> >>> similar issue (JDBC stored procedure container
>> >> >> >> >> >>> using DAS)
>> >> >> >> >> >>> Besides the fact that I am actively working on the
>> >> container
>> >> >> >> >> work,
>> >> >> >> >> >>> I also
>> >> >> >> >> >>> have tried to
>> >> >> >> >> >>> develop a sample based on the below discussion,
>> following
>> >> >> dynamic
>> >> >> >> >> >>> approach.
>> >> >> >> >> >>>
>> >> >> >> >> >>> I am attaching the same here. Please take a look and
>> give
>> >> your
>> >> >> >> >> >>> suggestions.
>> >> >> >> >> >>> In this, StoredProcedureService implementation has
>> >> >> >> >> setConfigInfo (DAS
>> >> >> >> >> >>> Config) and
>> >> >> >> >> >>> execute(Any SQL). This can be made more complete with
>> >> >> >> >> executeSQL(),
>> >> >> >> >> >>> applyChanges()
>> >> >> >> >> >>> etc.
>> >> >> >> >> >>>
>> >> >> >> >> >>> Can this be added to the existing set of samples?
>> >> >> >> >> >>>
>> >> >> >> >> >>> Regards,
>> >> >> >> >> >>> Amita
>> >> >> >> >> >>>
>> >> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > Luciano Resende wrote:
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > Kevin, from what I understood from your
>> suggestion, it
>> >> was
>> >> >> >> >> >>> looking to
>> >> >> >> >> >>> > me
>> >> >> >> >> >>> > > more like exposing DAS as a service :
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > >>> public interface RDBDASService
>> >> >> >> >> >>> > >>> DataObject execute(String commandName);
>> >> >> >> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
>> >> >> >> >> >>> > >>> void applyChanges(DataObject graphRoot);
>> >> >> >> >> >>> > >>> }
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > Yes, I am talking about exposing a DAS Service
>> configured
>> >> >> >> >> with a
>> >> >> >> >> >>> > specific set of capabilities/commands defined in
>> the DAS
>> >> >> config
>> >> >> >> >> >>> file.
>> >> >> >> >> >>> > So, if the implementation of the service interface
>> above
>> >> was
>> >> >> >> >> >>> configured
>> >> >> >> >> >>> > to work with Customers they would use the service like
>> >> this:
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > List customers = myRDBDASService.execute
>> >> >> ("getAllCustomers");
>> >> >> >> >> >>> > String name = customers.get(0).getString("name");
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > This is not much different than the static
>> interface you
>> >> >> >> >> proposed,
>> >> >> >> >> >>> > right?
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > And then, when a service developer defines the
>> >> >> >> >> AccountService,
>> >> >> >> >> >>> he will
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > have
>> >> >> >> >> >>> > > to know about yet another service, about how DAS
>> works,
>> >> >> >> >> how it is
>> >> >> >> >> >>> > > configured, etc, etc... is that right ?
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > The abilities of the service are defined by the DAS
>> >> config
>> >> >> >> >> file.
>> >> >> >> >> >>> So,
>> >> >> >> >> >>> > the person or tool that provides the config file must
>> >> >> >> >> understand
>> >> >> >> >> >>> how the
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > RDB DAS APIs work. There is no getting around this.
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > My proposal was going more towards allowing the
>> service
>> >> >> >> >> >>> developer to
>> >> >> >> >> >>> > > focus
>> >> >> >> >> >>> > > on defining the service, and let the "declarative
>> >> das" to
>> >> >> >> >> >>> handle the
>> >> >> >> >> >>> > > persistent layer....
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > The DAS config file is the declaration of an
>> instance of
>> >> the
>> >> >> >> >> >>> DAS. That
>> >> >> >> >> >>> > instance can be exposed as a dynamic or typed service/
>> >> >> >> >> interface.
>> >> >> >> >> >>> That
>> >> >> >> >> >>> > seems to be the main discussion we are having.
>> >> Although, I
>> >> >> >> >> may be
>> >> >> >> >> >>> > missing something.
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > Also, by defining some conventions over
>> configuration
>> >> >> >> >> and/or using
>> >> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a
>> >> stored
>> >> >> >> >> >>> procedure),
>> >> >> >> >> >>> > the
>> >> >> >> >> >>> > > service developer could really define a service that
>> >> >> >> >> interacts
>> >> >> >> >> >>> with a
>> >> >> >> >> >>> > > RDB,
>> >> >> >> >> >>> > > without having to code the service persistence
>> layer.
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > There is a lot of potential for the use of
>> annotations.
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > > - Luciano
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net>
>> >> wrote:
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> The real difference between the two approaches is
>> that
>> >> >> >> >> one is
>> >> >> >> >> >>> "Typed"
>> >> >> >> >> >>> > or
>> >> >> >> >> >>> > >> static and the other is dynamic. I think both are
>> >> needed
>> >> >> >> >> but was
>> >> >> >> >> >>> > >> suggesting that we start with dynamic since it
>> is the
>> >> >> most
>> >> >> >> >> >>> flexible
>> >> >> >> >> >>> > and
>> >> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a
>> >> static
>> >> >> >> >> >>> capability.
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> With either, the user does not need to know about
>> >> >> >> >> traditional
>> >> >> >> >> >>> > >> persistence frameworks. With the dynamic approach,
>> >> >> however,
>> >> >> >> >> >>> the user
>> >> >> >> >> >>> > >> does need to know about the dynamic SDO API.
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> So, with the static interface the user might write:
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> List customers = accountService.getAllCustomers
>> ();
>> >> >> >> >> >>> > >> String name =
>> >> ((Customer)customers.get(0)).getName();
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> The equivalent dynamic API might be:
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> List customers =
>> >> >> dasService.execute("getAllCustomers");
>> >> >> >> >> >>> > >> String name =
>> >> >> ((DataObject)customers.get(0)).getString
>> >> >> >> >> >>> ("name");
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> The first is probably a little easier for the
>> >> application
>> >> >> >> >> >>> developer
>> >> >> >> >> >>> > but
>> >> >> >> >> >>> > >> the second is much easier for the service
>> developer.
>> >> IMO,
>> >> >> >> >> the
>> >> >> >> >> >>> dynamic
>> >> >> >> >> >>> > >> case is the best place to start and, again, we
>> >> >> >> >> definitely will
>> >> >> >> >> >>> want
>> >> >> >> >> >>> > >> support for both.
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> Thanks.
>> >> >> >> >> >>> > >> --
>> >> >> >> >> >>> > >> Kevin
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> Jeremy Boynes wrote:
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> > I think this would be useful but it seems more
>> >> like a
>> >> >> >> >> >>> traditional
>> >> >> >> >> >>> > >> > persistence API than what Luciano was suggesting.
>> >> With
>> >> >> >> >> this
>> >> >> >> >> >>> one a
>> >> >> >> >> >>> > >> > user needs to know about DataObject's, commands,
>> SQL
>> >> >> >> >> strings
>> >> >> >> >> >>> etc.
>> >> >> >> >> >>> > >> > just like they would if they were using raw
>> JDBC or
>> >> >> JPA.
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more
>> >> about
>> >> >> >> >> >>> expressing
>> >> >> >> >> >>> > >> > high-level CRUD operations as operations on a
>> >> service
>> >> >> >> >> >>> interface:
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> public List getAllCustomers();
>> >> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
>> >> >> >> >> accountNumber);
>> >> >> >> >> >>> > >> >>> }
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > which is all application level concepts rather
>> >> >> >> >> than persistence
>> >> >> >> >> >>> > level
>> >> >> >> >> >>> > >> > concepts. I'd actually go a little further and
>> put
>> >> that
>> >> >> >> >> >>> right into
>> >> >> >> >> >>> > >> > the service contract:
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > public interface AccountService {
>> >> >> >> >> >>> > >> > List<Customer> getAllCustomers();
>> >> >> >> >> >>> > >> > Account getCustomerAccount(String
>> >> accountNumber);
>> >> >> >> >> >>> > >> > }
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
>> >> >> >> >> standardized
>> >> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
>> >> >> configuration
>> >> >> >> >> >>> would be
>> >> >> >> >> >>> > >> > needed except to add this to the logical
>> assembly:
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > <component name="AccountStore">
>> >> >> >> >> >>> > >> > <implementation.das
>> resource="MySQLDatabase"/>
>> >> >> >> >> >>> > >> > </component>
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > With SCA's ability to translate service
>> contracts,
>> >> this
>> >> >> >> >> >>> should be
>> >> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
>> >> >> >> >> regardless of
>> >> >> >> >> >>> > whether
>> >> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by
>> IIOP or
>> >> >> >> >> running on
>> >> >> >> >> a
>> >> >> >> >> >>> > Java,
>> >> >> >> >> >>> > >> > C++ or PHP platform.
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > The important thing here is that the client is
>> >> >> >> >> isolated from
>> >> >> >> >> >>> how
>> >> >> >> >> >>> > the
>> >> >> >> >> >>> > >> > DAS component is provided. We could have multiple
>> >> >> >> >> declarative
>> >> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and one
>> >> that
>> >> >> did
>> >> >> >> >> >>> stuff
>> >> >> >> >> >>> > with
>> >> >> >> >> >>> > >> > XML databases like Xindice; alternatively,
>> /without
>> >> >> >> >> altering
>> >> >> >> >> >>> the
>> >> >> >> >> >>> > >> > client at all/ they could switch to a custom
>> coded
>> >> >> version
>> >> >> >> >> >>> written
>> >> >> >> >> >>> > in
>> >> >> >> >> >>> > >> > Java, C++ or a store procedure language like
>> PL/SQL.
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > --
>> >> >> >> >> >>> > >> > Jeremy
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams
>> wrote:
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >> 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 code
>> >> specific to
>> >> >> >> >> a new
>> >> >> >> >> >>> > >> >> service. Instead, the service will be
>> >> "instantiated"
>> >> >> >> >> based
>> >> >> >> >> >>> on the
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >> >> provided DAS config file. The service interface
>> >> >> >> >> might look
>> >> >> >> >> >>> like
>> >> >> >> >> >>> > >> this:
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> public interface RDBDASService
>> >> >> >> >> >>> > >> >> DataObject execute(String commandName);
>> >> >> >> >> >>> > >> >> DataObject executeSQL(String
>> abitrarySQL);
>> >> >> >> >> >>> > >> >> void applyChanges(DataObject graphRoot);
>> >> >> >> >> >>> > >> >> }
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> So, depending on the config file used to
>> >> >> instantiate the
>> >> >> >> >> >>> service,
>> >> >> >> >> >>> > >> >> this interface could be used to return
>> Customers/
>> >> >> >> >> Accounts or
>> >> >> >> >> >>> > >> >> Toasters. In fact, a lot could be achieved with
>> no
>> >> >> >> >> >>> > configuration at
>> >> >> >> >> >>> > >> >> all by restricting use to: DataObject
>> >> >> executeSQL(String
>> >> >> >> >> >>> > >> abitrarySQL);
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> I expand a bit here:
>> >> http://mail-archives.apache.org/
>> >> >> >> >> >>> mod_mbox/ws-
>> >> >> >> >> >>> > >> >>
>> >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> Once this was working it should be
>> >> straightforward to
>> >> >> >> >> build
>> >> >> >> >> >>> more
>> >> >> >> >> >>> > >> >> strongly typed services and possible put
>> together
>> >> some
>> >> >> >> >> >>> generation
>> >> >> >> >> >>> > >> >> tooling. We could also start looking at support
>> >> for
>> >> a
>> >> >> >> >> more
>> >> >> >> >> >>> > RESTFul
>> >> >> >> >> >>> > >> >> interface.
>> >> >> >> >> >>> > >> >> --
>> >> >> >> >> >>> > >> >> Kevin
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> Luciano Resende wrote:
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>> Recently, people have been starting to talk
>> about
>> >> >> >> >> better DAS
>> >> >> >> >> >>> > >> >>> integration
>> >> >> >> >> >>> > >> >>> with DAS, and below are some threads on the
>> >> subject
>> >> :
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> >> msg08833.html
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> >> msg08923.html
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >>
>> >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> >> >> >> >> >>> msg09715.html
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make
>> >> sure
>> >> >> >> >> what I'm
>> >> >> >> >> >>> > >> >>> saying is not
>> >> >> >> >> >>> > >> >>> yet available on SCA today.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Today, defining a service to work with a
>> >> relational
>> >> >> >> >> >>> database, you
>> >> >> >> >> >>> > >> >>> will need
>> >> >> >> >> >>> > >> >>> to code the persistence side of the service
>> where
>> >> >> CRUD
>> >> >> >> >> >>> operations
>> >> >> >> >> >>> > >> >>> to the
>> >> >> >> >> >>> > >> >>> database will be done.
>> >> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
>> >> coding
>> >> >> >> >> the
>> >> >> >> >> >>> CRUD
>> >> >> >> >> >>> > >> >>> operations on
>> >> >> >> >> >>> > >> >>> the persistence layer would be avoided as
>> much as
>> >> >> >> >> possible.
>> >> >> >> >> >>> > >> >>> The idea would be to have a more "declarative
>> DAS"
>> >> >> when
>> >> >> >> >> >>> defining
>> >> >> >> >> >>> > SCA
>> >> >> >> >> >>> > >> >>> Services, so you would either use some
>> Annotations
>> >> >> >> >> or SCDL
>> >> >> >> >> to
>> >> >> >> >> >>> > >> have the
>> >> >> >> >> >>> > >> >>> "declarative DAS" configuration inside it.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> I was thinking on something like....
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> SCDL Definition would look something like
>> this :
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> <component name="AccountDataService">
>> >> >> >> >> >>> > >> >>> <interface.java
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> class="bigbank.account.services.account.AccountService"/>
>> >> >> >> >> >>> > >> >>> <implementation.das="dasConfig.properties"
>> >> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> >> >> >> >> >>> > >> >>> </component>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> The AccountService Interface would look like
>> this
>> >> >> >> >> (missing
>> >> >> >> >> >>> any
>> >> >> >> >> >>> > SCA
>> >> >> >> >> >>> > >> >>> annotations):
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> public List getAllCustomers();
>> >> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
>> >> >> >> >> accountNumber);
>> >> >> >> >> >>> > >> >>> }
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> The DAS config would look like this, and would
>> >> >> have the
>> >> >> >> >> >>> > definition
>> >> >> >> >> >>> > >> >>> for the
>> >> >> >> >> >>> > >> >>> "all companies" command.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> <Config ...>
>> >> >> >> >> >>> > >> >>> ...
>> >> >> >> >> >>> > >> >>> <ConnectionInfo
>> dataSource="java:comp/env/jdbc/
>> >> >> >> >> bigbank"/>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select *
>> >> from
>> >> >> >> >> >>> CUSTOMERS"
>> >> >> >> >> >>> > >> >>> kind="Select"/>
>> >> >> >> >> >>> > >> >>> <Command name="getCustomerAccount"
>> SQL="SELECT
>> >> >> >> >> >>> accountNumber,
>> >> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
>> >> >> >> >> accountNumber = ?"
>> >> >> >> >> >>> > >> >>> kind="Select" />
>> >> >> >> >> >>> > >> >>> ...
>> >> >> >> >> >>> > >> >>> </Config>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Mapping between interface methods and DAS
>> Commands
>> >> >> >> >> >>> > >> >>> - If a DAS config file is provided, based on
>> the
>> >> >> >> >> >>> > SCDL definition,
>> >> >> >> >> >>> > >> we
>> >> >> >> >> >>> > >> >>> would look for "DAS command" based on the
>> name of
>> >> the
>> >> >> >> >> getter
>> >> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to
>> getAllCustomers
>> >> >> >> >> command)
>> >> >> >> >> >>> > >> >>> - Otherwise, we would try to do a map
>> >> directly to
>> >> a
>> >> >> >> >> >>> > >> stored procedure
>> >> >> >> >> >>> > >> >>> - We could also have a way to force the
>> >> mapping by
>> >> >> >> >> using
>> >> >> >> >> >>> > >> annotation
>> >> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Mapping between method parameter and command
>> >> >> parameter
>> >> >> >> >> >>> > >> >>> - We would need to define a method for
>> >> mapping the
>> >> >> >> >> method
>> >> >> >> >> >>> > >> >>> parameters to
>> >> >> >> >> >>> > >> >>> the query paramters either based on position (
>> >> >> e.gfirst
>> >> >> >> >> >>> method
>> >> >> >> >> >>> > >> >>> parameter
>> >> >> >> >> >>> > >> >>> maps to the first command paramter), or we
>> >> would do
>> >> >> some
>> >> >> >> >> >>> > mapping by
>> >> >> >> >> >>> > >> >>> name
>> >> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Note:
>> >> >> >> >> >>> > >> >>> - A SCDL connection information would
>> >> override the
>> >> >> DAS
>> >> >> >> >> >>> Config
>> >> >> >> >> >>> > file
>> >> >> >> >> >>> > >> >>> connection information.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Benefits
>> >> >> >> >> >>> > >> >>> - It's All about simplicity and easy of use
>> >> >> >> >> >>> > >> >>> - This would allow a user to define a service
>> >> >> without
>> >> >> >> >> >>> having to
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >> >>> explicitly having to code any Data Access
>> related
>> >> >> code.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Implementation approaches
>> >> >> >> >> >>> > >> >>> - Utilizing DAS : This approach would start
>> from
>> >> >> the
>> >> >> >> >> >>> current
>> >> >> >> >> >>> > >> >>> Tuscany DAS
>> >> >> >> >> >>> > >> >>> implementation, where functionality would be
>> >> already
>> >> >> >> >> >>> > available, but
>> >> >> >> >> >>> > >> >>> the
>> >> >> >> >> >>> > >> >>> service implementation would be tied to SDO and
>> >> RDB
>> >> >> >> >> as this
>> >> >> >> >> >>> > is what
>> >> >> >> >> >>> > >> >>> DAS
>> >> >> >> >> >>> > >> >>> supports today.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> - Start simple and grow : We could start
>> simple,
>> >> by
>> >> >> >> >> >>> having a
>> >> >> >> >> >>> > >> simple
>> >> >> >> >> >>> > >> >>> implementation based on JDBC and would return
>> some
>> >> >> >> >> simple
>> >> >> >> >> >>> > >> >>> collection as a
>> >> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset),
>> this
>> >> >> could
>> >> >> >> >> >>> give us
>> >> >> >> >> >>> > a
>> >> >> >> >> >>> > >> >>> quick
>> >> >> >> >> >>> > >> >>> start to flush implementation details and get a
>> >> >> proven
>> >> >> >> >> >>> design,
>> >> >> >> >> >>> > and
>> >> >> >> >> >>> > >> >>> this
>> >> >> >> >> >>> > >> >>> could get evolved to use a DAS that would
>> support
>> >> >> >> >> multiple
>> >> >> >> >> >>> > backends
>> >> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well
>> as
>> >> >> >> >> non- SDO
>> >> >> >> >> >>> types
>> >> >> >> >> >>> > >> as a
>> >> >> >> >> >>> > >> >>> command
>> >> >> >> >> >>> > >> >>> result.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Toughts ?
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> - Luciano
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
>> >> >> wrote:
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> 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. Another thing we want to
>> >> eventually
>> >> >> >> >> >>> explore is
>> >> >> >> >> >>> > >> >>>> exposing
>> >> >> >> >> >>> > >> >>>> a DAS as REST-oriented services. As we have
>> seen
>> >> >> >> >> from the
>> >> >> >> >> >>> > parent
>> >> >> >> >> >>> > >> >>>> thread
>> >> >> >> >> >>> > >> >>>> there are almost too many possible approaches.
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a
>> service
>> >> >> and
>> >> >> >> >> >>> create a
>> >> >> >> >> >>> > new
>> >> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas
>> ). The
>> >> >> main
>> >> >> >> >> >>> reason
>> >> >> >> >> >>> > has
>> >> >> >> >> >>> > >> >>>> to do
>> >> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS
>> that
>> >> >> >> >> >>> > Jeremy mentioned
>> >> >> >> >> >>> > >> >>>> which
>> >> >> >> >> >>> > >> >>>> is all about creating data access services
>> >> >> >> >> >>> declaratively. A new
>> >> >> >> >> >>> > >> >>>> component type and a service that we build by
>> >> hand
>> >> >> >> >> would be
>> >> >> >> >> >>> > a good
>> >> >> >> >> >>> > >> >>>> step
>> >> >> >> >> >>> > >> >>>> in this direction.
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
>> >> >> >> >> interface like
>> >> >> >> >> >>> > this:
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> public interface RDBDASService
>> >> >> >> >> >>> > >> >>>> void applyChanges(DataObject
>> graphRoot);
>> >> >> >> >> >>> > >> >>>> DataObject execute(String
>> commandName);
>> >> >> >> >> >>> > >> >>>> DataObject executeSQL(String
>> >> abitrarySQL);
>> >> >> >> >> >>> > >> >>>> }
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> The service would be initialized with an
>> optional
>> >> >> >> >> RDB DAS
>> >> >> >> >> >>> > >> config file
>> >> >> >> >> >>> > >> >>>> that defines connection properties, a set of
>> >> >> commands,
>> >> >> >> >> >>> etc. So,
>> >> >> >> >> >>> > >> >>>> different services implementing the same
>> >> interface
>> >> >> >> >> could be
>> >> >> >> >> >>> > >> >>>> initialized
>> >> >> >> >> >>> > >> >>>> from separate config files.
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> Eventually, we might want to build services
>> like
>> >> >> this:
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> public interface Customers_RDBDASService
>> >> >> >> >> >>> > >> >>>> void applyChanges(DataObject
>> graphRoot);
>> >> >> >> >> >>> > >> >>>> DataObject getAllCustomersWithLastName
>> >> >> (String
>> >> >> >> >> >>> > lastName);
>> >> >> >> >> >>> > >> >>>> DataObject getAll
>> CustomersAndOrdersForID
>> >> >> (int
>> >> >> >> >> >>> > customerId);
>> >> >> >> >> >>> > >> >>>> }
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> But, for this to be very useful would probably
>> >> >> require
>> >> >> >> >> >>> some code
>> >> >> >> >> >>> > >> >>>> generation tooling.
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> Thoughts?
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> --Kevin
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> Luciano Resende wrote:
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
>> >> >> >> >> declarative
>> >> >> >> >> >>> > DAS and
>> >> >> >> >> >>> > >> >>>> will be
>> >> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki
>> >> soon...
>> >> >> >> >> >>> > >> >>>> >
>> >> >> >> >> >>> > >> >>>> > - Luciano
>> >> >> >> >> >>> > >> >>>> >
>> >> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes
>> <jb...@apache.org>
>> >> >> >> >> 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 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.
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
>> >> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I
>> >> think we
>> >> >> >> >> >>> > should welcome
>> >> >> >> >> >>> > >> it
>> >> >> >> >> >>> > >> >>>> >> like we would any other contribution.
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >> >> 3) to access data through an application
>> >> >> >> >> service with
>> >> >> >> >> >>> > >> >>>> declarative
>> >> >> >> >> >>> > >> >>>> >> >> implementation by DAS
>> >> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks
>> >> radar.
>> >> >> >> >> >>> > >> >>>> >> --
>> >> >> >> >> >>> > >> >>>> >> Jeremy
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> --------------------------------------------------------------------
>> >> >> >> >> >>> > >> -
>> >> >> >> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> >> >>> unsubscribe@ws.apache.org
>> >> >> >> >> >>> > >> >>>> >> For additional commands, e-mail:
>> >> >> >> >> >>> > tuscany-dev-help@ws.apache.org
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> --------------------------------------------------------------------
>> >> >> >> >> >>> > >> -
>> >> >> >> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> >> >>> unsubscribe@ws.apache.org
>> >> >> >> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
>> >> >> >> >> >>> help@ws.apache.org
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> >
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> >> unsubscribe@ws.apache.org
>> >> >> >> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
>> >> >> >> >> >>> help@ws.apache.org
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> >
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> >> unsubscribe@ws.apache.org
>> >> >> >> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
>> >> >> >> >> help@ws.apache.org
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> >> unsubscribe@ws.apache.org
>> >> >> >> >> >>> > >> For additional commands, e-mail: tuscany-dev-
>> >> >> >> >> help@ws.apache.org
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> >
>> >> >> >> >> >>> >
>> >> >> >> >> >>> >
>> >> >> >> >> >>> >
>> >> >> >> >> >>> >
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> > To unsubscribe, e-mail:
>> >> >> tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> >> >>> > For additional commands, e-mail:
>> >> >> tuscany-dev-help@ws.apache.org
>> >> >> >> >> >>> >
>> >> >> >> >> >>> >
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> To unsubscribe, e-mail:
>> >> tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> >> >>> For additional commands, e-mail:
>> >> >> tuscany-dev-help@ws.apache.org
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> > To unsubscribe, e-mail:
>> tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> >> > For additional commands, e-mail:
>> >> tuscany-dev-help@ws.apache.org
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail:
>> tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> >> For additional commands, e-mail:
>> tuscany-dev-help@ws.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Amita Vadhavkar <am...@gmail.com>.
Hello Kevin , Luciano,
Thanks a lot for all your suggestions and looking forward to have a IRC chat
with you.
I am proposing 9th Nov 5.30 a.m. IST (8th Nov 4.00 p.m. PST) for approx. 1
hr.
Please join the chat and we all can discuss -
1) what we are trying to provide - service, container
2) what all features can be provided
3) any high level design suggestions ( sim. to Kevin's latest reply )
4) any other suggestions
5) we can try to come up with a list of work items
This will be very helpful in getting a clear picture of what all can be done
in SCA (as well as DAS) domain for our current work.
Regards,
Amita
On 11/8/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Hello Amita,
>
> This looks promising. I notice your test case uses explicit updates and
> inserts. While this is supported by the DAS it is not the preferred
> usage which is to allow the RDB DAS to generate the CUD statements from
> the SDO change history. Could you modify the example to read a data
> graph and then post the changes back via "applyChanges"? Maybe the
> equivalent of this simple test from the DAS test suite:
>
> public void testReadModifyApply4() throws Exception {
>
> DAS das = DAS.FACTORY.createDAS(getConfig("CustomerConfig.xml"),
> getConnection());
> // Read customer with particular ID
> Command select = das.getCommand("getCustomer");
> select.setParameter(1, 1);
> DataObject root = select.executeQuery();
>
> DataObject customer = (DataObject) root.get("CUSTOMER[1]");
>
> // Modify customer
> customer.set("LASTNAME", "Pavick");
>
> das.applyChanges(root);
>
> // Verify the change
> root = select.executeQuery();
> assertEquals("Pavick",
> root.getDataObject("CUSTOMER[1]").getString("LASTNAME"));
>
> }
>
> Also, this service interface seems difficult to work with since command
> identifiers and argument values are encoded in the params Vector
>
> public interface CustomersOrdersService {
>
> void execute(Vector params);
> DataObject executeQuery(Vector params);
> void applyChanges(Vector params);
> DataObject executeAdhoc(Vector params);//adhoc query implementation
>
> DataObject getAllCustomers(Vector paramsList);
>
> }
>
> Do you think it possible to implement something like the following
> interface:
>
> public interface DynamicRDBDASService {
>
> DataObject execute(String commandName, List params);
> DataObject executeAdHoc(String queryString, List params);
> void applyChanges();
> }
>
> The name is kind of long (suggestions welcome) but, I think this
> interface could be generic and set of available commands is driven by
> the provided DAS config file. I am not sure how we might support SP OUT
> parameters but we can think about that later.
>
> I does seem like you and Luciano should team up on this.
>
> Thanks!
> --
> Kevin
>
>
>
>
> Amita Vadhavkar wrote:
>
> > Hi Kevin,
> > Thanks a lot for the comments. I have posted the code and doc on
> JIRA-904
> > for the container work. Also, am most likely missing something in the
> > database
> > connection portion. Would like to discuss with you.
> >
> > Will you please provide feedback on JIRA-904 attachments?
> >
> > I am checking with Luciano for a convenient date/time when we can chat,
> > would
> > be great if you can also join. I am in IST timezone.
> >
> > Regards,
> > Amita
> >
> > On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >>
> >> Hi Amita,
> >> This is looking good. Some comments inline:
> >>
> >> Amita Vadhavkar wrote:
> >>
> >> > Hi,
> >> > I am trying to create a container for DAS-SCA too (not just for
> stored
> >> > procedure) and will be able to send a working code in ML over the
> >> > weekend.
> >> >
> >> > Below is summary of what I got so far from the previous mail
> >> > discussions and
> >> > some questions.
> >> >
> >> >
> >> > The integration between DAS and SCA can happen at application level
> as
> >> > service or at container level.
> >> >
> >> >
> >> >
> >> > 2 different possible approaches –
> >> >
> >> > static – e.g. getAllCustomers
> >> >
> >> > dynamic – e.g. execute("all customers");
> >> >
> >> >
> >> >
> >> > For application level service – it is the sample *
> >> > sample-StoredProcedureService.jar* or what Luciano is providing in
> >> more
> >> > details, is an example. In *sample-StoredProcedureService.jar*
> >> example
> >> > dynamic approach is followed
> >> >
> >> >
> >> >
> >> > For container approach – again static or dynamic approach can be
> >> > followed.
> >> > For static – it's like providing service for getAllCompanies(),
> >> > getAllCustomers() etc. whereas for dynamic its like execute(command)
> >> > where
> >> > command can be "getAllCompanies", "getAllCustomers". Etc.
> >> >
> >> >
> >> >
> >> > I am working on a container implementation where dynamic
> >> > approach is followed.
> >> >
> >> If I understand correctly, the container approach will provide the
> >> tightest integration with SCA and make things easier for end-users. Do
> >> you agree?
> >>
> >> >
> >> >
> >> > There are 2 places where extensibility is required –
> >> >
> >> > 1) for providing different data access mechanisms. i.e. today
> >> > there is
> >> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
> >> > scdl will
> >> > be same, but the exampleconfig.xml will change.
> >> >
> >> > In the container I am working on - Scdl has a new tag
> >> >
> >> > Scdl has a new tag
> >> > <da:implementation.da script="customersOrders/CustomersOrders.xml"
> >> > dataAccessType="rdb"/>
> >> >
> >> >
> >> >
> >> > Here, dataAccessType – is the key which tells whether it's RDB or
> >> > something
> >> > else. And the xml script provides the connection and data store
> >> details.
> >> >
> >> >
> >> >
> >> > 2) for RDB-DAS – providing support for different databases (this
> >> > portion should be part of DAS and not SCA.) In the current container
> >> > I am
> >> > working on it is provided as a package -
> >> > org.apache.tuscany.container.dataaccessshelper package - which
> should
> >> > finally go into DAS codeline(?).
> >> >
> >> >
> >> Currently, there are two ways to specify a particular database: first,
> >> the user can pass a JDBC Connection to the DAS Factory when creating a
> >> DAS instance. The second is that a DataSource can be specified in the
> >> DAS Config xml file in which case the DAS is responsible for getting
> the
> >> connection.
> >>
> >> >
> >> >
> >> >
> >> > For static approach we may need some code generation tooling.
> >>
> >> Right. That is why I think it best to start with dynamic. But, we
> will
> >> want static support as well.
> >>
> >> > Also could not
> >> > understand how this can be merged into RESTful interfaces. (this was
> >> > mentioned in some mail conversation)
> >> >
> >> >
> >> >
> >> > Regards,
> >> >
> >> > Amita
> >> >
> >> >
> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >
> >> >>
> >> >> Luciano Resende wrote:
> >> >>
> >> >> > Comments in-line...
> >> >> >
> >> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> >> >> >>
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > I would also like to understand this a little better ... here
> >> I am
> >> >> >> > thinking
> >> >> >> > aloud and hope the others will help in getting my persceptions
> >> >> >> > right...
> >> >> >> >
> >> >> >> > I guess firstly it is a question of how or where we want to
> >> >> >> > position 'DAS
> >> >> >> > Integration' in SCA. Is is something we want to integrate as
> >> the
> >> >> >> > Application Layer, which I understand is what Amita is trying
> >> >> >> > presently and
> >> >> >> > which Jim refers to as component implementation. In this
> >> option
> >> >> >> > we get to
> >> >> >> > do some sort of a service wrapper to DAS and then it becomes a
> >> >> >> > demonstration
> >> >> >> > of two Tuscany subprojects integrating at application level.
> >> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > Yes, I think we have space to position DAS both ways, and
> >> integrating
> >> >> > in the
> >> >> > application layer by exposing DAS as a service would be a very
> easy
> >> >> and
> >> >> > quick, this could be exposed as a sample app, and could show we
> are
> >> >> > working
> >> >> > on getting a better integration between DAS and SCA
> >> >> >
> >> >> >
> >> >> >> Or do we want to position DAS at the infrastructure layer as
> >> another
> >> >> >> > extension type (either container or binding). I guess this is
> >> >> >> > where Ant
> >> >> >> > started this - proposing a JDBC container / binding for
> >> component
> >> >> >> > implementation in StoredProcedures.
> >> >> >> I was thinking a DAS was a way to declaratively model
> >> heterogeneous
> >> >> >> data as a service and offer a mechanism for remoting that data.
> In
> >> >> >> other words, it provided the ability for an application to
> perform
> >> >> >> CRUD using a high-level contract (interface) and having those
> >> >> >> operations take place across a service network. How this is
> >> hooked
> >> >> >> into the SCA container is probably best done as an extension
> type,
> >> >> >> i.e. someone could specify:
> >> >> >>
> >> >> >> <component name="Foo">
> >> >> >> <implementation.das>
> >> >> >> <interface.java ....>
> >> >> >> </implementation.das>
> >> >> >> </component>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > Yes, this goes back to the way I was thinking on my original
> >> proposal.
> >> >> >
> >> >> >
> >> >> >> If this is the path we should take
> >> >> >> > then we probably have to think beyond DAS - to something more
> >> >> >> > general - of
> >> >> >> > which DAS is just a special case. I suppose this is what Jim
> >> has
> >> >> also
> >> >> >> > suggested in trying to explore other persistence mechanisms.
> >> >> >> >
> >> >> >> This may be the crux of the confusion. I was thinking DAS
> >> provides a
> >> >> >> general mechanism for accessing heterogeneous data and is only
> >> right
> >> >> >> now tied to SQL because of resource constraints (i.e. we have to
> >> >> >> start somewhere). Ultimately, DAS should provide the
> >> infrastructure
> >> >> >> for dealing with multiple, varied data stores and mechanisms for
> >> >> >> querying across them. In other words, I guess I am saying DAS
> >> should
> >> >> >> be the general solution (declarative and heterogeneous) since
> >> if it
> >> >> >> is only a programmatic way to access relational data then its
> >> value
> >> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > Yes, the current status of DAS implementation is RDB only. I would
> >> say
> >> >> > that,
> >> >> > in the future, I'd like to see a heterogeneous DAS that would give
> >> you
> >> >> > access to different data stores, and probably support non-SDO
> types
> >> as
> >> >> > well.
> >> >> >
> >> >> >> I too feel that this is something that must be done as an
> >> extension
> >> >> >> > type -
> >> >> >> > but yet to get my hands on the general scheme of things that
> DAS
> >> >> >> > can slip
> >> >> >> > into. Infact the other thread where Jeremy has taken forward a
> >> >> >> > proposal to
> >> >> >> > the specs group on resources tempts me to think that there is
> >> going
> >> >> >> > to be
> >> >> >> > something in that which we can leverage from.
> >> >> >> >
> >> >> >> I think resources are orthogonal as they are about a component
> >> >> >> implementation's contract with its container. Declarative data
> >> >> >> services on the other hand are about application constructs
> >> that can
> >> >> >> be wired to.
> >> >> >>
> >> >> >> > I hope to get a better understanding this as we go along in
> this
> >> >> >> > thread :)
> >> >> >> >
> >> >> >> Me too :-) As soon as I have trouble explaining technologies to
> >> .NET
> >> >> >> people and they say "you Unix/Java people are at it again with a
> >> >> >> thousand ways to do the same exact thing" it causes me to think
> >> that
> >> >> >> maybe we need to clarify our message.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > If we all think it would be useful, I could try to summarize the
> >> >> > thread on
> >> >> > the wiki with a more clean proposal incorporating all your
> >> feedback ,
> >> >> > what
> >> >> > you guys think ?
> >> >>
> >> >> Yes. Great idea.
> >> >>
> >> >> >
> >> >> >
> >> >> > Jim
> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > - Venkat
> >> >> >> >
> >> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >>
> >> >> >> >> Jim Marino wrote:
> >> >> >> >>
> >> >> >> >> > When I first read the thread on this, I thought the DAS
> >> service
> >> >> >> >> would
> >> >> >> >> > be a component extension type (e.g. analogous to a
> >> >> >> >> > implementation.java or implementation.ejb) and not a
> >> component
> >> >> >> >> > implementation type, which would allow for dynamic and
> >> >> eventually
> >> >> >> >> > declarative configuration styles.
> >> >> >> >>
> >> >> >> >> I have not very familiar with the terminology so I am not sure
> >> >> what
> >> >> a
> >> >> >> >> "component extension type" is. But, I do think we eventually
> >> want
> >> >> >> >> "implementation.rdbdas". Wouldn't this be a new
> implementation
> >> >> type?
> >> >> >> >>
> >> >> >> >> It looks like Amita chose to start with a POJO. I notice
> >> the use
> >> >> >> >> of "
> >> >> >> >> implementation.java".
> >> >> >> >>
> >> >> >> >> > Either way, though, I am curious as to why
> >> >> >> >> >
> >> >> >> >> > public DAS configureService(String configFile);
> >> >> >> >> >
> >> >> >> >> > exists as part of the service definition? If the DAS service
> >> >> was a
> >> >> >> >> > component extension type, it could be handled as part of the
> >> >> >> >> > application bootstrap. If the DAS service was a component
> >> >> >> >> > implementation type, the configuration file URI could be
> >> passed
> >> >> >> >> in as
> >> >> >> >> > a property and then processed in an initializer method
> >> decorated
> >> >> by
> >> >> >> >> > the SCA @Init annotation. In the latter case, if the
> >> >> implementation
> >> >> >> >> > of DASService thread-safe (hopefully it is since
> >> configuration
> >> >> >> >> would
> >> >> >> >> > seem to be a heavyweight operation), then I would make the
> >> >> >> >> component
> >> >> >> >> > module scoped to avoid initialization overhead on every
> >> >> resolution.
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > In both approaches (extension vs. implementation type),
> >> having
> >> >> >> >> > configuration exposed to the application doesn't quite feel
> >> >> right,
> >> >> >> >> > since that is what DI tries to externalize.
> >> >> >> >>
> >> >> >> >> I agree. The configuration should be part of the
> >> >> initialization and
> >> >> >> >> should use SCA patterns to do this. I think that Amita meant
> >> >> to use
> >> >> >> >> eventually use a component property for the DAS config info
> but
> >> >> >> >> started
> >> >> >> >> with a method.
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > Also, I was thinking that in having this a component
> >> extension
> >> >> >> >> type,
> >> >> >> >> > the service interfaces returned from a resolution could
> >> include
> >> >> the
> >> >> >> >> > dynamic one described below or static ones people have
> >> >> mentioned.
> >> >> I
> >> >> >> >> > guess it is best to start with the easier-to-implement part
> >> >> >> >> first and
> >> >> >> >> > support the dynamic interface.
> >> >> >> >> >
> >> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be
> >> nice to
> >> >> >> >> > understand what DAS provides in relation to other
> persistence
> >> >> >> >> > technologies. Outside of the Java world, Microsoft is
> >> promoting
> >> >> >> >> LINQ
> >> >> >> >> > which is really interesting, and it would be informative to
> >> >> compare
> >> >> >> >> > the goals of DAS with that approach (there are obvious
> >> >> differences
> >> >> >> >> > such as having the query language a strongly-typed part of
> >> the
> >> >> >> >> > programming language, e.g. C#, and LINQ's use of closures).
> >> >> >> >> >
> >> >> >> >> > In contrasting DAS to O-R technologies, I see the primary
> use
> >> >> cases
> >> >> >> >> > for the former being a quick way to issue a query that may
> be
> >> >> >> >> > executed against *heterogeneous* data stores and have that
> >> data
> >> >> >> >> flow
> >> >> >> >> > remotely or to a client that is not necessarily
> >> Java-based. One
> >> >> key
> >> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> >> >> >> (Hibernate
> >> >> >> >> > and JPA are about as easy):
> >> >> >> >> >
> >> >> >> >> IMO the primary use case for DAS is an application that is
> SDO-
> >> >> >> >> centric
> >> >> >> >> and is taking advantage of its disconnected capabilities. The
> >> RDB
> >> >> >> >> DAS
> >> >> >> >> is built to work with SDO and uses the change summary to drive
> >> >> >> >> changes
> >> >> >> >> made to a disconnected data graph back to some store. This is
> >> not
> >> >> to
> >> >> >> >> say that a relational DAS could not be built on top of JPA, in
> >> >> fact,
> >> >> >> >> this might be a very useful thing to do. The implementation
> we
> >> >> >> >> currently have provides a very straightforward implicit
> mapping
> >> >> from
> >> >> >> >> DataObjects to Tables. If more capable mapping is needed
> >> then it
> >> >> >> >> makes
> >> >> >> >> sense to use the JPA-defined technology and artifacts. A
> >> modified
> >> >> >> >> Entity manager might be needed to take advantage of SDO's
> >> change
> >> >> >> >> summary.
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > public interface CustomerDao extends BaseQuery {
> >> >> >> >> > @Select("select * from customers where city = ?1")
> >> >> >> >> > DataSet<Customer> findCustomersFrom(String city);
> >> >> >> >> > }
> >> >> >> >> >
> >> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> >> >> >> > (CustomerDao.class, datasource);
> >> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > The other key is remote data and change lists. I think
> there
> >> >> are
> >> >> >> >> > (literally) about a thousand ways that already exist to
> >> >> handle the
> >> >> >> >> > "local" data case. For change lists, interop with ADO.NET's
> >> >> change
> >> >> >> >> > summary facilities would be interesting.
> >> >> >> >>
> >> >> >> >> I agree. Also, it looks like Xcalia may have a similar
> >> thought:
> >> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think
> >> it is
> >> >> >> >> > important we have a clear statement as to when it is
> >> appropriate
> >> >> >> >> and
> >> >> >> >> > not appropriate to use. One place to start would be to
> >> compare
> >> >> >> >> it to
> >> >> >> >> > JDBC 4 and JPA.
> >> >> >> >>
> >> >> >> >> We can get started with JPA:
> >> >> >> >>
> >> >> >> >> * JPA is java-specific, container-based, built around a
> >> >> connected
> >> >> >> >> data model and offers a complete O/R mapping for POJOs
> >> >> >> >>
> >> >> >> >> * The RDB DAS is a java implementation of a language -
> >> neutral
> >> >> >> >> concept (hopefully specified some day) that is
> >> >> containerless,
> >> >> >> >> assumes a disconnected data model and provides a simple,
> >> >> >> >> implicit
> >> >> >> >> mapping for SDO DataObjects (Dynamic or Static) to
> >> >> relational
> >> >> >> >> tables.
> >> >> >> >>
> >> >> >> >> Anything else?
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > Jim
> >> >> >> >> >
> >> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >> >> >> >
> >> >> >> >> >> Hi Amita
> >> >> >> >> >>
> >> >> >> >> >> I think we were both going on the same way, with the DAS
> >> >> Service
> >> >> >> >> >> sample,
> >> >> >> >> >> altough i had the interface more like this, to be more
> >> >> flexible :
> >> >> >> >> >>
> >> >> >> >> >> public interface DASService {
> >> >> >> >> >>
> >> >> >> >> >> public DAS configureService(String configFile);
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >> public DataObject executeCommand(String commandName);
> >> >> >> >> >> public DataObject execute(String newCommand);
> >> >> >> >> >> public void applyChanges(DataObject graphRoot);
> >> >> >> >> >> }
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> As for having it as a sample, maybe we could defined the
> >> >> >> >> DASService
> >> >> >> >> >> as one
> >> >> >> >> >> sample itself, and have a second version of companyWeb that
> >> >> would
> >> >> >> >> >> consume
> >> >> >> >> >> the service, something like :
> >> >> >> >> >>
> >> >> >> >> >> das\samples\companyWeb
> >> >> >> >> >> das\samples\dasService
> >> >> >> >> >> das\samples.companyWeb.service
> >> >> >> >> >>
> >> >> >> >> >> or, more like BigBank
> >> >> >> >> >>
> >> >> >> >> >> das\samples\companyweb.Service\dasService
> >> >> >> >> >> das\samples\companyweb.Service\webClient
> >> >> >> >> >>
> >> >> >> >> >> Or even in sampleApps...
> >> >> >> >> >>
> >> >> >> >> >> Toughts ?
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
> >> wrote:
> >> >> >> >> >>
> >> >> >> >> >>>
> >> >> >> >> >>> Hi ,
> >> >> >> >> >>> I am also following up another thread
> >> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> msg09944.html
> >> >> >> >> >>> on the
> >> >> >> >> >>> similar issue (JDBC stored procedure container
> >> >> >> >> >>> using DAS)
> >> >> >> >> >>> Besides the fact that I am actively working on the
> >> container
> >> >> >> >> work,
> >> >> >> >> >>> I also
> >> >> >> >> >>> have tried to
> >> >> >> >> >>> develop a sample based on the below discussion, following
> >> >> dynamic
> >> >> >> >> >>> approach.
> >> >> >> >> >>>
> >> >> >> >> >>> I am attaching the same here. Please take a look and give
> >> your
> >> >> >> >> >>> suggestions.
> >> >> >> >> >>> In this, StoredProcedureService implementation has
> >> >> >> >> setConfigInfo (DAS
> >> >> >> >> >>> Config) and
> >> >> >> >> >>> execute(Any SQL). This can be made more complete with
> >> >> >> >> executeSQL(),
> >> >> >> >> >>> applyChanges()
> >> >> >> >> >>> etc.
> >> >> >> >> >>>
> >> >> >> >> >>> Can this be added to the existing set of samples?
> >> >> >> >> >>>
> >> >> >> >> >>> Regards,
> >> >> >> >> >>> Amita
> >> >> >> >> >>>
> >> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >> >>> >
> >> >> >> >> >>> > Luciano Resende wrote:
> >> >> >> >> >>> >
> >> >> >> >> >>> > > Kevin, from what I understood from your suggestion, it
> >> was
> >> >> >> >> >>> looking to
> >> >> >> >> >>> > me
> >> >> >> >> >>> > > more like exposing DAS as a service :
> >> >> >> >> >>> > >
> >> >> >> >> >>> > >>> public interface RDBDASService
> >> >> >> >> >>> > >>> DataObject execute(String commandName);
> >> >> >> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
> >> >> >> >> >>> > >>> void applyChanges(DataObject graphRoot);
> >> >> >> >> >>> > >>> }
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > Yes, I am talking about exposing a DAS Service
> configured
> >> >> >> >> with a
> >> >> >> >> >>> > specific set of capabilities/commands defined in the DAS
> >> >> config
> >> >> >> >> >>> file.
> >> >> >> >> >>> > So, if the implementation of the service interface above
> >> was
> >> >> >> >> >>> configured
> >> >> >> >> >>> > to work with Customers they would use the service like
> >> this:
> >> >> >> >> >>> >
> >> >> >> >> >>> > List customers = myRDBDASService.execute
> >> >> ("getAllCustomers");
> >> >> >> >> >>> > String name = customers.get(0).getString("name");
> >> >> >> >> >>> >
> >> >> >> >> >>> > This is not much different than the static interface you
> >> >> >> >> proposed,
> >> >> >> >> >>> > right?
> >> >> >> >> >>> >
> >> >> >> >> >>> > > And then, when a service developer defines the
> >> >> >> >> AccountService,
> >> >> >> >> >>> he will
> >> >> >> >> >>> >
> >> >> >> >> >>> > > have
> >> >> >> >> >>> > > to know about yet another service, about how DAS
> works,
> >> >> >> >> how it is
> >> >> >> >> >>> > > configured, etc, etc... is that right ?
> >> >> >> >> >>> > >
> >> >> >> >> >>> > The abilities of the service are defined by the DAS
> >> config
> >> >> >> >> file.
> >> >> >> >> >>> So,
> >> >> >> >> >>> > the person or tool that provides the config file must
> >> >> >> >> understand
> >> >> >> >> >>> how the
> >> >> >> >> >>> >
> >> >> >> >> >>> > RDB DAS APIs work. There is no getting around this.
> >> >> >> >> >>> >
> >> >> >> >> >>> > > My proposal was going more towards allowing the
> service
> >> >> >> >> >>> developer to
> >> >> >> >> >>> > > focus
> >> >> >> >> >>> > > on defining the service, and let the "declarative
> >> das" to
> >> >> >> >> >>> handle the
> >> >> >> >> >>> > > persistent layer....
> >> >> >> >> >>> > >
> >> >> >> >> >>> > The DAS config file is the declaration of an instance of
> >> the
> >> >> >> >> >>> DAS. That
> >> >> >> >> >>> > instance can be exposed as a dynamic or typed service/
> >> >> >> >> interface.
> >> >> >> >> >>> That
> >> >> >> >> >>> > seems to be the main discussion we are having.
> >> Although, I
> >> >> >> >> may be
> >> >> >> >> >>> > missing something.
> >> >> >> >> >>> >
> >> >> >> >> >>> > > Also, by defining some conventions over configuration
> >> >> >> >> and/or using
> >> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a
> >> stored
> >> >> >> >> >>> procedure),
> >> >> >> >> >>> > the
> >> >> >> >> >>> > > service developer could really define a service that
> >> >> >> >> interacts
> >> >> >> >> >>> with a
> >> >> >> >> >>> > > RDB,
> >> >> >> >> >>> > > without having to code the service persistence layer.
> >> >> >> >> >>> > >
> >> >> >> >> >>> > There is a lot of potential for the use of annotations.
> >> >> >> >> >>> >
> >> >> >> >> >>> > >
> >> >> >> >> >>> > > - Luciano
> >> >> >> >> >>> > >
> >> >> >> >> >>> > >
> >> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net>
> >> wrote:
> >> >> >> >> >>> > >
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> The real difference between the two approaches is
> that
> >> >> >> >> one is
> >> >> >> >> >>> "Typed"
> >> >> >> >> >>> > or
> >> >> >> >> >>> > >> static and the other is dynamic. I think both are
> >> needed
> >> >> >> >> but was
> >> >> >> >> >>> > >> suggesting that we start with dynamic since it is the
> >> >> most
> >> >> >> >> >>> flexible
> >> >> >> >> >>> > and
> >> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a
> >> static
> >> >> >> >> >>> capability.
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> With either, the user does not need to know about
> >> >> >> >> traditional
> >> >> >> >> >>> > >> persistence frameworks. With the dynamic approach,
> >> >> however,
> >> >> >> >> >>> the user
> >> >> >> >> >>> > >> does need to know about the dynamic SDO API.
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> So, with the static interface the user might write:
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> List customers = accountService.getAllCustomers
> ();
> >> >> >> >> >>> > >> String name =
> >> ((Customer)customers.get(0)).getName();
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> The equivalent dynamic API might be:
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> List customers =
> >> >> dasService.execute("getAllCustomers");
> >> >> >> >> >>> > >> String name =
> >> >> ((DataObject)customers.get(0)).getString
> >> >> >> >> >>> ("name");
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> The first is probably a little easier for the
> >> application
> >> >> >> >> >>> developer
> >> >> >> >> >>> > but
> >> >> >> >> >>> > >> the second is much easier for the service developer.
> >> IMO,
> >> >> >> >> the
> >> >> >> >> >>> dynamic
> >> >> >> >> >>> > >> case is the best place to start and, again, we
> >> >> >> >> definitely will
> >> >> >> >> >>> want
> >> >> >> >> >>> > >> support for both.
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> Thanks.
> >> >> >> >> >>> > >> --
> >> >> >> >> >>> > >> Kevin
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> Jeremy Boynes wrote:
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> > I think this would be useful but it seems more
> >> like a
> >> >> >> >> >>> traditional
> >> >> >> >> >>> > >> > persistence API than what Luciano was suggesting.
> >> With
> >> >> >> >> this
> >> >> >> >> >>> one a
> >> >> >> >> >>> > >> > user needs to know about DataObject's, commands,
> SQL
> >> >> >> >> strings
> >> >> >> >> >>> etc.
> >> >> >> >> >>> > >> > just like they would if they were using raw JDBC or
> >> >> JPA.
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more
> >> about
> >> >> >> >> >>> expressing
> >> >> >> >> >>> > >> > high-level CRUD operations as operations on a
> >> service
> >> >> >> >> >>> interface:
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> public List getAllCustomers();
> >> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
> >> >> >> >> accountNumber);
> >> >> >> >> >>> > >> >>> }
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > which is all application level concepts rather
> >> >> >> >> than persistence
> >> >> >> >> >>> > level
> >> >> >> >> >>> > >> > concepts. I'd actually go a little further and put
> >> that
> >> >> >> >> >>> right into
> >> >> >> >> >>> > >> > the service contract:
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > public interface AccountService {
> >> >> >> >> >>> > >> > List<Customer> getAllCustomers();
> >> >> >> >> >>> > >> > Account getCustomerAccount(String
> >> accountNumber);
> >> >> >> >> >>> > >> > }
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
> >> >> >> >> standardized
> >> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
> >> >> configuration
> >> >> >> >> >>> would be
> >> >> >> >> >>> > >> > needed except to add this to the logical assembly:
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > <component name="AccountStore">
> >> >> >> >> >>> > >> > <implementation.das resource="MySQLDatabase"/>
> >> >> >> >> >>> > >> > </component>
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > With SCA's ability to translate service contracts,
> >> this
> >> >> >> >> >>> should be
> >> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
> >> >> >> >> regardless of
> >> >> >> >> >>> > whether
> >> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> >> >> >> >> running on
> >> >> >> >> a
> >> >> >> >> >>> > Java,
> >> >> >> >> >>> > >> > C++ or PHP platform.
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > The important thing here is that the client is
> >> >> >> >> isolated from
> >> >> >> >> >>> how
> >> >> >> >> >>> > the
> >> >> >> >> >>> > >> > DAS component is provided. We could have multiple
> >> >> >> >> declarative
> >> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and one
> >> that
> >> >> did
> >> >> >> >> >>> stuff
> >> >> >> >> >>> > with
> >> >> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
> >> >> >> >> altering
> >> >> >> >> >>> the
> >> >> >> >> >>> > >> > client at all/ they could switch to a custom coded
> >> >> version
> >> >> >> >> >>> written
> >> >> >> >> >>> > in
> >> >> >> >> >>> > >> > Java, C++ or a store procedure language like
> PL/SQL.
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > --
> >> >> >> >> >>> > >> > Jeremy
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >> 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 code
> >> specific to
> >> >> >> >> a new
> >> >> >> >> >>> > >> >> service. Instead, the service will be
> >> "instantiated"
> >> >> >> >> based
> >> >> >> >> >>> on the
> >> >> >> >> >>> >
> >> >> >> >> >>> > >> >> provided DAS config file. The service interface
> >> >> >> >> might look
> >> >> >> >> >>> like
> >> >> >> >> >>> > >> this:
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> public interface RDBDASService
> >> >> >> >> >>> > >> >> DataObject execute(String commandName);
> >> >> >> >> >>> > >> >> DataObject executeSQL(String abitrarySQL);
> >> >> >> >> >>> > >> >> void applyChanges(DataObject graphRoot);
> >> >> >> >> >>> > >> >> }
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> So, depending on the config file used to
> >> >> instantiate the
> >> >> >> >> >>> service,
> >> >> >> >> >>> > >> >> this interface could be used to return Customers/
> >> >> >> >> Accounts or
> >> >> >> >> >>> > >> >> Toasters. In fact, a lot could be achieved with
> no
> >> >> >> >> >>> > configuration at
> >> >> >> >> >>> > >> >> all by restricting use to: DataObject
> >> >> executeSQL(String
> >> >> >> >> >>> > >> abitrarySQL);
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> I expand a bit here:
> >> http://mail-archives.apache.org/
> >> >> >> >> >>> mod_mbox/ws-
> >> >> >> >> >>> > >> >>
> >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> Once this was working it should be
> >> straightforward to
> >> >> >> >> build
> >> >> >> >> >>> more
> >> >> >> >> >>> > >> >> strongly typed services and possible put together
> >> some
> >> >> >> >> >>> generation
> >> >> >> >> >>> > >> >> tooling. We could also start looking at support
> >> for
> >> a
> >> >> >> >> more
> >> >> >> >> >>> > RESTFul
> >> >> >> >> >>> > >> >> interface.
> >> >> >> >> >>> > >> >> --
> >> >> >> >> >>> > >> >> Kevin
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> Luciano Resende wrote:
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>> Recently, people have been starting to talk about
> >> >> >> >> better DAS
> >> >> >> >> >>> > >> >>> integration
> >> >> >> >> >>> > >> >>> with DAS, and below are some threads on the
> >> subject
> >> :
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> msg08833.html
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> msg08923.html
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >>
> >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >> >> >> >>> msg09715.html
> >> >> >> >> >>> >
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make
> >> sure
> >> >> >> >> what I'm
> >> >> >> >> >>> > >> >>> saying is not
> >> >> >> >> >>> > >> >>> yet available on SCA today.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Today, defining a service to work with a
> >> relational
> >> >> >> >> >>> database, you
> >> >> >> >> >>> > >> >>> will need
> >> >> >> >> >>> > >> >>> to code the persistence side of the service where
> >> >> CRUD
> >> >> >> >> >>> operations
> >> >> >> >> >>> > >> >>> to the
> >> >> >> >> >>> > >> >>> database will be done.
> >> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
> >> coding
> >> >> >> >> the
> >> >> >> >> >>> CRUD
> >> >> >> >> >>> > >> >>> operations on
> >> >> >> >> >>> > >> >>> the persistence layer would be avoided as much as
> >> >> >> >> possible.
> >> >> >> >> >>> > >> >>> The idea would be to have a more "declarative
> DAS"
> >> >> when
> >> >> >> >> >>> defining
> >> >> >> >> >>> > SCA
> >> >> >> >> >>> > >> >>> Services, so you would either use some
> Annotations
> >> >> >> >> or SCDL
> >> >> >> >> to
> >> >> >> >> >>> > >> have the
> >> >> >> >> >>> > >> >>> "declarative DAS" configuration inside it.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> I was thinking on something like....
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> SCDL Definition would look something like this :
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> <component name="AccountDataService">
> >> >> >> >> >>> > >> >>> <interface.java
> >> >> >> >> >>> > >> >>>
> >> >> >> >> class="bigbank.account.services.account.AccountService"/>
> >> >> >> >> >>> > >> >>> <implementation.das="dasConfig.properties"
> >> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >> >> >> >>> > >> >>> </component>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> The AccountService Interface would look like this
> >> >> >> >> (missing
> >> >> >> >> >>> any
> >> >> >> >> >>> > SCA
> >> >> >> >> >>> > >> >>> annotations):
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> public List getAllCustomers();
> >> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
> >> >> >> >> accountNumber);
> >> >> >> >> >>> > >> >>> }
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> The DAS config would look like this, and would
> >> >> have the
> >> >> >> >> >>> > definition
> >> >> >> >> >>> > >> >>> for the
> >> >> >> >> >>> > >> >>> "all companies" command.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> <Config ...>
> >> >> >> >> >>> > >> >>> ...
> >> >> >> >> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
> >> >> >> >> bigbank"/>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select *
> >> from
> >> >> >> >> >>> CUSTOMERS"
> >> >> >> >> >>> > >> >>> kind="Select"/>
> >> >> >> >> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
> >> >> >> >> >>> accountNumber,
> >> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
> >> >> >> >> accountNumber = ?"
> >> >> >> >> >>> > >> >>> kind="Select" />
> >> >> >> >> >>> > >> >>> ...
> >> >> >> >> >>> > >> >>> </Config>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Mapping between interface methods and DAS
> Commands
> >> >> >> >> >>> > >> >>> - If a DAS config file is provided, based on
> the
> >> >> >> >> >>> > SCDL definition,
> >> >> >> >> >>> > >> we
> >> >> >> >> >>> > >> >>> would look for "DAS command" based on the name of
> >> the
> >> >> >> >> getter
> >> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> >> >> >> >> command)
> >> >> >> >> >>> > >> >>> - Otherwise, we would try to do a map
> >> directly to
> >> a
> >> >> >> >> >>> > >> stored procedure
> >> >> >> >> >>> > >> >>> - We could also have a way to force the
> >> mapping by
> >> >> >> >> using
> >> >> >> >> >>> > >> annotation
> >> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Mapping between method parameter and command
> >> >> parameter
> >> >> >> >> >>> > >> >>> - We would need to define a method for
> >> mapping the
> >> >> >> >> method
> >> >> >> >> >>> > >> >>> parameters to
> >> >> >> >> >>> > >> >>> the query paramters either based on position (
> >> >> e.gfirst
> >> >> >> >> >>> method
> >> >> >> >> >>> > >> >>> parameter
> >> >> >> >> >>> > >> >>> maps to the first command paramter), or we
> >> would do
> >> >> some
> >> >> >> >> >>> > mapping by
> >> >> >> >> >>> > >> >>> name
> >> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Note:
> >> >> >> >> >>> > >> >>> - A SCDL connection information would
> >> override the
> >> >> DAS
> >> >> >> >> >>> Config
> >> >> >> >> >>> > file
> >> >> >> >> >>> > >> >>> connection information.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Benefits
> >> >> >> >> >>> > >> >>> - It's All about simplicity and easy of use
> >> >> >> >> >>> > >> >>> - This would allow a user to define a service
> >> >> without
> >> >> >> >> >>> having to
> >> >> >> >> >>> >
> >> >> >> >> >>> > >> >>> explicitly having to code any Data Access related
> >> >> code.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Implementation approaches
> >> >> >> >> >>> > >> >>> - Utilizing DAS : This approach would start
> from
> >> >> the
> >> >> >> >> >>> current
> >> >> >> >> >>> > >> >>> Tuscany DAS
> >> >> >> >> >>> > >> >>> implementation, where functionality would be
> >> already
> >> >> >> >> >>> > available, but
> >> >> >> >> >>> > >> >>> the
> >> >> >> >> >>> > >> >>> service implementation would be tied to SDO and
> >> RDB
> >> >> >> >> as this
> >> >> >> >> >>> > is what
> >> >> >> >> >>> > >> >>> DAS
> >> >> >> >> >>> > >> >>> supports today.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> - Start simple and grow : We could start
> simple,
> >> by
> >> >> >> >> >>> having a
> >> >> >> >> >>> > >> simple
> >> >> >> >> >>> > >> >>> implementation based on JDBC and would return
> some
> >> >> >> >> simple
> >> >> >> >> >>> > >> >>> collection as a
> >> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset),
> this
> >> >> could
> >> >> >> >> >>> give us
> >> >> >> >> >>> > a
> >> >> >> >> >>> > >> >>> quick
> >> >> >> >> >>> > >> >>> start to flush implementation details and get a
> >> >> proven
> >> >> >> >> >>> design,
> >> >> >> >> >>> > and
> >> >> >> >> >>> > >> >>> this
> >> >> >> >> >>> > >> >>> could get evolved to use a DAS that would support
> >> >> >> >> multiple
> >> >> >> >> >>> > backends
> >> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well
> as
> >> >> >> >> non- SDO
> >> >> >> >> >>> types
> >> >> >> >> >>> > >> as a
> >> >> >> >> >>> > >> >>> command
> >> >> >> >> >>> > >> >>> result.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Toughts ?
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> - Luciano
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
> >> >> wrote:
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> 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. Another thing we want to
> >> eventually
> >> >> >> >> >>> explore is
> >> >> >> >> >>> > >> >>>> exposing
> >> >> >> >> >>> > >> >>>> a DAS as REST-oriented services. As we have
> seen
> >> >> >> >> from the
> >> >> >> >> >>> > parent
> >> >> >> >> >>> > >> >>>> thread
> >> >> >> >> >>> > >> >>>> there are almost too many possible approaches.
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a
> service
> >> >> and
> >> >> >> >> >>> create a
> >> >> >> >> >>> > new
> >> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas
> ). The
> >> >> main
> >> >> >> >> >>> reason
> >> >> >> >> >>> > has
> >> >> >> >> >>> > >> >>>> to do
> >> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS
> that
> >> >> >> >> >>> > Jeremy mentioned
> >> >> >> >> >>> > >> >>>> which
> >> >> >> >> >>> > >> >>>> is all about creating data access services
> >> >> >> >> >>> declaratively. A new
> >> >> >> >> >>> > >> >>>> component type and a service that we build by
> >> hand
> >> >> >> >> would be
> >> >> >> >> >>> > a good
> >> >> >> >> >>> > >> >>>> step
> >> >> >> >> >>> > >> >>>> in this direction.
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> >> >> >> interface like
> >> >> >> >> >>> > this:
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> public interface RDBDASService
> >> >> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >> >> >> >> >>> > >> >>>> DataObject execute(String commandName);
> >> >> >> >> >>> > >> >>>> DataObject executeSQL(String
> >> abitrarySQL);
> >> >> >> >> >>> > >> >>>> }
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> The service would be initialized with an
> optional
> >> >> >> >> RDB DAS
> >> >> >> >> >>> > >> config file
> >> >> >> >> >>> > >> >>>> that defines connection properties, a set of
> >> >> commands,
> >> >> >> >> >>> etc. So,
> >> >> >> >> >>> > >> >>>> different services implementing the same
> >> interface
> >> >> >> >> could be
> >> >> >> >> >>> > >> >>>> initialized
> >> >> >> >> >>> > >> >>>> from separate config files.
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> Eventually, we might want to build services like
> >> >> this:
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> public interface Customers_RDBDASService
> >> >> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >> >> >> >> >>> > >> >>>> DataObject getAllCustomersWithLastName
> >> >> (String
> >> >> >> >> >>> > lastName);
> >> >> >> >> >>> > >> >>>> DataObject getAll
> CustomersAndOrdersForID
> >> >> (int
> >> >> >> >> >>> > customerId);
> >> >> >> >> >>> > >> >>>> }
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> But, for this to be very useful would probably
> >> >> require
> >> >> >> >> >>> some code
> >> >> >> >> >>> > >> >>>> generation tooling.
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> Thoughts?
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> --Kevin
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> Luciano Resende wrote:
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> >> >> >> >> declarative
> >> >> >> >> >>> > DAS and
> >> >> >> >> >>> > >> >>>> will be
> >> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki
> >> soon...
> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >>> > >> >>>> > - Luciano
> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jb...@apache.org>
> >> >> >> >> 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 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.
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I
> >> think we
> >> >> >> >> >>> > should welcome
> >> >> >> >> >>> > >> it
> >> >> >> >> >>> > >> >>>> >> like we would any other contribution.
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >> >> 3) to access data through an application
> >> >> >> >> service with
> >> >> >> >> >>> > >> >>>> declarative
> >> >> >> >> >>> > >> >>>> >> >> implementation by DAS
> >> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks
> >> radar.
> >> >> >> >> >>> > >> >>>> >> --
> >> >> >> >> >>> > >> >>>> >> Jeremy
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >>
> >> >> >> >> >>>
> >> >> >> >>
> >> >> --------------------------------------------------------------------
> >> >> >> >> >>> > >> -
> >> >> >> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> >>> unsubscribe@ws.apache.org
> >> >> >> >> >>> > >> >>>> >> For additional commands, e-mail:
> >> >> >> >> >>> > tuscany-dev-help@ws.apache.org
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >>
> >> >> >> >> >>>
> >> >> >> >>
> >> >> --------------------------------------------------------------------
> >> >> >> >> >>> > >> -
> >> >> >> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> >>> unsubscribe@ws.apache.org
> >> >> >> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
> >> >> >> >> >>> help@ws.apache.org
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> >
> >> >> >> >> >>>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
> >> >> >> >> >>> help@ws.apache.org
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> >
> >> >> >> >> >>>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
> >> >> >> >> help@ws.apache.org
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >> >>> > >> For additional commands, e-mail: tuscany-dev-
> >> >> >> >> help@ws.apache.org
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> > To unsubscribe, e-mail:
> >> >> tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> >>> > For additional commands, e-mail:
> >> >> tuscany-dev-help@ws.apache.org
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> To unsubscribe, e-mail:
> >> tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> >>> For additional commands, e-mail:
> >> >> tuscany-dev-help@ws.apache.org
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> > To unsubscribe, e-mail:
> tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> > For additional commands, e-mail:
> >> tuscany-dev-help@ws.apache.org
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >> For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Kevin Williams <ke...@qwest.net>.
Hello Amita,
This looks promising. I notice your test case uses explicit updates and
inserts. While this is supported by the DAS it is not the preferred
usage which is to allow the RDB DAS to generate the CUD statements from
the SDO change history. Could you modify the example to read a data
graph and then post the changes back via "applyChanges"? Maybe the
equivalent of this simple test from the DAS test suite:
public void testReadModifyApply4() throws Exception {
DAS das = DAS.FACTORY.createDAS(getConfig("CustomerConfig.xml"),
getConnection());
// Read customer with particular ID
Command select = das.getCommand("getCustomer");
select.setParameter(1, 1);
DataObject root = select.executeQuery();
DataObject customer = (DataObject) root.get("CUSTOMER[1]");
// Modify customer
customer.set("LASTNAME", "Pavick");
das.applyChanges(root);
// Verify the change
root = select.executeQuery();
assertEquals("Pavick",
root.getDataObject("CUSTOMER[1]").getString("LASTNAME"));
}
Also, this service interface seems difficult to work with since command
identifiers and argument values are encoded in the params Vector
public interface CustomersOrdersService {
void execute(Vector params);
DataObject executeQuery(Vector params);
void applyChanges(Vector params);
DataObject executeAdhoc(Vector params);//adhoc query implementation
DataObject getAllCustomers(Vector paramsList);
}
Do you think it possible to implement something like the following
interface:
public interface DynamicRDBDASService {
DataObject execute(String commandName, List params);
DataObject executeAdHoc(String queryString, List params);
void applyChanges();
}
The name is kind of long (suggestions welcome) but, I think this
interface could be generic and set of available commands is driven by
the provided DAS config file. I am not sure how we might support SP OUT
parameters but we can think about that later.
I does seem like you and Luciano should team up on this.
Thanks!
--
Kevin
Amita Vadhavkar wrote:
> Hi Kevin,
> Thanks a lot for the comments. I have posted the code and doc on JIRA-904
> for the container work. Also, am most likely missing something in the
> database
> connection portion. Would like to discuss with you.
>
> Will you please provide feedback on JIRA-904 attachments?
>
> I am checking with Luciano for a convenient date/time when we can chat,
> would
> be great if you can also join. I am in IST timezone.
>
> Regards,
> Amita
>
> On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
>
>>
>> Hi Amita,
>> This is looking good. Some comments inline:
>>
>> Amita Vadhavkar wrote:
>>
>> > Hi,
>> > I am trying to create a container for DAS-SCA too (not just for stored
>> > procedure) and will be able to send a working code in ML over the
>> > weekend.
>> >
>> > Below is summary of what I got so far from the previous mail
>> > discussions and
>> > some questions.
>> >
>> >
>> > The integration between DAS and SCA can happen at application level as
>> > service or at container level.
>> >
>> >
>> >
>> > 2 different possible approaches –
>> >
>> > static – e.g. getAllCustomers
>> >
>> > dynamic – e.g. execute("all customers");
>> >
>> >
>> >
>> > For application level service – it is the sample *
>> > sample-StoredProcedureService.jar* or what Luciano is providing in
>> more
>> > details, is an example. In *sample-StoredProcedureService.jar*
>> example
>> > dynamic approach is followed
>> >
>> >
>> >
>> > For container approach – again static or dynamic approach can be
>> > followed.
>> > For static – it's like providing service for getAllCompanies(),
>> > getAllCustomers() etc. whereas for dynamic its like execute(command)
>> > where
>> > command can be "getAllCompanies", "getAllCustomers". Etc.
>> >
>> >
>> >
>> > I am working on a container implementation where dynamic
>> > approach is followed.
>> >
>> If I understand correctly, the container approach will provide the
>> tightest integration with SCA and make things easier for end-users. Do
>> you agree?
>>
>> >
>> >
>> > There are 2 places where extensibility is required –
>> >
>> > 1) for providing different data access mechanisms. i.e. today
>> > there is
>> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
>> > scdl will
>> > be same, but the exampleconfig.xml will change.
>> >
>> > In the container I am working on - Scdl has a new tag
>> >
>> > Scdl has a new tag
>> > <da:implementation.da script="customersOrders/CustomersOrders.xml"
>> > dataAccessType="rdb"/>
>> >
>> >
>> >
>> > Here, dataAccessType – is the key which tells whether it's RDB or
>> > something
>> > else. And the xml script provides the connection and data store
>> details.
>> >
>> >
>> >
>> > 2) for RDB-DAS – providing support for different databases (this
>> > portion should be part of DAS and not SCA.) In the current container
>> > I am
>> > working on it is provided as a package -
>> > org.apache.tuscany.container.dataaccessshelper package - which should
>> > finally go into DAS codeline(?).
>> >
>> >
>> Currently, there are two ways to specify a particular database: first,
>> the user can pass a JDBC Connection to the DAS Factory when creating a
>> DAS instance. The second is that a DataSource can be specified in the
>> DAS Config xml file in which case the DAS is responsible for getting the
>> connection.
>>
>> >
>> >
>> >
>> > For static approach we may need some code generation tooling.
>>
>> Right. That is why I think it best to start with dynamic. But, we will
>> want static support as well.
>>
>> > Also could not
>> > understand how this can be merged into RESTful interfaces. (this was
>> > mentioned in some mail conversation)
>> >
>> >
>> >
>> > Regards,
>> >
>> > Amita
>> >
>> >
>> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >
>> >>
>> >> Luciano Resende wrote:
>> >>
>> >> > Comments in-line...
>> >> >
>> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
>> >> >>
>> >> >> > Hi,
>> >> >> >
>> >> >> > I would also like to understand this a little better ... here
>> I am
>> >> >> > thinking
>> >> >> > aloud and hope the others will help in getting my persceptions
>> >> >> > right...
>> >> >> >
>> >> >> > I guess firstly it is a question of how or where we want to
>> >> >> > position 'DAS
>> >> >> > Integration' in SCA. Is is something we want to integrate as
>> the
>> >> >> > Application Layer, which I understand is what Amita is trying
>> >> >> > presently and
>> >> >> > which Jim refers to as component implementation. In this
>> option
>> >> >> > we get to
>> >> >> > do some sort of a service wrapper to DAS and then it becomes a
>> >> >> > demonstration
>> >> >> > of two Tuscany subprojects integrating at application level.
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > Yes, I think we have space to position DAS both ways, and
>> integrating
>> >> > in the
>> >> > application layer by exposing DAS as a service would be a very easy
>> >> and
>> >> > quick, this could be exposed as a sample app, and could show we are
>> >> > working
>> >> > on getting a better integration between DAS and SCA
>> >> >
>> >> >
>> >> >> Or do we want to position DAS at the infrastructure layer as
>> another
>> >> >> > extension type (either container or binding). I guess this is
>> >> >> > where Ant
>> >> >> > started this - proposing a JDBC container / binding for
>> component
>> >> >> > implementation in StoredProcedures.
>> >> >> I was thinking a DAS was a way to declaratively model
>> heterogeneous
>> >> >> data as a service and offer a mechanism for remoting that data. In
>> >> >> other words, it provided the ability for an application to perform
>> >> >> CRUD using a high-level contract (interface) and having those
>> >> >> operations take place across a service network. How this is
>> hooked
>> >> >> into the SCA container is probably best done as an extension type,
>> >> >> i.e. someone could specify:
>> >> >>
>> >> >> <component name="Foo">
>> >> >> <implementation.das>
>> >> >> <interface.java ....>
>> >> >> </implementation.das>
>> >> >> </component>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Yes, this goes back to the way I was thinking on my original
>> proposal.
>> >> >
>> >> >
>> >> >> If this is the path we should take
>> >> >> > then we probably have to think beyond DAS - to something more
>> >> >> > general - of
>> >> >> > which DAS is just a special case. I suppose this is what Jim
>> has
>> >> also
>> >> >> > suggested in trying to explore other persistence mechanisms.
>> >> >> >
>> >> >> This may be the crux of the confusion. I was thinking DAS
>> provides a
>> >> >> general mechanism for accessing heterogeneous data and is only
>> right
>> >> >> now tied to SQL because of resource constraints (i.e. we have to
>> >> >> start somewhere). Ultimately, DAS should provide the
>> infrastructure
>> >> >> for dealing with multiple, varied data stores and mechanisms for
>> >> >> querying across them. In other words, I guess I am saying DAS
>> should
>> >> >> be the general solution (declarative and heterogeneous) since
>> if it
>> >> >> is only a programmatic way to access relational data then its
>> value
>> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Yes, the current status of DAS implementation is RDB only. I would
>> say
>> >> > that,
>> >> > in the future, I'd like to see a heterogeneous DAS that would give
>> you
>> >> > access to different data stores, and probably support non-SDO types
>> as
>> >> > well.
>> >> >
>> >> >> I too feel that this is something that must be done as an
>> extension
>> >> >> > type -
>> >> >> > but yet to get my hands on the general scheme of things that DAS
>> >> >> > can slip
>> >> >> > into. Infact the other thread where Jeremy has taken forward a
>> >> >> > proposal to
>> >> >> > the specs group on resources tempts me to think that there is
>> going
>> >> >> > to be
>> >> >> > something in that which we can leverage from.
>> >> >> >
>> >> >> I think resources are orthogonal as they are about a component
>> >> >> implementation's contract with its container. Declarative data
>> >> >> services on the other hand are about application constructs
>> that can
>> >> >> be wired to.
>> >> >>
>> >> >> > I hope to get a better understanding this as we go along in this
>> >> >> > thread :)
>> >> >> >
>> >> >> Me too :-) As soon as I have trouble explaining technologies to
>> .NET
>> >> >> people and they say "you Unix/Java people are at it again with a
>> >> >> thousand ways to do the same exact thing" it causes me to think
>> that
>> >> >> maybe we need to clarify our message.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > If we all think it would be useful, I could try to summarize the
>> >> > thread on
>> >> > the wiki with a more clean proposal incorporating all your
>> feedback ,
>> >> > what
>> >> > you guys think ?
>> >>
>> >> Yes. Great idea.
>> >>
>> >> >
>> >> >
>> >> > Jim
>> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > - Venkat
>> >> >> >
>> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >>
>> >> >> >> Jim Marino wrote:
>> >> >> >>
>> >> >> >> > When I first read the thread on this, I thought the DAS
>> service
>> >> >> >> would
>> >> >> >> > be a component extension type (e.g. analogous to a
>> >> >> >> > implementation.java or implementation.ejb) and not a
>> component
>> >> >> >> > implementation type, which would allow for dynamic and
>> >> eventually
>> >> >> >> > declarative configuration styles.
>> >> >> >>
>> >> >> >> I have not very familiar with the terminology so I am not sure
>> >> what
>> >> a
>> >> >> >> "component extension type" is. But, I do think we eventually
>> want
>> >> >> >> "implementation.rdbdas". Wouldn't this be a new implementation
>> >> type?
>> >> >> >>
>> >> >> >> It looks like Amita chose to start with a POJO. I notice
>> the use
>> >> >> >> of "
>> >> >> >> implementation.java".
>> >> >> >>
>> >> >> >> > Either way, though, I am curious as to why
>> >> >> >> >
>> >> >> >> > public DAS configureService(String configFile);
>> >> >> >> >
>> >> >> >> > exists as part of the service definition? If the DAS service
>> >> was a
>> >> >> >> > component extension type, it could be handled as part of the
>> >> >> >> > application bootstrap. If the DAS service was a component
>> >> >> >> > implementation type, the configuration file URI could be
>> passed
>> >> >> >> in as
>> >> >> >> > a property and then processed in an initializer method
>> decorated
>> >> by
>> >> >> >> > the SCA @Init annotation. In the latter case, if the
>> >> implementation
>> >> >> >> > of DASService thread-safe (hopefully it is since
>> configuration
>> >> >> >> would
>> >> >> >> > seem to be a heavyweight operation), then I would make the
>> >> >> >> component
>> >> >> >> > module scoped to avoid initialization overhead on every
>> >> resolution.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > In both approaches (extension vs. implementation type),
>> having
>> >> >> >> > configuration exposed to the application doesn't quite feel
>> >> right,
>> >> >> >> > since that is what DI tries to externalize.
>> >> >> >>
>> >> >> >> I agree. The configuration should be part of the
>> >> initialization and
>> >> >> >> should use SCA patterns to do this. I think that Amita meant
>> >> to use
>> >> >> >> eventually use a component property for the DAS config info but
>> >> >> >> started
>> >> >> >> with a method.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Also, I was thinking that in having this a component
>> extension
>> >> >> >> type,
>> >> >> >> > the service interfaces returned from a resolution could
>> include
>> >> the
>> >> >> >> > dynamic one described below or static ones people have
>> >> mentioned.
>> >> I
>> >> >> >> > guess it is best to start with the easier-to-implement part
>> >> >> >> first and
>> >> >> >> > support the dynamic interface.
>> >> >> >> >
>> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be
>> nice to
>> >> >> >> > understand what DAS provides in relation to other persistence
>> >> >> >> > technologies. Outside of the Java world, Microsoft is
>> promoting
>> >> >> >> LINQ
>> >> >> >> > which is really interesting, and it would be informative to
>> >> compare
>> >> >> >> > the goals of DAS with that approach (there are obvious
>> >> differences
>> >> >> >> > such as having the query language a strongly-typed part of
>> the
>> >> >> >> > programming language, e.g. C#, and LINQ's use of closures).
>> >> >> >> >
>> >> >> >> > In contrasting DAS to O-R technologies, I see the primary use
>> >> cases
>> >> >> >> > for the former being a quick way to issue a query that may be
>> >> >> >> > executed against *heterogeneous* data stores and have that
>> data
>> >> >> >> flow
>> >> >> >> > remotely or to a client that is not necessarily
>> Java-based. One
>> >> key
>> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
>> >> >> >> (Hibernate
>> >> >> >> > and JPA are about as easy):
>> >> >> >> >
>> >> >> >> IMO the primary use case for DAS is an application that is SDO-
>> >> >> >> centric
>> >> >> >> and is taking advantage of its disconnected capabilities. The
>> RDB
>> >> >> >> DAS
>> >> >> >> is built to work with SDO and uses the change summary to drive
>> >> >> >> changes
>> >> >> >> made to a disconnected data graph back to some store. This is
>> not
>> >> to
>> >> >> >> say that a relational DAS could not be built on top of JPA, in
>> >> fact,
>> >> >> >> this might be a very useful thing to do. The implementation we
>> >> >> >> currently have provides a very straightforward implicit mapping
>> >> from
>> >> >> >> DataObjects to Tables. If more capable mapping is needed
>> then it
>> >> >> >> makes
>> >> >> >> sense to use the JPA-defined technology and artifacts. A
>> modified
>> >> >> >> Entity manager might be needed to take advantage of SDO's
>> change
>> >> >> >> summary.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > public interface CustomerDao extends BaseQuery {
>> >> >> >> > @Select("select * from customers where city = ?1")
>> >> >> >> > DataSet<Customer> findCustomersFrom(String city);
>> >> >> >> > }
>> >> >> >> >
>> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
>> >> >> >> > (CustomerDao.class, datasource);
>> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > The other key is remote data and change lists. I think there
>> >> are
>> >> >> >> > (literally) about a thousand ways that already exist to
>> >> handle the
>> >> >> >> > "local" data case. For change lists, interop with ADO.NET's
>> >> change
>> >> >> >> > summary facilities would be interesting.
>> >> >> >>
>> >> >> >> I agree. Also, it looks like Xcalia may have a similar
>> thought:
>> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
>> >> >> >>
>> >> >> >> >
>> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think
>> it is
>> >> >> >> > important we have a clear statement as to when it is
>> appropriate
>> >> >> >> and
>> >> >> >> > not appropriate to use. One place to start would be to
>> compare
>> >> >> >> it to
>> >> >> >> > JDBC 4 and JPA.
>> >> >> >>
>> >> >> >> We can get started with JPA:
>> >> >> >>
>> >> >> >> * JPA is java-specific, container-based, built around a
>> >> connected
>> >> >> >> data model and offers a complete O/R mapping for POJOs
>> >> >> >>
>> >> >> >> * The RDB DAS is a java implementation of a language -
>> neutral
>> >> >> >> concept (hopefully specified some day) that is
>> >> containerless,
>> >> >> >> assumes a disconnected data model and provides a simple,
>> >> >> >> implicit
>> >> >> >> mapping for SDO DataObjects (Dynamic or Static) to
>> >> relational
>> >> >> >> tables.
>> >> >> >>
>> >> >> >> Anything else?
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Jim
>> >> >> >> >
>> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>> >> >> >> >
>> >> >> >> >> Hi Amita
>> >> >> >> >>
>> >> >> >> >> I think we were both going on the same way, with the DAS
>> >> Service
>> >> >> >> >> sample,
>> >> >> >> >> altough i had the interface more like this, to be more
>> >> flexible :
>> >> >> >> >>
>> >> >> >> >> public interface DASService {
>> >> >> >> >>
>> >> >> >> >> public DAS configureService(String configFile);
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >> public DataObject executeCommand(String commandName);
>> >> >> >> >> public DataObject execute(String newCommand);
>> >> >> >> >> public void applyChanges(DataObject graphRoot);
>> >> >> >> >> }
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> As for having it as a sample, maybe we could defined the
>> >> >> >> DASService
>> >> >> >> >> as one
>> >> >> >> >> sample itself, and have a second version of companyWeb that
>> >> would
>> >> >> >> >> consume
>> >> >> >> >> the service, something like :
>> >> >> >> >>
>> >> >> >> >> das\samples\companyWeb
>> >> >> >> >> das\samples\dasService
>> >> >> >> >> das\samples.companyWeb.service
>> >> >> >> >>
>> >> >> >> >> or, more like BigBank
>> >> >> >> >>
>> >> >> >> >> das\samples\companyweb.Service\dasService
>> >> >> >> >> das\samples\companyweb.Service\webClient
>> >> >> >> >>
>> >> >> >> >> Or even in sampleApps...
>> >> >> >> >>
>> >> >> >> >> Toughts ?
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
>> wrote:
>> >> >> >> >>
>> >> >> >> >>>
>> >> >> >> >>> Hi ,
>> >> >> >> >>> I am also following up another thread
>> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> msg09944.html
>> >> >> >> >>> on the
>> >> >> >> >>> similar issue (JDBC stored procedure container
>> >> >> >> >>> using DAS)
>> >> >> >> >>> Besides the fact that I am actively working on the
>> container
>> >> >> >> work,
>> >> >> >> >>> I also
>> >> >> >> >>> have tried to
>> >> >> >> >>> develop a sample based on the below discussion, following
>> >> dynamic
>> >> >> >> >>> approach.
>> >> >> >> >>>
>> >> >> >> >>> I am attaching the same here. Please take a look and give
>> your
>> >> >> >> >>> suggestions.
>> >> >> >> >>> In this, StoredProcedureService implementation has
>> >> >> >> setConfigInfo (DAS
>> >> >> >> >>> Config) and
>> >> >> >> >>> execute(Any SQL). This can be made more complete with
>> >> >> >> executeSQL(),
>> >> >> >> >>> applyChanges()
>> >> >> >> >>> etc.
>> >> >> >> >>>
>> >> >> >> >>> Can this be added to the existing set of samples?
>> >> >> >> >>>
>> >> >> >> >>> Regards,
>> >> >> >> >>> Amita
>> >> >> >> >>>
>> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >> >>> >
>> >> >> >> >>> > Luciano Resende wrote:
>> >> >> >> >>> >
>> >> >> >> >>> > > Kevin, from what I understood from your suggestion, it
>> was
>> >> >> >> >>> looking to
>> >> >> >> >>> > me
>> >> >> >> >>> > > more like exposing DAS as a service :
>> >> >> >> >>> > >
>> >> >> >> >>> > >>> public interface RDBDASService
>> >> >> >> >>> > >>> DataObject execute(String commandName);
>> >> >> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
>> >> >> >> >>> > >>> void applyChanges(DataObject graphRoot);
>> >> >> >> >>> > >>> }
>> >> >> >> >>> > >>
>> >> >> >> >>> > Yes, I am talking about exposing a DAS Service configured
>> >> >> >> with a
>> >> >> >> >>> > specific set of capabilities/commands defined in the DAS
>> >> config
>> >> >> >> >>> file.
>> >> >> >> >>> > So, if the implementation of the service interface above
>> was
>> >> >> >> >>> configured
>> >> >> >> >>> > to work with Customers they would use the service like
>> this:
>> >> >> >> >>> >
>> >> >> >> >>> > List customers = myRDBDASService.execute
>> >> ("getAllCustomers");
>> >> >> >> >>> > String name = customers.get(0).getString("name");
>> >> >> >> >>> >
>> >> >> >> >>> > This is not much different than the static interface you
>> >> >> >> proposed,
>> >> >> >> >>> > right?
>> >> >> >> >>> >
>> >> >> >> >>> > > And then, when a service developer defines the
>> >> >> >> AccountService,
>> >> >> >> >>> he will
>> >> >> >> >>> >
>> >> >> >> >>> > > have
>> >> >> >> >>> > > to know about yet another service, about how DAS works,
>> >> >> >> how it is
>> >> >> >> >>> > > configured, etc, etc... is that right ?
>> >> >> >> >>> > >
>> >> >> >> >>> > The abilities of the service are defined by the DAS
>> config
>> >> >> >> file.
>> >> >> >> >>> So,
>> >> >> >> >>> > the person or tool that provides the config file must
>> >> >> >> understand
>> >> >> >> >>> how the
>> >> >> >> >>> >
>> >> >> >> >>> > RDB DAS APIs work. There is no getting around this.
>> >> >> >> >>> >
>> >> >> >> >>> > > My proposal was going more towards allowing the service
>> >> >> >> >>> developer to
>> >> >> >> >>> > > focus
>> >> >> >> >>> > > on defining the service, and let the "declarative
>> das" to
>> >> >> >> >>> handle the
>> >> >> >> >>> > > persistent layer....
>> >> >> >> >>> > >
>> >> >> >> >>> > The DAS config file is the declaration of an instance of
>> the
>> >> >> >> >>> DAS. That
>> >> >> >> >>> > instance can be exposed as a dynamic or typed service/
>> >> >> >> interface.
>> >> >> >> >>> That
>> >> >> >> >>> > seems to be the main discussion we are having.
>> Although, I
>> >> >> >> may be
>> >> >> >> >>> > missing something.
>> >> >> >> >>> >
>> >> >> >> >>> > > Also, by defining some conventions over configuration
>> >> >> >> and/or using
>> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a
>> stored
>> >> >> >> >>> procedure),
>> >> >> >> >>> > the
>> >> >> >> >>> > > service developer could really define a service that
>> >> >> >> interacts
>> >> >> >> >>> with a
>> >> >> >> >>> > > RDB,
>> >> >> >> >>> > > without having to code the service persistence layer.
>> >> >> >> >>> > >
>> >> >> >> >>> > There is a lot of potential for the use of annotations.
>> >> >> >> >>> >
>> >> >> >> >>> > >
>> >> >> >> >>> > > - Luciano
>> >> >> >> >>> > >
>> >> >> >> >>> > >
>> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net>
>> wrote:
>> >> >> >> >>> > >
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> The real difference between the two approaches is that
>> >> >> >> one is
>> >> >> >> >>> "Typed"
>> >> >> >> >>> > or
>> >> >> >> >>> > >> static and the other is dynamic. I think both are
>> needed
>> >> >> >> but was
>> >> >> >> >>> > >> suggesting that we start with dynamic since it is the
>> >> most
>> >> >> >> >>> flexible
>> >> >> >> >>> > and
>> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a
>> static
>> >> >> >> >>> capability.
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> With either, the user does not need to know about
>> >> >> >> traditional
>> >> >> >> >>> > >> persistence frameworks. With the dynamic approach,
>> >> however,
>> >> >> >> >>> the user
>> >> >> >> >>> > >> does need to know about the dynamic SDO API.
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> So, with the static interface the user might write:
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> List customers = accountService.getAllCustomers();
>> >> >> >> >>> > >> String name =
>> ((Customer)customers.get(0)).getName();
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> The equivalent dynamic API might be:
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> List customers =
>> >> dasService.execute("getAllCustomers");
>> >> >> >> >>> > >> String name =
>> >> ((DataObject)customers.get(0)).getString
>> >> >> >> >>> ("name");
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> The first is probably a little easier for the
>> application
>> >> >> >> >>> developer
>> >> >> >> >>> > but
>> >> >> >> >>> > >> the second is much easier for the service developer.
>> IMO,
>> >> >> >> the
>> >> >> >> >>> dynamic
>> >> >> >> >>> > >> case is the best place to start and, again, we
>> >> >> >> definitely will
>> >> >> >> >>> want
>> >> >> >> >>> > >> support for both.
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> Thanks.
>> >> >> >> >>> > >> --
>> >> >> >> >>> > >> Kevin
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> Jeremy Boynes wrote:
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> > I think this would be useful but it seems more
>> like a
>> >> >> >> >>> traditional
>> >> >> >> >>> > >> > persistence API than what Luciano was suggesting.
>> With
>> >> >> >> this
>> >> >> >> >>> one a
>> >> >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
>> >> >> >> strings
>> >> >> >> >>> etc.
>> >> >> >> >>> > >> > just like they would if they were using raw JDBC or
>> >> JPA.
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more
>> about
>> >> >> >> >>> expressing
>> >> >> >> >>> > >> > high-level CRUD operations as operations on a
>> service
>> >> >> >> >>> interface:
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> public List getAllCustomers();
>> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
>> >> >> >> accountNumber);
>> >> >> >> >>> > >> >>> }
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > which is all application level concepts rather
>> >> >> >> than persistence
>> >> >> >> >>> > level
>> >> >> >> >>> > >> > concepts. I'd actually go a little further and put
>> that
>> >> >> >> >>> right into
>> >> >> >> >>> > >> > the service contract:
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > public interface AccountService {
>> >> >> >> >>> > >> > List<Customer> getAllCustomers();
>> >> >> >> >>> > >> > Account getCustomerAccount(String
>> accountNumber);
>> >> >> >> >>> > >> > }
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
>> >> >> >> standardized
>> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
>> >> configuration
>> >> >> >> >>> would be
>> >> >> >> >>> > >> > needed except to add this to the logical assembly:
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > <component name="AccountStore">
>> >> >> >> >>> > >> > <implementation.das resource="MySQLDatabase"/>
>> >> >> >> >>> > >> > </component>
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > With SCA's ability to translate service contracts,
>> this
>> >> >> >> >>> should be
>> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
>> >> >> >> regardless of
>> >> >> >> >>> > whether
>> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
>> >> >> >> running on
>> >> >> >> a
>> >> >> >> >>> > Java,
>> >> >> >> >>> > >> > C++ or PHP platform.
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > The important thing here is that the client is
>> >> >> >> isolated from
>> >> >> >> >>> how
>> >> >> >> >>> > the
>> >> >> >> >>> > >> > DAS component is provided. We could have multiple
>> >> >> >> declarative
>> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and one
>> that
>> >> did
>> >> >> >> >>> stuff
>> >> >> >> >>> > with
>> >> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
>> >> >> >> altering
>> >> >> >> >>> the
>> >> >> >> >>> > >> > client at all/ they could switch to a custom coded
>> >> version
>> >> >> >> >>> written
>> >> >> >> >>> > in
>> >> >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > --
>> >> >> >> >>> > >> > Jeremy
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >> 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 code
>> specific to
>> >> >> >> a new
>> >> >> >> >>> > >> >> service. Instead, the service will be
>> "instantiated"
>> >> >> >> based
>> >> >> >> >>> on the
>> >> >> >> >>> >
>> >> >> >> >>> > >> >> provided DAS config file. The service interface
>> >> >> >> might look
>> >> >> >> >>> like
>> >> >> >> >>> > >> this:
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> public interface RDBDASService
>> >> >> >> >>> > >> >> DataObject execute(String commandName);
>> >> >> >> >>> > >> >> DataObject executeSQL(String abitrarySQL);
>> >> >> >> >>> > >> >> void applyChanges(DataObject graphRoot);
>> >> >> >> >>> > >> >> }
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> So, depending on the config file used to
>> >> instantiate the
>> >> >> >> >>> service,
>> >> >> >> >>> > >> >> this interface could be used to return Customers/
>> >> >> >> Accounts or
>> >> >> >> >>> > >> >> Toasters. In fact, a lot could be achieved with no
>> >> >> >> >>> > configuration at
>> >> >> >> >>> > >> >> all by restricting use to: DataObject
>> >> executeSQL(String
>> >> >> >> >>> > >> abitrarySQL);
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> I expand a bit here:
>> http://mail-archives.apache.org/
>> >> >> >> >>> mod_mbox/ws-
>> >> >> >> >>> > >> >>
>> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> Once this was working it should be
>> straightforward to
>> >> >> >> build
>> >> >> >> >>> more
>> >> >> >> >>> > >> >> strongly typed services and possible put together
>> some
>> >> >> >> >>> generation
>> >> >> >> >>> > >> >> tooling. We could also start looking at support
>> for
>> a
>> >> >> >> more
>> >> >> >> >>> > RESTFul
>> >> >> >> >>> > >> >> interface.
>> >> >> >> >>> > >> >> --
>> >> >> >> >>> > >> >> Kevin
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> Luciano Resende wrote:
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>> Recently, people have been starting to talk about
>> >> >> >> better DAS
>> >> >> >> >>> > >> >>> integration
>> >> >> >> >>> > >> >>> with DAS, and below are some threads on the
>> subject
>> :
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> msg08833.html
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> msg08923.html
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >>
>> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> >> >> >> >>> msg09715.html
>> >> >> >> >>> >
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make
>> sure
>> >> >> >> what I'm
>> >> >> >> >>> > >> >>> saying is not
>> >> >> >> >>> > >> >>> yet available on SCA today.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Today, defining a service to work with a
>> relational
>> >> >> >> >>> database, you
>> >> >> >> >>> > >> >>> will need
>> >> >> >> >>> > >> >>> to code the persistence side of the service where
>> >> CRUD
>> >> >> >> >>> operations
>> >> >> >> >>> > >> >>> to the
>> >> >> >> >>> > >> >>> database will be done.
>> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
>> coding
>> >> >> >> the
>> >> >> >> >>> CRUD
>> >> >> >> >>> > >> >>> operations on
>> >> >> >> >>> > >> >>> the persistence layer would be avoided as much as
>> >> >> >> possible.
>> >> >> >> >>> > >> >>> The idea would be to have a more "declarative DAS"
>> >> when
>> >> >> >> >>> defining
>> >> >> >> >>> > SCA
>> >> >> >> >>> > >> >>> Services, so you would either use some Annotations
>> >> >> >> or SCDL
>> >> >> >> to
>> >> >> >> >>> > >> have the
>> >> >> >> >>> > >> >>> "declarative DAS" configuration inside it.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> I was thinking on something like....
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> SCDL Definition would look something like this :
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> <component name="AccountDataService">
>> >> >> >> >>> > >> >>> <interface.java
>> >> >> >> >>> > >> >>>
>> >> >> >> class="bigbank.account.services.account.AccountService"/>
>> >> >> >> >>> > >> >>> <implementation.das="dasConfig.properties"
>> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> >> >> >> >>> > >> >>> </component>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> The AccountService Interface would look like this
>> >> >> >> (missing
>> >> >> >> >>> any
>> >> >> >> >>> > SCA
>> >> >> >> >>> > >> >>> annotations):
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> public List getAllCustomers();
>> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
>> >> >> >> accountNumber);
>> >> >> >> >>> > >> >>> }
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> The DAS config would look like this, and would
>> >> have the
>> >> >> >> >>> > definition
>> >> >> >> >>> > >> >>> for the
>> >> >> >> >>> > >> >>> "all companies" command.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> <Config ...>
>> >> >> >> >>> > >> >>> ...
>> >> >> >> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
>> >> >> >> bigbank"/>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select *
>> from
>> >> >> >> >>> CUSTOMERS"
>> >> >> >> >>> > >> >>> kind="Select"/>
>> >> >> >> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
>> >> >> >> >>> accountNumber,
>> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
>> >> >> >> accountNumber = ?"
>> >> >> >> >>> > >> >>> kind="Select" />
>> >> >> >> >>> > >> >>> ...
>> >> >> >> >>> > >> >>> </Config>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
>> >> >> >> >>> > >> >>> - If a DAS config file is provided, based on the
>> >> >> >> >>> > SCDL definition,
>> >> >> >> >>> > >> we
>> >> >> >> >>> > >> >>> would look for "DAS command" based on the name of
>> the
>> >> >> >> getter
>> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
>> >> >> >> command)
>> >> >> >> >>> > >> >>> - Otherwise, we would try to do a map
>> directly to
>> a
>> >> >> >> >>> > >> stored procedure
>> >> >> >> >>> > >> >>> - We could also have a way to force the
>> mapping by
>> >> >> >> using
>> >> >> >> >>> > >> annotation
>> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Mapping between method parameter and command
>> >> parameter
>> >> >> >> >>> > >> >>> - We would need to define a method for
>> mapping the
>> >> >> >> method
>> >> >> >> >>> > >> >>> parameters to
>> >> >> >> >>> > >> >>> the query paramters either based on position (
>> >> e.gfirst
>> >> >> >> >>> method
>> >> >> >> >>> > >> >>> parameter
>> >> >> >> >>> > >> >>> maps to the first command paramter), or we
>> would do
>> >> some
>> >> >> >> >>> > mapping by
>> >> >> >> >>> > >> >>> name
>> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Note:
>> >> >> >> >>> > >> >>> - A SCDL connection information would
>> override the
>> >> DAS
>> >> >> >> >>> Config
>> >> >> >> >>> > file
>> >> >> >> >>> > >> >>> connection information.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Benefits
>> >> >> >> >>> > >> >>> - It's All about simplicity and easy of use
>> >> >> >> >>> > >> >>> - This would allow a user to define a service
>> >> without
>> >> >> >> >>> having to
>> >> >> >> >>> >
>> >> >> >> >>> > >> >>> explicitly having to code any Data Access related
>> >> code.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Implementation approaches
>> >> >> >> >>> > >> >>> - Utilizing DAS : This approach would start from
>> >> the
>> >> >> >> >>> current
>> >> >> >> >>> > >> >>> Tuscany DAS
>> >> >> >> >>> > >> >>> implementation, where functionality would be
>> already
>> >> >> >> >>> > available, but
>> >> >> >> >>> > >> >>> the
>> >> >> >> >>> > >> >>> service implementation would be tied to SDO and
>> RDB
>> >> >> >> as this
>> >> >> >> >>> > is what
>> >> >> >> >>> > >> >>> DAS
>> >> >> >> >>> > >> >>> supports today.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> - Start simple and grow : We could start simple,
>> by
>> >> >> >> >>> having a
>> >> >> >> >>> > >> simple
>> >> >> >> >>> > >> >>> implementation based on JDBC and would return some
>> >> >> >> simple
>> >> >> >> >>> > >> >>> collection as a
>> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
>> >> could
>> >> >> >> >>> give us
>> >> >> >> >>> > a
>> >> >> >> >>> > >> >>> quick
>> >> >> >> >>> > >> >>> start to flush implementation details and get a
>> >> proven
>> >> >> >> >>> design,
>> >> >> >> >>> > and
>> >> >> >> >>> > >> >>> this
>> >> >> >> >>> > >> >>> could get evolved to use a DAS that would support
>> >> >> >> multiple
>> >> >> >> >>> > backends
>> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
>> >> >> >> non- SDO
>> >> >> >> >>> types
>> >> >> >> >>> > >> as a
>> >> >> >> >>> > >> >>> command
>> >> >> >> >>> > >> >>> result.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Toughts ?
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> - Luciano
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
>> >> wrote:
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> 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. Another thing we want to
>> eventually
>> >> >> >> >>> explore is
>> >> >> >> >>> > >> >>>> exposing
>> >> >> >> >>> > >> >>>> a DAS as REST-oriented services. As we have seen
>> >> >> >> from the
>> >> >> >> >>> > parent
>> >> >> >> >>> > >> >>>> thread
>> >> >> >> >>> > >> >>>> there are almost too many possible approaches.
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a service
>> >> and
>> >> >> >> >>> create a
>> >> >> >> >>> > new
>> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas). The
>> >> main
>> >> >> >> >>> reason
>> >> >> >> >>> > has
>> >> >> >> >>> > >> >>>> to do
>> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
>> >> >> >> >>> > Jeremy mentioned
>> >> >> >> >>> > >> >>>> which
>> >> >> >> >>> > >> >>>> is all about creating data access services
>> >> >> >> >>> declaratively. A new
>> >> >> >> >>> > >> >>>> component type and a service that we build by
>> hand
>> >> >> >> would be
>> >> >> >> >>> > a good
>> >> >> >> >>> > >> >>>> step
>> >> >> >> >>> > >> >>>> in this direction.
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
>> >> >> >> interface like
>> >> >> >> >>> > this:
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> public interface RDBDASService
>> >> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
>> >> >> >> >>> > >> >>>> DataObject execute(String commandName);
>> >> >> >> >>> > >> >>>> DataObject executeSQL(String
>> abitrarySQL);
>> >> >> >> >>> > >> >>>> }
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> The service would be initialized with an optional
>> >> >> >> RDB DAS
>> >> >> >> >>> > >> config file
>> >> >> >> >>> > >> >>>> that defines connection properties, a set of
>> >> commands,
>> >> >> >> >>> etc. So,
>> >> >> >> >>> > >> >>>> different services implementing the same
>> interface
>> >> >> >> could be
>> >> >> >> >>> > >> >>>> initialized
>> >> >> >> >>> > >> >>>> from separate config files.
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> Eventually, we might want to build services like
>> >> this:
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> public interface Customers_RDBDASService
>> >> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
>> >> >> >> >>> > >> >>>> DataObject getAllCustomersWithLastName
>> >> (String
>> >> >> >> >>> > lastName);
>> >> >> >> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID
>> >> (int
>> >> >> >> >>> > customerId);
>> >> >> >> >>> > >> >>>> }
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> But, for this to be very useful would probably
>> >> require
>> >> >> >> >>> some code
>> >> >> >> >>> > >> >>>> generation tooling.
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> Thoughts?
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> --Kevin
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> Luciano Resende wrote:
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
>> >> >> >> declarative
>> >> >> >> >>> > DAS and
>> >> >> >> >>> > >> >>>> will be
>> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki
>> soon...
>> >> >> >> >>> > >> >>>> >
>> >> >> >> >>> > >> >>>> > - Luciano
>> >> >> >> >>> > >> >>>> >
>> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
>> >> >> >> 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 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.
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
>> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I
>> think we
>> >> >> >> >>> > should welcome
>> >> >> >> >>> > >> it
>> >> >> >> >>> > >> >>>> >> like we would any other contribution.
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >> >> 3) to access data through an application
>> >> >> >> service with
>> >> >> >> >>> > >> >>>> declarative
>> >> >> >> >>> > >> >>>> >> >> implementation by DAS
>> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks
>> radar.
>> >> >> >> >>> > >> >>>> >> --
>> >> >> >> >>> > >> >>>> >> Jeremy
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >>
>> >> >> >> >>>
>> >> >> >>
>> >> --------------------------------------------------------------------
>> >> >> >> >>> > >> -
>> >> >> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> >>> unsubscribe@ws.apache.org
>> >> >> >> >>> > >> >>>> >> For additional commands, e-mail:
>> >> >> >> >>> > tuscany-dev-help@ws.apache.org
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >>
>> >> >> >> >>>
>> >> >> >>
>> >> --------------------------------------------------------------------
>> >> >> >> >>> > >> -
>> >> >> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> >>> unsubscribe@ws.apache.org
>> >> >> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
>> >> >> >> >>> help@ws.apache.org
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> >
>> >> >> >> >>>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> unsubscribe@ws.apache.org
>> >> >> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
>> >> >> >> >>> help@ws.apache.org
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> >
>> >> >> >> >>>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> unsubscribe@ws.apache.org
>> >> >> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
>> >> >> >> help@ws.apache.org
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >> unsubscribe@ws.apache.org
>> >> >> >> >>> > >> For additional commands, e-mail: tuscany-dev-
>> >> >> >> help@ws.apache.org
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >>> > To unsubscribe, e-mail:
>> >> tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> >>> > For additional commands, e-mail:
>> >> tuscany-dev-help@ws.apache.org
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >>> To unsubscribe, e-mail:
>> tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> >>> For additional commands, e-mail:
>> >> tuscany-dev-help@ws.apache.org
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> > For additional commands, e-mail:
>> tuscany-dev-help@ws.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi Kevin,
Thanks a lot for the comments. I have posted the code and doc on JIRA-904
for the container work. Also, am most likely missing something in the
database
connection portion. Would like to discuss with you.
Will you please provide feedback on JIRA-904 attachments?
I am checking with Luciano for a convenient date/time when we can chat,
would
be great if you can also join. I am in IST timezone.
Regards,
Amita
On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Hi Amita,
> This is looking good. Some comments inline:
>
> Amita Vadhavkar wrote:
>
> > Hi,
> > I am trying to create a container for DAS-SCA too (not just for stored
> > procedure) and will be able to send a working code in ML over the
> > weekend.
> >
> > Below is summary of what I got so far from the previous mail
> > discussions and
> > some questions.
> >
> >
> > The integration between DAS and SCA can happen at application level as
> > service or at container level.
> >
> >
> >
> > 2 different possible approaches –
> >
> > static – e.g. getAllCustomers
> >
> > dynamic – e.g. execute("all customers");
> >
> >
> >
> > For application level service – it is the sample *
> > sample-StoredProcedureService.jar* or what Luciano is providing in more
> > details, is an example. In *sample-StoredProcedureService.jar* example
> > dynamic approach is followed
> >
> >
> >
> > For container approach – again static or dynamic approach can be
> > followed.
> > For static – it's like providing service for getAllCompanies(),
> > getAllCustomers() etc. whereas for dynamic its like execute(command)
> > where
> > command can be "getAllCompanies", "getAllCustomers". Etc.
> >
> >
> >
> > I am working on a container implementation where dynamic
> > approach is followed.
> >
> If I understand correctly, the container approach will provide the
> tightest integration with SCA and make things easier for end-users. Do
> you agree?
>
> >
> >
> > There are 2 places where extensibility is required –
> >
> > 1) for providing different data access mechanisms. i.e. today
> > there is
> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
> > scdl will
> > be same, but the exampleconfig.xml will change.
> >
> > In the container I am working on - Scdl has a new tag
> >
> > Scdl has a new tag
> > <da:implementation.da script="customersOrders/CustomersOrders.xml"
> > dataAccessType="rdb"/>
> >
> >
> >
> > Here, dataAccessType – is the key which tells whether it's RDB or
> > something
> > else. And the xml script provides the connection and data store details.
> >
> >
> >
> > 2) for RDB-DAS – providing support for different databases (this
> > portion should be part of DAS and not SCA.) In the current container
> > I am
> > working on it is provided as a package -
> > org.apache.tuscany.container.dataaccessshelper package - which should
> > finally go into DAS codeline(?).
> >
> >
> Currently, there are two ways to specify a particular database: first,
> the user can pass a JDBC Connection to the DAS Factory when creating a
> DAS instance. The second is that a DataSource can be specified in the
> DAS Config xml file in which case the DAS is responsible for getting the
> connection.
>
> >
> >
> >
> > For static approach we may need some code generation tooling.
>
> Right. That is why I think it best to start with dynamic. But, we will
> want static support as well.
>
> > Also could not
> > understand how this can be merged into RESTful interfaces. (this was
> > mentioned in some mail conversation)
> >
> >
> >
> > Regards,
> >
> > Amita
> >
> >
> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >>
> >> Luciano Resende wrote:
> >>
> >> > Comments in-line...
> >> >
> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >
> >> >>
> >> >>
> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > I would also like to understand this a little better ... here I am
> >> >> > thinking
> >> >> > aloud and hope the others will help in getting my persceptions
> >> >> > right...
> >> >> >
> >> >> > I guess firstly it is a question of how or where we want to
> >> >> > position 'DAS
> >> >> > Integration' in SCA. Is is something we want to integrate as the
> >> >> > Application Layer, which I understand is what Amita is trying
> >> >> > presently and
> >> >> > which Jim refers to as component implementation. In this option
> >> >> > we get to
> >> >> > do some sort of a service wrapper to DAS and then it becomes a
> >> >> > demonstration
> >> >> > of two Tuscany subprojects integrating at application level.
> >> >> >
> >> >
> >> >
> >> >
> >> > Yes, I think we have space to position DAS both ways, and integrating
> >> > in the
> >> > application layer by exposing DAS as a service would be a very easy
> >> and
> >> > quick, this could be exposed as a sample app, and could show we are
> >> > working
> >> > on getting a better integration between DAS and SCA
> >> >
> >> >
> >> >> Or do we want to position DAS at the infrastructure layer as another
> >> >> > extension type (either container or binding). I guess this is
> >> >> > where Ant
> >> >> > started this - proposing a JDBC container / binding for component
> >> >> > implementation in StoredProcedures.
> >> >> I was thinking a DAS was a way to declaratively model heterogeneous
> >> >> data as a service and offer a mechanism for remoting that data. In
> >> >> other words, it provided the ability for an application to perform
> >> >> CRUD using a high-level contract (interface) and having those
> >> >> operations take place across a service network. How this is hooked
> >> >> into the SCA container is probably best done as an extension type,
> >> >> i.e. someone could specify:
> >> >>
> >> >> <component name="Foo">
> >> >> <implementation.das>
> >> >> <interface.java ....>
> >> >> </implementation.das>
> >> >> </component>
> >> >
> >> >
> >> >
> >> >
> >> > Yes, this goes back to the way I was thinking on my original
> proposal.
> >> >
> >> >
> >> >> If this is the path we should take
> >> >> > then we probably have to think beyond DAS - to something more
> >> >> > general - of
> >> >> > which DAS is just a special case. I suppose this is what Jim has
> >> also
> >> >> > suggested in trying to explore other persistence mechanisms.
> >> >> >
> >> >> This may be the crux of the confusion. I was thinking DAS provides a
> >> >> general mechanism for accessing heterogeneous data and is only right
> >> >> now tied to SQL because of resource constraints (i.e. we have to
> >> >> start somewhere). Ultimately, DAS should provide the infrastructure
> >> >> for dealing with multiple, varied data stores and mechanisms for
> >> >> querying across them. In other words, I guess I am saying DAS should
> >> >> be the general solution (declarative and heterogeneous) since if it
> >> >> is only a programmatic way to access relational data then its value
> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
> >> >
> >> >
> >> >
> >> >
> >> > Yes, the current status of DAS implementation is RDB only. I would
> say
> >> > that,
> >> > in the future, I'd like to see a heterogeneous DAS that would give
> you
> >> > access to different data stores, and probably support non-SDO types
> as
> >> > well.
> >> >
> >> >> I too feel that this is something that must be done as an extension
> >> >> > type -
> >> >> > but yet to get my hands on the general scheme of things that DAS
> >> >> > can slip
> >> >> > into. Infact the other thread where Jeremy has taken forward a
> >> >> > proposal to
> >> >> > the specs group on resources tempts me to think that there is
> going
> >> >> > to be
> >> >> > something in that which we can leverage from.
> >> >> >
> >> >> I think resources are orthogonal as they are about a component
> >> >> implementation's contract with its container. Declarative data
> >> >> services on the other hand are about application constructs that can
> >> >> be wired to.
> >> >>
> >> >> > I hope to get a better understanding this as we go along in this
> >> >> > thread :)
> >> >> >
> >> >> Me too :-) As soon as I have trouble explaining technologies to .NET
> >> >> people and they say "you Unix/Java people are at it again with a
> >> >> thousand ways to do the same exact thing" it causes me to think that
> >> >> maybe we need to clarify our message.
> >> >
> >> >
> >> >
> >> >
> >> > If we all think it would be useful, I could try to summarize the
> >> > thread on
> >> > the wiki with a more clean proposal incorporating all your feedback ,
> >> > what
> >> > you guys think ?
> >>
> >> Yes. Great idea.
> >>
> >> >
> >> >
> >> > Jim
> >> >
> >> >> > Thanks
> >> >> >
> >> >> > - Venkat
> >> >> >
> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >>
> >> >> >> Jim Marino wrote:
> >> >> >>
> >> >> >> > When I first read the thread on this, I thought the DAS service
> >> >> >> would
> >> >> >> > be a component extension type (e.g. analogous to a
> >> >> >> > implementation.java or implementation.ejb) and not a component
> >> >> >> > implementation type, which would allow for dynamic and
> >> eventually
> >> >> >> > declarative configuration styles.
> >> >> >>
> >> >> >> I have not very familiar with the terminology so I am not sure
> >> what
> >> a
> >> >> >> "component extension type" is. But, I do think we eventually
> want
> >> >> >> "implementation.rdbdas". Wouldn't this be a new implementation
> >> type?
> >> >> >>
> >> >> >> It looks like Amita chose to start with a POJO. I notice the use
> >> >> >> of "
> >> >> >> implementation.java".
> >> >> >>
> >> >> >> > Either way, though, I am curious as to why
> >> >> >> >
> >> >> >> > public DAS configureService(String configFile);
> >> >> >> >
> >> >> >> > exists as part of the service definition? If the DAS service
> >> was a
> >> >> >> > component extension type, it could be handled as part of the
> >> >> >> > application bootstrap. If the DAS service was a component
> >> >> >> > implementation type, the configuration file URI could be passed
> >> >> >> in as
> >> >> >> > a property and then processed in an initializer method
> decorated
> >> by
> >> >> >> > the SCA @Init annotation. In the latter case, if the
> >> implementation
> >> >> >> > of DASService thread-safe (hopefully it is since configuration
> >> >> >> would
> >> >> >> > seem to be a heavyweight operation), then I would make the
> >> >> >> component
> >> >> >> > module scoped to avoid initialization overhead on every
> >> resolution.
> >> >> >>
> >> >> >> >
> >> >> >> > In both approaches (extension vs. implementation type), having
> >> >> >> > configuration exposed to the application doesn't quite feel
> >> right,
> >> >> >> > since that is what DI tries to externalize.
> >> >> >>
> >> >> >> I agree. The configuration should be part of the
> >> initialization and
> >> >> >> should use SCA patterns to do this. I think that Amita meant
> >> to use
> >> >> >> eventually use a component property for the DAS config info but
> >> >> >> started
> >> >> >> with a method.
> >> >> >>
> >> >> >> >
> >> >> >> > Also, I was thinking that in having this a component extension
> >> >> >> type,
> >> >> >> > the service interfaces returned from a resolution could include
> >> the
> >> >> >> > dynamic one described below or static ones people have
> >> mentioned.
> >> I
> >> >> >> > guess it is best to start with the easier-to-implement part
> >> >> >> first and
> >> >> >> > support the dynamic interface.
> >> >> >> >
> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> >> >> >> > understand what DAS provides in relation to other persistence
> >> >> >> > technologies. Outside of the Java world, Microsoft is promoting
> >> >> >> LINQ
> >> >> >> > which is really interesting, and it would be informative to
> >> compare
> >> >> >> > the goals of DAS with that approach (there are obvious
> >> differences
> >> >> >> > such as having the query language a strongly-typed part of the
> >> >> >> > programming language, e.g. C#, and LINQ's use of closures).
> >> >> >> >
> >> >> >> > In contrasting DAS to O-R technologies, I see the primary use
> >> cases
> >> >> >> > for the former being a quick way to issue a query that may be
> >> >> >> > executed against *heterogeneous* data stores and have that data
> >> >> >> flow
> >> >> >> > remotely or to a client that is not necessarily Java-based. One
> >> key
> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> >> >> (Hibernate
> >> >> >> > and JPA are about as easy):
> >> >> >> >
> >> >> >> IMO the primary use case for DAS is an application that is SDO-
> >> >> >> centric
> >> >> >> and is taking advantage of its disconnected capabilities. The
> RDB
> >> >> >> DAS
> >> >> >> is built to work with SDO and uses the change summary to drive
> >> >> >> changes
> >> >> >> made to a disconnected data graph back to some store. This is
> not
> >> to
> >> >> >> say that a relational DAS could not be built on top of JPA, in
> >> fact,
> >> >> >> this might be a very useful thing to do. The implementation we
> >> >> >> currently have provides a very straightforward implicit mapping
> >> from
> >> >> >> DataObjects to Tables. If more capable mapping is needed then it
> >> >> >> makes
> >> >> >> sense to use the JPA-defined technology and artifacts. A
> modified
> >> >> >> Entity manager might be needed to take advantage of SDO's change
> >> >> >> summary.
> >> >> >>
> >> >> >> >
> >> >> >> > public interface CustomerDao extends BaseQuery {
> >> >> >> > @Select("select * from customers where city = ?1")
> >> >> >> > DataSet<Customer> findCustomersFrom(String city);
> >> >> >> > }
> >> >> >> >
> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> >> >> > (CustomerDao.class, datasource);
> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >> >> >
> >> >> >> >
> >> >> >> > The other key is remote data and change lists. I think there
> >> are
> >> >> >> > (literally) about a thousand ways that already exist to
> >> handle the
> >> >> >> > "local" data case. For change lists, interop with ADO.NET's
> >> change
> >> >> >> > summary facilities would be interesting.
> >> >> >>
> >> >> >> I agree. Also, it looks like Xcalia may have a similar thought:
> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >> >> >>
> >> >> >> >
> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think it is
> >> >> >> > important we have a clear statement as to when it is
> appropriate
> >> >> >> and
> >> >> >> > not appropriate to use. One place to start would be to compare
> >> >> >> it to
> >> >> >> > JDBC 4 and JPA.
> >> >> >>
> >> >> >> We can get started with JPA:
> >> >> >>
> >> >> >> * JPA is java-specific, container-based, built around a
> >> connected
> >> >> >> data model and offers a complete O/R mapping for POJOs
> >> >> >>
> >> >> >> * The RDB DAS is a java implementation of a language -
> neutral
> >> >> >> concept (hopefully specified some day) that is
> >> containerless,
> >> >> >> assumes a disconnected data model and provides a simple,
> >> >> >> implicit
> >> >> >> mapping for SDO DataObjects (Dynamic or Static) to
> >> relational
> >> >> >> tables.
> >> >> >>
> >> >> >> Anything else?
> >> >> >>
> >> >> >> >
> >> >> >> > Jim
> >> >> >> >
> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >> >> >
> >> >> >> >> Hi Amita
> >> >> >> >>
> >> >> >> >> I think we were both going on the same way, with the DAS
> >> Service
> >> >> >> >> sample,
> >> >> >> >> altough i had the interface more like this, to be more
> >> flexible :
> >> >> >> >>
> >> >> >> >> public interface DASService {
> >> >> >> >>
> >> >> >> >> public DAS configureService(String configFile);
> >> >> >> >
> >> >> >> >
> >> >> >> >> public DataObject executeCommand(String commandName);
> >> >> >> >> public DataObject execute(String newCommand);
> >> >> >> >> public void applyChanges(DataObject graphRoot);
> >> >> >> >> }
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> As for having it as a sample, maybe we could defined the
> >> >> >> DASService
> >> >> >> >> as one
> >> >> >> >> sample itself, and have a second version of companyWeb that
> >> would
> >> >> >> >> consume
> >> >> >> >> the service, something like :
> >> >> >> >>
> >> >> >> >> das\samples\companyWeb
> >> >> >> >> das\samples\dasService
> >> >> >> >> das\samples.companyWeb.service
> >> >> >> >>
> >> >> >> >> or, more like BigBank
> >> >> >> >>
> >> >> >> >> das\samples\companyweb.Service\dasService
> >> >> >> >> das\samples\companyweb.Service\webClient
> >> >> >> >>
> >> >> >> >> Or even in sampleApps...
> >> >> >> >>
> >> >> >> >> Toughts ?
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
> wrote:
> >> >> >> >>
> >> >> >> >>>
> >> >> >> >>> Hi ,
> >> >> >> >>> I am also following up another thread
> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> msg09944.html
> >> >> >> >>> on the
> >> >> >> >>> similar issue (JDBC stored procedure container
> >> >> >> >>> using DAS)
> >> >> >> >>> Besides the fact that I am actively working on the container
> >> >> >> work,
> >> >> >> >>> I also
> >> >> >> >>> have tried to
> >> >> >> >>> develop a sample based on the below discussion, following
> >> dynamic
> >> >> >> >>> approach.
> >> >> >> >>>
> >> >> >> >>> I am attaching the same here. Please take a look and give
> your
> >> >> >> >>> suggestions.
> >> >> >> >>> In this, StoredProcedureService implementation has
> >> >> >> setConfigInfo (DAS
> >> >> >> >>> Config) and
> >> >> >> >>> execute(Any SQL). This can be made more complete with
> >> >> >> executeSQL(),
> >> >> >> >>> applyChanges()
> >> >> >> >>> etc.
> >> >> >> >>>
> >> >> >> >>> Can this be added to the existing set of samples?
> >> >> >> >>>
> >> >> >> >>> Regards,
> >> >> >> >>> Amita
> >> >> >> >>>
> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >>> >
> >> >> >> >>> > Luciano Resende wrote:
> >> >> >> >>> >
> >> >> >> >>> > > Kevin, from what I understood from your suggestion, it
> was
> >> >> >> >>> looking to
> >> >> >> >>> > me
> >> >> >> >>> > > more like exposing DAS as a service :
> >> >> >> >>> > >
> >> >> >> >>> > >>> public interface RDBDASService
> >> >> >> >>> > >>> DataObject execute(String commandName);
> >> >> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
> >> >> >> >>> > >>> void applyChanges(DataObject graphRoot);
> >> >> >> >>> > >>> }
> >> >> >> >>> > >>
> >> >> >> >>> > Yes, I am talking about exposing a DAS Service configured
> >> >> >> with a
> >> >> >> >>> > specific set of capabilities/commands defined in the DAS
> >> config
> >> >> >> >>> file.
> >> >> >> >>> > So, if the implementation of the service interface above
> was
> >> >> >> >>> configured
> >> >> >> >>> > to work with Customers they would use the service like
> this:
> >> >> >> >>> >
> >> >> >> >>> > List customers = myRDBDASService.execute
> >> ("getAllCustomers");
> >> >> >> >>> > String name = customers.get(0).getString("name");
> >> >> >> >>> >
> >> >> >> >>> > This is not much different than the static interface you
> >> >> >> proposed,
> >> >> >> >>> > right?
> >> >> >> >>> >
> >> >> >> >>> > > And then, when a service developer defines the
> >> >> >> AccountService,
> >> >> >> >>> he will
> >> >> >> >>> >
> >> >> >> >>> > > have
> >> >> >> >>> > > to know about yet another service, about how DAS works,
> >> >> >> how it is
> >> >> >> >>> > > configured, etc, etc... is that right ?
> >> >> >> >>> > >
> >> >> >> >>> > The abilities of the service are defined by the DAS config
> >> >> >> file.
> >> >> >> >>> So,
> >> >> >> >>> > the person or tool that provides the config file must
> >> >> >> understand
> >> >> >> >>> how the
> >> >> >> >>> >
> >> >> >> >>> > RDB DAS APIs work. There is no getting around this.
> >> >> >> >>> >
> >> >> >> >>> > > My proposal was going more towards allowing the service
> >> >> >> >>> developer to
> >> >> >> >>> > > focus
> >> >> >> >>> > > on defining the service, and let the "declarative das" to
> >> >> >> >>> handle the
> >> >> >> >>> > > persistent layer....
> >> >> >> >>> > >
> >> >> >> >>> > The DAS config file is the declaration of an instance of
> the
> >> >> >> >>> DAS. That
> >> >> >> >>> > instance can be exposed as a dynamic or typed service/
> >> >> >> interface.
> >> >> >> >>> That
> >> >> >> >>> > seems to be the main discussion we are having. Although, I
> >> >> >> may be
> >> >> >> >>> > missing something.
> >> >> >> >>> >
> >> >> >> >>> > > Also, by defining some conventions over configuration
> >> >> >> and/or using
> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
> >> >> >> >>> procedure),
> >> >> >> >>> > the
> >> >> >> >>> > > service developer could really define a service that
> >> >> >> interacts
> >> >> >> >>> with a
> >> >> >> >>> > > RDB,
> >> >> >> >>> > > without having to code the service persistence layer.
> >> >> >> >>> > >
> >> >> >> >>> > There is a lot of potential for the use of annotations.
> >> >> >> >>> >
> >> >> >> >>> > >
> >> >> >> >>> > > - Luciano
> >> >> >> >>> > >
> >> >> >> >>> > >
> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
> >> >> >> >>> > >
> >> >> >> >>> > >>
> >> >> >> >>> > >> The real difference between the two approaches is that
> >> >> >> one is
> >> >> >> >>> "Typed"
> >> >> >> >>> > or
> >> >> >> >>> > >> static and the other is dynamic. I think both are
> needed
> >> >> >> but was
> >> >> >> >>> > >> suggesting that we start with dynamic since it is the
> >> most
> >> >> >> >>> flexible
> >> >> >> >>> > and
> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a static
> >> >> >> >>> capability.
> >> >> >> >>> > >>
> >> >> >> >>> > >> With either, the user does not need to know about
> >> >> >> traditional
> >> >> >> >>> > >> persistence frameworks. With the dynamic approach,
> >> however,
> >> >> >> >>> the user
> >> >> >> >>> > >> does need to know about the dynamic SDO API.
> >> >> >> >>> > >>
> >> >> >> >>> > >> So, with the static interface the user might write:
> >> >> >> >>> > >>
> >> >> >> >>> > >> List customers = accountService.getAllCustomers();
> >> >> >> >>> > >> String name =
> ((Customer)customers.get(0)).getName();
> >> >> >> >>> > >>
> >> >> >> >>> > >> The equivalent dynamic API might be:
> >> >> >> >>> > >>
> >> >> >> >>> > >> List customers =
> >> dasService.execute("getAllCustomers");
> >> >> >> >>> > >> String name =
> >> ((DataObject)customers.get(0)).getString
> >> >> >> >>> ("name");
> >> >> >> >>> > >>
> >> >> >> >>> > >> The first is probably a little easier for the
> application
> >> >> >> >>> developer
> >> >> >> >>> > but
> >> >> >> >>> > >> the second is much easier for the service developer.
> IMO,
> >> >> >> the
> >> >> >> >>> dynamic
> >> >> >> >>> > >> case is the best place to start and, again, we
> >> >> >> definitely will
> >> >> >> >>> want
> >> >> >> >>> > >> support for both.
> >> >> >> >>> > >>
> >> >> >> >>> > >> Thanks.
> >> >> >> >>> > >> --
> >> >> >> >>> > >> Kevin
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >> Jeremy Boynes wrote:
> >> >> >> >>> > >>
> >> >> >> >>> > >> > I think this would be useful but it seems more like a
> >> >> >> >>> traditional
> >> >> >> >>> > >> > persistence API than what Luciano was suggesting. With
> >> >> >> this
> >> >> >> >>> one a
> >> >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
> >> >> >> strings
> >> >> >> >>> etc.
> >> >> >> >>> > >> > just like they would if they were using raw JDBC or
> >> JPA.
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more
> about
> >> >> >> >>> expressing
> >> >> >> >>> > >> > high-level CRUD operations as operations on a service
> >> >> >> >>> interface:
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> public List getAllCustomers();
> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
> >> >> >> accountNumber);
> >> >> >> >>> > >> >>> }
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > which is all application level concepts rather
> >> >> >> than persistence
> >> >> >> >>> > level
> >> >> >> >>> > >> > concepts. I'd actually go a little further and put
> that
> >> >> >> >>> right into
> >> >> >> >>> > >> > the service contract:
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > public interface AccountService {
> >> >> >> >>> > >> > List<Customer> getAllCustomers();
> >> >> >> >>> > >> > Account getCustomerAccount(String accountNumber);
> >> >> >> >>> > >> > }
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
> >> >> >> standardized
> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
> >> configuration
> >> >> >> >>> would be
> >> >> >> >>> > >> > needed except to add this to the logical assembly:
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > <component name="AccountStore">
> >> >> >> >>> > >> > <implementation.das resource="MySQLDatabase"/>
> >> >> >> >>> > >> > </component>
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > With SCA's ability to translate service contracts,
> this
> >> >> >> >>> should be
> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
> >> >> >> regardless of
> >> >> >> >>> > whether
> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> >> >> >> running on
> >> >> >> a
> >> >> >> >>> > Java,
> >> >> >> >>> > >> > C++ or PHP platform.
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > The important thing here is that the client is
> >> >> >> isolated from
> >> >> >> >>> how
> >> >> >> >>> > the
> >> >> >> >>> > >> > DAS component is provided. We could have multiple
> >> >> >> declarative
> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and one that
> >> did
> >> >> >> >>> stuff
> >> >> >> >>> > with
> >> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
> >> >> >> altering
> >> >> >> >>> the
> >> >> >> >>> > >> > client at all/ they could switch to a custom coded
> >> version
> >> >> >> >>> written
> >> >> >> >>> > in
> >> >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > --
> >> >> >> >>> > >> > Jeremy
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >> 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 code specific to
> >> >> >> a new
> >> >> >> >>> > >> >> service. Instead, the service will be "instantiated"
> >> >> >> based
> >> >> >> >>> on the
> >> >> >> >>> >
> >> >> >> >>> > >> >> provided DAS config file. The service interface
> >> >> >> might look
> >> >> >> >>> like
> >> >> >> >>> > >> this:
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> public interface RDBDASService
> >> >> >> >>> > >> >> DataObject execute(String commandName);
> >> >> >> >>> > >> >> DataObject executeSQL(String abitrarySQL);
> >> >> >> >>> > >> >> void applyChanges(DataObject graphRoot);
> >> >> >> >>> > >> >> }
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> So, depending on the config file used to
> >> instantiate the
> >> >> >> >>> service,
> >> >> >> >>> > >> >> this interface could be used to return Customers/
> >> >> >> Accounts or
> >> >> >> >>> > >> >> Toasters. In fact, a lot could be achieved with no
> >> >> >> >>> > configuration at
> >> >> >> >>> > >> >> all by restricting use to: DataObject
> >> executeSQL(String
> >> >> >> >>> > >> abitrarySQL);
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
> >> >> >> >>> mod_mbox/ws-
> >> >> >> >>> > >> >>
> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> Once this was working it should be straightforward to
> >> >> >> build
> >> >> >> >>> more
> >> >> >> >>> > >> >> strongly typed services and possible put together
> some
> >> >> >> >>> generation
> >> >> >> >>> > >> >> tooling. We could also start looking at support for
> a
> >> >> >> more
> >> >> >> >>> > RESTFul
> >> >> >> >>> > >> >> interface.
> >> >> >> >>> > >> >> --
> >> >> >> >>> > >> >> Kevin
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> Luciano Resende wrote:
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>> Recently, people have been starting to talk about
> >> >> >> better DAS
> >> >> >> >>> > >> >>> integration
> >> >> >> >>> > >> >>> with DAS, and below are some threads on the subject
> :
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> msg08833.html
> >> >> >> >>> > >> >>>
> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> msg08923.html
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >> >> >>> msg09715.html
> >> >> >> >>> >
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
> >> >> >> what I'm
> >> >> >> >>> > >> >>> saying is not
> >> >> >> >>> > >> >>> yet available on SCA today.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Today, defining a service to work with a relational
> >> >> >> >>> database, you
> >> >> >> >>> > >> >>> will need
> >> >> >> >>> > >> >>> to code the persistence side of the service where
> >> CRUD
> >> >> >> >>> operations
> >> >> >> >>> > >> >>> to the
> >> >> >> >>> > >> >>> database will be done.
> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
> coding
> >> >> >> the
> >> >> >> >>> CRUD
> >> >> >> >>> > >> >>> operations on
> >> >> >> >>> > >> >>> the persistence layer would be avoided as much as
> >> >> >> possible.
> >> >> >> >>> > >> >>> The idea would be to have a more "declarative DAS"
> >> when
> >> >> >> >>> defining
> >> >> >> >>> > SCA
> >> >> >> >>> > >> >>> Services, so you would either use some Annotations
> >> >> >> or SCDL
> >> >> >> to
> >> >> >> >>> > >> have the
> >> >> >> >>> > >> >>> "declarative DAS" configuration inside it.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> I was thinking on something like....
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> SCDL Definition would look something like this :
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> <component name="AccountDataService">
> >> >> >> >>> > >> >>> <interface.java
> >> >> >> >>> > >> >>>
> >> >> >> class="bigbank.account.services.account.AccountService"/>
> >> >> >> >>> > >> >>> <implementation.das="dasConfig.properties"
> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >> >> >>> > >> >>> </component>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> The AccountService Interface would look like this
> >> >> >> (missing
> >> >> >> >>> any
> >> >> >> >>> > SCA
> >> >> >> >>> > >> >>> annotations):
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> public List getAllCustomers();
> >> >> >> >>> > >> >>> public Object getCustomerAccount(String
> >> >> >> accountNumber);
> >> >> >> >>> > >> >>> }
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> The DAS config would look like this, and would
> >> have the
> >> >> >> >>> > definition
> >> >> >> >>> > >> >>> for the
> >> >> >> >>> > >> >>> "all companies" command.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> <Config ...>
> >> >> >> >>> > >> >>> ...
> >> >> >> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
> >> >> >> bigbank"/>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select * from
> >> >> >> >>> CUSTOMERS"
> >> >> >> >>> > >> >>> kind="Select"/>
> >> >> >> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
> >> >> >> >>> accountNumber,
> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
> >> >> >> accountNumber = ?"
> >> >> >> >>> > >> >>> kind="Select" />
> >> >> >> >>> > >> >>> ...
> >> >> >> >>> > >> >>> </Config>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
> >> >> >> >>> > >> >>> - If a DAS config file is provided, based on the
> >> >> >> >>> > SCDL definition,
> >> >> >> >>> > >> we
> >> >> >> >>> > >> >>> would look for "DAS command" based on the name of
> the
> >> >> >> getter
> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> >> >> >> command)
> >> >> >> >>> > >> >>> - Otherwise, we would try to do a map directly to
> a
> >> >> >> >>> > >> stored procedure
> >> >> >> >>> > >> >>> - We could also have a way to force the mapping by
> >> >> >> using
> >> >> >> >>> > >> annotation
> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Mapping between method parameter and command
> >> parameter
> >> >> >> >>> > >> >>> - We would need to define a method for mapping the
> >> >> >> method
> >> >> >> >>> > >> >>> parameters to
> >> >> >> >>> > >> >>> the query paramters either based on position (
> >> e.gfirst
> >> >> >> >>> method
> >> >> >> >>> > >> >>> parameter
> >> >> >> >>> > >> >>> maps to the first command paramter), or we would do
> >> some
> >> >> >> >>> > mapping by
> >> >> >> >>> > >> >>> name
> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Note:
> >> >> >> >>> > >> >>> - A SCDL connection information would override the
> >> DAS
> >> >> >> >>> Config
> >> >> >> >>> > file
> >> >> >> >>> > >> >>> connection information.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Benefits
> >> >> >> >>> > >> >>> - It's All about simplicity and easy of use
> >> >> >> >>> > >> >>> - This would allow a user to define a service
> >> without
> >> >> >> >>> having to
> >> >> >> >>> >
> >> >> >> >>> > >> >>> explicitly having to code any Data Access related
> >> code.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Implementation approaches
> >> >> >> >>> > >> >>> - Utilizing DAS : This approach would start from
> >> the
> >> >> >> >>> current
> >> >> >> >>> > >> >>> Tuscany DAS
> >> >> >> >>> > >> >>> implementation, where functionality would be already
> >> >> >> >>> > available, but
> >> >> >> >>> > >> >>> the
> >> >> >> >>> > >> >>> service implementation would be tied to SDO and RDB
> >> >> >> as this
> >> >> >> >>> > is what
> >> >> >> >>> > >> >>> DAS
> >> >> >> >>> > >> >>> supports today.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> - Start simple and grow : We could start simple,
> by
> >> >> >> >>> having a
> >> >> >> >>> > >> simple
> >> >> >> >>> > >> >>> implementation based on JDBC and would return some
> >> >> >> simple
> >> >> >> >>> > >> >>> collection as a
> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
> >> could
> >> >> >> >>> give us
> >> >> >> >>> > a
> >> >> >> >>> > >> >>> quick
> >> >> >> >>> > >> >>> start to flush implementation details and get a
> >> proven
> >> >> >> >>> design,
> >> >> >> >>> > and
> >> >> >> >>> > >> >>> this
> >> >> >> >>> > >> >>> could get evolved to use a DAS that would support
> >> >> >> multiple
> >> >> >> >>> > backends
> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
> >> >> >> non- SDO
> >> >> >> >>> types
> >> >> >> >>> > >> as a
> >> >> >> >>> > >> >>> command
> >> >> >> >>> > >> >>> result.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Toughts ?
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> - Luciano
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
> >> wrote:
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> 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. Another thing we want to
> eventually
> >> >> >> >>> explore is
> >> >> >> >>> > >> >>>> exposing
> >> >> >> >>> > >> >>>> a DAS as REST-oriented services. As we have seen
> >> >> >> from the
> >> >> >> >>> > parent
> >> >> >> >>> > >> >>>> thread
> >> >> >> >>> > >> >>>> there are almost too many possible approaches.
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a service
> >> and
> >> >> >> >>> create a
> >> >> >> >>> > new
> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas). The
> >> main
> >> >> >> >>> reason
> >> >> >> >>> > has
> >> >> >> >>> > >> >>>> to do
> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
> >> >> >> >>> > Jeremy mentioned
> >> >> >> >>> > >> >>>> which
> >> >> >> >>> > >> >>>> is all about creating data access services
> >> >> >> >>> declaratively. A new
> >> >> >> >>> > >> >>>> component type and a service that we build by hand
> >> >> >> would be
> >> >> >> >>> > a good
> >> >> >> >>> > >> >>>> step
> >> >> >> >>> > >> >>>> in this direction.
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> >> >> interface like
> >> >> >> >>> > this:
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> public interface RDBDASService
> >> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >> >> >> >>> > >> >>>> DataObject execute(String commandName);
> >> >> >> >>> > >> >>>> DataObject executeSQL(String abitrarySQL);
> >> >> >> >>> > >> >>>> }
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> The service would be initialized with an optional
> >> >> >> RDB DAS
> >> >> >> >>> > >> config file
> >> >> >> >>> > >> >>>> that defines connection properties, a set of
> >> commands,
> >> >> >> >>> etc. So,
> >> >> >> >>> > >> >>>> different services implementing the same interface
> >> >> >> could be
> >> >> >> >>> > >> >>>> initialized
> >> >> >> >>> > >> >>>> from separate config files.
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> Eventually, we might want to build services like
> >> this:
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> public interface Customers_RDBDASService
> >> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >> >> >> >>> > >> >>>> DataObject getAllCustomersWithLastName
> >> (String
> >> >> >> >>> > lastName);
> >> >> >> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID
> >> (int
> >> >> >> >>> > customerId);
> >> >> >> >>> > >> >>>> }
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> But, for this to be very useful would probably
> >> require
> >> >> >> >>> some code
> >> >> >> >>> > >> >>>> generation tooling.
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> Thoughts?
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> --Kevin
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> Luciano Resende wrote:
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> >> >> >> declarative
> >> >> >> >>> > DAS and
> >> >> >> >>> > >> >>>> will be
> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
> >> >> >> >>> > >> >>>> >
> >> >> >> >>> > >> >>>> > - Luciano
> >> >> >> >>> > >> >>>> >
> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
> >> >> >> 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 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.
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
> >> >> >> >>> > should welcome
> >> >> >> >>> > >> it
> >> >> >> >>> > >> >>>> >> like we would any other contribution.
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >> >> 3) to access data through an application
> >> >> >> service with
> >> >> >> >>> > >> >>>> declarative
> >> >> >> >>> > >> >>>> >> >> implementation by DAS
> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
> >> >> >> >>> > >> >>>> >> --
> >> >> >> >>> > >> >>>> >> Jeremy
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >>
> >> >> >> >>>
> >> >> >>
> >> --------------------------------------------------------------------
> >> >> >> >>> > >> -
> >> >> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >>> unsubscribe@ws.apache.org
> >> >> >> >>> > >> >>>> >> For additional commands, e-mail:
> >> >> >> >>> > tuscany-dev-help@ws.apache.org
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >>
> >> >> >> >>>
> >> >> >>
> >> --------------------------------------------------------------------
> >> >> >> >>> > >> -
> >> >> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> >>> unsubscribe@ws.apache.org
> >> >> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
> >> >> >> >>> help@ws.apache.org
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
> >> >> >> >>> help@ws.apache.org
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
> >> >> >> help@ws.apache.org
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >> unsubscribe@ws.apache.org
> >> >> >> >>> > >> For additional commands, e-mail: tuscany-dev-
> >> >> >> help@ws.apache.org
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >>> > To unsubscribe, e-mail:
> >> tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >>> > For additional commands, e-mail:
> >> tuscany-dev-help@ws.apache.org
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> >>> For additional commands, e-mail:
> >> tuscany-dev-help@ws.apache.org
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Kevin Williams <ke...@qwest.net>.
Hi Amita,
This is looking good. Some comments inline:
Amita Vadhavkar wrote:
> Hi,
> I am trying to create a container for DAS-SCA too (not just for stored
> procedure) and will be able to send a working code in ML over the
> weekend.
>
> Below is summary of what I got so far from the previous mail
> discussions and
> some questions.
>
>
> The integration between DAS and SCA can happen at application level as
> service or at container level.
>
>
>
> 2 different possible approaches –
>
> static – e.g. getAllCustomers
>
> dynamic – e.g. execute("all customers");
>
>
>
> For application level service – it is the sample *
> sample-StoredProcedureService.jar* or what Luciano is providing in more
> details, is an example. In *sample-StoredProcedureService.jar* example
> dynamic approach is followed
>
>
>
> For container approach – again static or dynamic approach can be
> followed.
> For static – it's like providing service for getAllCompanies(),
> getAllCustomers() etc. whereas for dynamic its like execute(command)
> where
> command can be "getAllCompanies", "getAllCustomers". Etc.
>
>
>
> I am working on a container implementation where dynamic
> approach is followed.
>
If I understand correctly, the container approach will provide the
tightest integration with SCA and make things easier for end-users. Do
you agree?
>
>
> There are 2 places where extensibility is required –
>
> 1) for providing different data access mechanisms. i.e. today
> there is
> RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
> scdl will
> be same, but the exampleconfig.xml will change.
>
> In the container I am working on - Scdl has a new tag
>
> Scdl has a new tag
> <da:implementation.da script="customersOrders/CustomersOrders.xml"
> dataAccessType="rdb"/>
>
>
>
> Here, dataAccessType – is the key which tells whether it's RDB or
> something
> else. And the xml script provides the connection and data store details.
>
>
>
> 2) for RDB-DAS – providing support for different databases (this
> portion should be part of DAS and not SCA.) In the current container
> I am
> working on it is provided as a package -
> org.apache.tuscany.container.dataaccessshelper package - which should
> finally go into DAS codeline(?).
>
>
Currently, there are two ways to specify a particular database: first,
the user can pass a JDBC Connection to the DAS Factory when creating a
DAS instance. The second is that a DataSource can be specified in the
DAS Config xml file in which case the DAS is responsible for getting the
connection.
>
>
>
> For static approach we may need some code generation tooling.
Right. That is why I think it best to start with dynamic. But, we will
want static support as well.
> Also could not
> understand how this can be merged into RESTful interfaces. (this was
> mentioned in some mail conversation)
>
>
>
> Regards,
>
> Amita
>
>
> On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>
>>
>> Luciano Resende wrote:
>>
>> > Comments in-line...
>> >
>> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
>> >
>> >>
>> >>
>> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > I would also like to understand this a little better ... here I am
>> >> > thinking
>> >> > aloud and hope the others will help in getting my persceptions
>> >> > right...
>> >> >
>> >> > I guess firstly it is a question of how or where we want to
>> >> > position 'DAS
>> >> > Integration' in SCA. Is is something we want to integrate as the
>> >> > Application Layer, which I understand is what Amita is trying
>> >> > presently and
>> >> > which Jim refers to as component implementation. In this option
>> >> > we get to
>> >> > do some sort of a service wrapper to DAS and then it becomes a
>> >> > demonstration
>> >> > of two Tuscany subprojects integrating at application level.
>> >> >
>> >
>> >
>> >
>> > Yes, I think we have space to position DAS both ways, and integrating
>> > in the
>> > application layer by exposing DAS as a service would be a very easy
>> and
>> > quick, this could be exposed as a sample app, and could show we are
>> > working
>> > on getting a better integration between DAS and SCA
>> >
>> >
>> >> Or do we want to position DAS at the infrastructure layer as another
>> >> > extension type (either container or binding). I guess this is
>> >> > where Ant
>> >> > started this - proposing a JDBC container / binding for component
>> >> > implementation in StoredProcedures.
>> >> I was thinking a DAS was a way to declaratively model heterogeneous
>> >> data as a service and offer a mechanism for remoting that data. In
>> >> other words, it provided the ability for an application to perform
>> >> CRUD using a high-level contract (interface) and having those
>> >> operations take place across a service network. How this is hooked
>> >> into the SCA container is probably best done as an extension type,
>> >> i.e. someone could specify:
>> >>
>> >> <component name="Foo">
>> >> <implementation.das>
>> >> <interface.java ....>
>> >> </implementation.das>
>> >> </component>
>> >
>> >
>> >
>> >
>> > Yes, this goes back to the way I was thinking on my original proposal.
>> >
>> >
>> >> If this is the path we should take
>> >> > then we probably have to think beyond DAS - to something more
>> >> > general - of
>> >> > which DAS is just a special case. I suppose this is what Jim has
>> also
>> >> > suggested in trying to explore other persistence mechanisms.
>> >> >
>> >> This may be the crux of the confusion. I was thinking DAS provides a
>> >> general mechanism for accessing heterogeneous data and is only right
>> >> now tied to SQL because of resource constraints (i.e. we have to
>> >> start somewhere). Ultimately, DAS should provide the infrastructure
>> >> for dealing with multiple, varied data stores and mechanisms for
>> >> querying across them. In other words, I guess I am saying DAS should
>> >> be the general solution (declarative and heterogeneous) since if it
>> >> is only a programmatic way to access relational data then its value
>> >> is less clear in comparison to things such as JDBC 4 or JPA.
>> >
>> >
>> >
>> >
>> > Yes, the current status of DAS implementation is RDB only. I would say
>> > that,
>> > in the future, I'd like to see a heterogeneous DAS that would give you
>> > access to different data stores, and probably support non-SDO types as
>> > well.
>> >
>> >> I too feel that this is something that must be done as an extension
>> >> > type -
>> >> > but yet to get my hands on the general scheme of things that DAS
>> >> > can slip
>> >> > into. Infact the other thread where Jeremy has taken forward a
>> >> > proposal to
>> >> > the specs group on resources tempts me to think that there is going
>> >> > to be
>> >> > something in that which we can leverage from.
>> >> >
>> >> I think resources are orthogonal as they are about a component
>> >> implementation's contract with its container. Declarative data
>> >> services on the other hand are about application constructs that can
>> >> be wired to.
>> >>
>> >> > I hope to get a better understanding this as we go along in this
>> >> > thread :)
>> >> >
>> >> Me too :-) As soon as I have trouble explaining technologies to .NET
>> >> people and they say "you Unix/Java people are at it again with a
>> >> thousand ways to do the same exact thing" it causes me to think that
>> >> maybe we need to clarify our message.
>> >
>> >
>> >
>> >
>> > If we all think it would be useful, I could try to summarize the
>> > thread on
>> > the wiki with a more clean proposal incorporating all your feedback ,
>> > what
>> > you guys think ?
>>
>> Yes. Great idea.
>>
>> >
>> >
>> > Jim
>> >
>> >> > Thanks
>> >> >
>> >> > - Venkat
>> >> >
>> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >>
>> >> >> Jim Marino wrote:
>> >> >>
>> >> >> > When I first read the thread on this, I thought the DAS service
>> >> >> would
>> >> >> > be a component extension type (e.g. analogous to a
>> >> >> > implementation.java or implementation.ejb) and not a component
>> >> >> > implementation type, which would allow for dynamic and
>> eventually
>> >> >> > declarative configuration styles.
>> >> >>
>> >> >> I have not very familiar with the terminology so I am not sure
>> what
>> a
>> >> >> "component extension type" is. But, I do think we eventually want
>> >> >> "implementation.rdbdas". Wouldn't this be a new implementation
>> type?
>> >> >>
>> >> >> It looks like Amita chose to start with a POJO. I notice the use
>> >> >> of "
>> >> >> implementation.java".
>> >> >>
>> >> >> > Either way, though, I am curious as to why
>> >> >> >
>> >> >> > public DAS configureService(String configFile);
>> >> >> >
>> >> >> > exists as part of the service definition? If the DAS service
>> was a
>> >> >> > component extension type, it could be handled as part of the
>> >> >> > application bootstrap. If the DAS service was a component
>> >> >> > implementation type, the configuration file URI could be passed
>> >> >> in as
>> >> >> > a property and then processed in an initializer method decorated
>> by
>> >> >> > the SCA @Init annotation. In the latter case, if the
>> implementation
>> >> >> > of DASService thread-safe (hopefully it is since configuration
>> >> >> would
>> >> >> > seem to be a heavyweight operation), then I would make the
>> >> >> component
>> >> >> > module scoped to avoid initialization overhead on every
>> resolution.
>> >> >>
>> >> >> >
>> >> >> > In both approaches (extension vs. implementation type), having
>> >> >> > configuration exposed to the application doesn't quite feel
>> right,
>> >> >> > since that is what DI tries to externalize.
>> >> >>
>> >> >> I agree. The configuration should be part of the
>> initialization and
>> >> >> should use SCA patterns to do this. I think that Amita meant
>> to use
>> >> >> eventually use a component property for the DAS config info but
>> >> >> started
>> >> >> with a method.
>> >> >>
>> >> >> >
>> >> >> > Also, I was thinking that in having this a component extension
>> >> >> type,
>> >> >> > the service interfaces returned from a resolution could include
>> the
>> >> >> > dynamic one described below or static ones people have
>> mentioned.
>> I
>> >> >> > guess it is best to start with the easier-to-implement part
>> >> >> first and
>> >> >> > support the dynamic interface.
>> >> >> >
>> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
>> >> >> > understand what DAS provides in relation to other persistence
>> >> >> > technologies. Outside of the Java world, Microsoft is promoting
>> >> >> LINQ
>> >> >> > which is really interesting, and it would be informative to
>> compare
>> >> >> > the goals of DAS with that approach (there are obvious
>> differences
>> >> >> > such as having the query language a strongly-typed part of the
>> >> >> > programming language, e.g. C#, and LINQ's use of closures).
>> >> >> >
>> >> >> > In contrasting DAS to O-R technologies, I see the primary use
>> cases
>> >> >> > for the former being a quick way to issue a query that may be
>> >> >> > executed against *heterogeneous* data stores and have that data
>> >> >> flow
>> >> >> > remotely or to a client that is not necessarily Java-based. One
>> key
>> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
>> >> >> (Hibernate
>> >> >> > and JPA are about as easy):
>> >> >> >
>> >> >> IMO the primary use case for DAS is an application that is SDO-
>> >> >> centric
>> >> >> and is taking advantage of its disconnected capabilities. The RDB
>> >> >> DAS
>> >> >> is built to work with SDO and uses the change summary to drive
>> >> >> changes
>> >> >> made to a disconnected data graph back to some store. This is not
>> to
>> >> >> say that a relational DAS could not be built on top of JPA, in
>> fact,
>> >> >> this might be a very useful thing to do. The implementation we
>> >> >> currently have provides a very straightforward implicit mapping
>> from
>> >> >> DataObjects to Tables. If more capable mapping is needed then it
>> >> >> makes
>> >> >> sense to use the JPA-defined technology and artifacts. A modified
>> >> >> Entity manager might be needed to take advantage of SDO's change
>> >> >> summary.
>> >> >>
>> >> >> >
>> >> >> > public interface CustomerDao extends BaseQuery {
>> >> >> > @Select("select * from customers where city = ?1")
>> >> >> > DataSet<Customer> findCustomersFrom(String city);
>> >> >> > }
>> >> >> >
>> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
>> >> >> > (CustomerDao.class, datasource);
>> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
>> >> >> >
>> >> >> >
>> >> >> > The other key is remote data and change lists. I think there
>> are
>> >> >> > (literally) about a thousand ways that already exist to
>> handle the
>> >> >> > "local" data case. For change lists, interop with ADO.NET's
>> change
>> >> >> > summary facilities would be interesting.
>> >> >>
>> >> >> I agree. Also, it looks like Xcalia may have a similar thought:
>> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
>> >> >>
>> >> >> >
>> >> >> > I'm playing devil's advocate a bit with DAS, but I think it is
>> >> >> > important we have a clear statement as to when it is appropriate
>> >> >> and
>> >> >> > not appropriate to use. One place to start would be to compare
>> >> >> it to
>> >> >> > JDBC 4 and JPA.
>> >> >>
>> >> >> We can get started with JPA:
>> >> >>
>> >> >> * JPA is java-specific, container-based, built around a
>> connected
>> >> >> data model and offers a complete O/R mapping for POJOs
>> >> >>
>> >> >> * The RDB DAS is a java implementation of a language - neutral
>> >> >> concept (hopefully specified some day) that is
>> containerless,
>> >> >> assumes a disconnected data model and provides a simple,
>> >> >> implicit
>> >> >> mapping for SDO DataObjects (Dynamic or Static) to
>> relational
>> >> >> tables.
>> >> >>
>> >> >> Anything else?
>> >> >>
>> >> >> >
>> >> >> > Jim
>> >> >> >
>> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>> >> >> >
>> >> >> >> Hi Amita
>> >> >> >>
>> >> >> >> I think we were both going on the same way, with the DAS
>> Service
>> >> >> >> sample,
>> >> >> >> altough i had the interface more like this, to be more
>> flexible :
>> >> >> >>
>> >> >> >> public interface DASService {
>> >> >> >>
>> >> >> >> public DAS configureService(String configFile);
>> >> >> >
>> >> >> >
>> >> >> >> public DataObject executeCommand(String commandName);
>> >> >> >> public DataObject execute(String newCommand);
>> >> >> >> public void applyChanges(DataObject graphRoot);
>> >> >> >> }
>> >> >> >>
>> >> >> >>
>> >> >> >> As for having it as a sample, maybe we could defined the
>> >> >> DASService
>> >> >> >> as one
>> >> >> >> sample itself, and have a second version of companyWeb that
>> would
>> >> >> >> consume
>> >> >> >> the service, something like :
>> >> >> >>
>> >> >> >> das\samples\companyWeb
>> >> >> >> das\samples\dasService
>> >> >> >> das\samples.companyWeb.service
>> >> >> >>
>> >> >> >> or, more like BigBank
>> >> >> >>
>> >> >> >> das\samples\companyweb.Service\dasService
>> >> >> >> das\samples\companyweb.Service\webClient
>> >> >> >>
>> >> >> >> Or even in sampleApps...
>> >> >> >>
>> >> >> >> Toughts ?
>> >> >> >>
>> >> >> >>
>> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
>> >> >> >>
>> >> >> >>>
>> >> >> >>> Hi ,
>> >> >> >>> I am also following up another thread
>> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> msg09944.html
>> >> >> >>> on the
>> >> >> >>> similar issue (JDBC stored procedure container
>> >> >> >>> using DAS)
>> >> >> >>> Besides the fact that I am actively working on the container
>> >> >> work,
>> >> >> >>> I also
>> >> >> >>> have tried to
>> >> >> >>> develop a sample based on the below discussion, following
>> dynamic
>> >> >> >>> approach.
>> >> >> >>>
>> >> >> >>> I am attaching the same here. Please take a look and give your
>> >> >> >>> suggestions.
>> >> >> >>> In this, StoredProcedureService implementation has
>> >> >> setConfigInfo (DAS
>> >> >> >>> Config) and
>> >> >> >>> execute(Any SQL). This can be made more complete with
>> >> >> executeSQL(),
>> >> >> >>> applyChanges()
>> >> >> >>> etc.
>> >> >> >>>
>> >> >> >>> Can this be added to the existing set of samples?
>> >> >> >>>
>> >> >> >>> Regards,
>> >> >> >>> Amita
>> >> >> >>>
>> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >>> >
>> >> >> >>> > Luciano Resende wrote:
>> >> >> >>> >
>> >> >> >>> > > Kevin, from what I understood from your suggestion, it was
>> >> >> >>> looking to
>> >> >> >>> > me
>> >> >> >>> > > more like exposing DAS as a service :
>> >> >> >>> > >
>> >> >> >>> > >>> public interface RDBDASService
>> >> >> >>> > >>> DataObject execute(String commandName);
>> >> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
>> >> >> >>> > >>> void applyChanges(DataObject graphRoot);
>> >> >> >>> > >>> }
>> >> >> >>> > >>
>> >> >> >>> > Yes, I am talking about exposing a DAS Service configured
>> >> >> with a
>> >> >> >>> > specific set of capabilities/commands defined in the DAS
>> config
>> >> >> >>> file.
>> >> >> >>> > So, if the implementation of the service interface above was
>> >> >> >>> configured
>> >> >> >>> > to work with Customers they would use the service like this:
>> >> >> >>> >
>> >> >> >>> > List customers = myRDBDASService.execute
>> ("getAllCustomers");
>> >> >> >>> > String name = customers.get(0).getString("name");
>> >> >> >>> >
>> >> >> >>> > This is not much different than the static interface you
>> >> >> proposed,
>> >> >> >>> > right?
>> >> >> >>> >
>> >> >> >>> > > And then, when a service developer defines the
>> >> >> AccountService,
>> >> >> >>> he will
>> >> >> >>> >
>> >> >> >>> > > have
>> >> >> >>> > > to know about yet another service, about how DAS works,
>> >> >> how it is
>> >> >> >>> > > configured, etc, etc... is that right ?
>> >> >> >>> > >
>> >> >> >>> > The abilities of the service are defined by the DAS config
>> >> >> file.
>> >> >> >>> So,
>> >> >> >>> > the person or tool that provides the config file must
>> >> >> understand
>> >> >> >>> how the
>> >> >> >>> >
>> >> >> >>> > RDB DAS APIs work. There is no getting around this.
>> >> >> >>> >
>> >> >> >>> > > My proposal was going more towards allowing the service
>> >> >> >>> developer to
>> >> >> >>> > > focus
>> >> >> >>> > > on defining the service, and let the "declarative das" to
>> >> >> >>> handle the
>> >> >> >>> > > persistent layer....
>> >> >> >>> > >
>> >> >> >>> > The DAS config file is the declaration of an instance of the
>> >> >> >>> DAS. That
>> >> >> >>> > instance can be exposed as a dynamic or typed service/
>> >> >> interface.
>> >> >> >>> That
>> >> >> >>> > seems to be the main discussion we are having. Although, I
>> >> >> may be
>> >> >> >>> > missing something.
>> >> >> >>> >
>> >> >> >>> > > Also, by defining some conventions over configuration
>> >> >> and/or using
>> >> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
>> >> >> >>> procedure),
>> >> >> >>> > the
>> >> >> >>> > > service developer could really define a service that
>> >> >> interacts
>> >> >> >>> with a
>> >> >> >>> > > RDB,
>> >> >> >>> > > without having to code the service persistence layer.
>> >> >> >>> > >
>> >> >> >>> > There is a lot of potential for the use of annotations.
>> >> >> >>> >
>> >> >> >>> > >
>> >> >> >>> > > - Luciano
>> >> >> >>> > >
>> >> >> >>> > >
>> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
>> >> >> >>> > >
>> >> >> >>> > >>
>> >> >> >>> > >> The real difference between the two approaches is that
>> >> >> one is
>> >> >> >>> "Typed"
>> >> >> >>> > or
>> >> >> >>> > >> static and the other is dynamic. I think both are needed
>> >> >> but was
>> >> >> >>> > >> suggesting that we start with dynamic since it is the
>> most
>> >> >> >>> flexible
>> >> >> >>> > and
>> >> >> >>> > >> seems to be a reasonable stepping stone towards a static
>> >> >> >>> capability.
>> >> >> >>> > >>
>> >> >> >>> > >> With either, the user does not need to know about
>> >> >> traditional
>> >> >> >>> > >> persistence frameworks. With the dynamic approach,
>> however,
>> >> >> >>> the user
>> >> >> >>> > >> does need to know about the dynamic SDO API.
>> >> >> >>> > >>
>> >> >> >>> > >> So, with the static interface the user might write:
>> >> >> >>> > >>
>> >> >> >>> > >> List customers = accountService.getAllCustomers();
>> >> >> >>> > >> String name = ((Customer)customers.get(0)).getName();
>> >> >> >>> > >>
>> >> >> >>> > >> The equivalent dynamic API might be:
>> >> >> >>> > >>
>> >> >> >>> > >> List customers =
>> dasService.execute("getAllCustomers");
>> >> >> >>> > >> String name =
>> ((DataObject)customers.get(0)).getString
>> >> >> >>> ("name");
>> >> >> >>> > >>
>> >> >> >>> > >> The first is probably a little easier for the application
>> >> >> >>> developer
>> >> >> >>> > but
>> >> >> >>> > >> the second is much easier for the service developer. IMO,
>> >> >> the
>> >> >> >>> dynamic
>> >> >> >>> > >> case is the best place to start and, again, we
>> >> >> definitely will
>> >> >> >>> want
>> >> >> >>> > >> support for both.
>> >> >> >>> > >>
>> >> >> >>> > >> Thanks.
>> >> >> >>> > >> --
>> >> >> >>> > >> Kevin
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >> Jeremy Boynes wrote:
>> >> >> >>> > >>
>> >> >> >>> > >> > I think this would be useful but it seems more like a
>> >> >> >>> traditional
>> >> >> >>> > >> > persistence API than what Luciano was suggesting. With
>> >> >> this
>> >> >> >>> one a
>> >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
>> >> >> strings
>> >> >> >>> etc.
>> >> >> >>> > >> > just like they would if they were using raw JDBC or
>> JPA.
>> >> >> >>> > >> >
>> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more about
>> >> >> >>> expressing
>> >> >> >>> > >> > high-level CRUD operations as operations on a service
>> >> >> >>> interface:
>> >> >> >>> > >> >
>> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> public List getAllCustomers();
>> >> >> >>> > >> >>> public Object getCustomerAccount(String
>> >> >> accountNumber);
>> >> >> >>> > >> >>> }
>> >> >> >>> > >> >>
>> >> >> >>> > >> >
>> >> >> >>> > >> > which is all application level concepts rather
>> >> >> than persistence
>> >> >> >>> > level
>> >> >> >>> > >> > concepts. I'd actually go a little further and put that
>> >> >> >>> right into
>> >> >> >>> > >> > the service contract:
>> >> >> >>> > >> >
>> >> >> >>> > >> > public interface AccountService {
>> >> >> >>> > >> > List<Customer> getAllCustomers();
>> >> >> >>> > >> > Account getCustomerAccount(String accountNumber);
>> >> >> >>> > >> > }
>> >> >> >>> > >> >
>> >> >> >>> > >> > In a ideal world, if the user was able to accept
>> >> >> standardized
>> >> >> >>> > >> > mappings (a la Rails et al) then no further
>> configuration
>> >> >> >>> would be
>> >> >> >>> > >> > needed except to add this to the logical assembly:
>> >> >> >>> > >> >
>> >> >> >>> > >> > <component name="AccountStore">
>> >> >> >>> > >> > <implementation.das resource="MySQLDatabase"/>
>> >> >> >>> > >> > </component>
>> >> >> >>> > >> >
>> >> >> >>> > >> > With SCA's ability to translate service contracts, this
>> >> >> >>> should be
>> >> >> >>> > >> > callable from and deployable to any SCA runtime
>> >> >> regardless of
>> >> >> >>> > whether
>> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
>> >> >> running on
>> >> >> a
>> >> >> >>> > Java,
>> >> >> >>> > >> > C++ or PHP platform.
>> >> >> >>> > >> >
>> >> >> >>> > >> > The important thing here is that the client is
>> >> >> isolated from
>> >> >> >>> how
>> >> >> >>> > the
>> >> >> >>> > >> > DAS component is provided. We could have multiple
>> >> >> declarative
>> >> >> >>> > >> > implementations, say one based on RDB-DAS and one that
>> did
>> >> >> >>> stuff
>> >> >> >>> > with
>> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
>> >> >> altering
>> >> >> >>> the
>> >> >> >>> > >> > client at all/ they could switch to a custom coded
>> version
>> >> >> >>> written
>> >> >> >>> > in
>> >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
>> >> >> >>> > >> >
>> >> >> >>> > >> > --
>> >> >> >>> > >> > Jeremy
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>> >> >> >>> > >> >
>> >> >> >>> > >> >> 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 code specific to
>> >> >> a new
>> >> >> >>> > >> >> service. Instead, the service will be "instantiated"
>> >> >> based
>> >> >> >>> on the
>> >> >> >>> >
>> >> >> >>> > >> >> provided DAS config file. The service interface
>> >> >> might look
>> >> >> >>> like
>> >> >> >>> > >> this:
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> public interface RDBDASService
>> >> >> >>> > >> >> DataObject execute(String commandName);
>> >> >> >>> > >> >> DataObject executeSQL(String abitrarySQL);
>> >> >> >>> > >> >> void applyChanges(DataObject graphRoot);
>> >> >> >>> > >> >> }
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> So, depending on the config file used to
>> instantiate the
>> >> >> >>> service,
>> >> >> >>> > >> >> this interface could be used to return Customers/
>> >> >> Accounts or
>> >> >> >>> > >> >> Toasters. In fact, a lot could be achieved with no
>> >> >> >>> > configuration at
>> >> >> >>> > >> >> all by restricting use to: DataObject
>> executeSQL(String
>> >> >> >>> > >> abitrarySQL);
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
>> >> >> >>> mod_mbox/ws-
>> >> >> >>> > >> >>
>> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> Once this was working it should be straightforward to
>> >> >> build
>> >> >> >>> more
>> >> >> >>> > >> >> strongly typed services and possible put together some
>> >> >> >>> generation
>> >> >> >>> > >> >> tooling. We could also start looking at support for a
>> >> >> more
>> >> >> >>> > RESTFul
>> >> >> >>> > >> >> interface.
>> >> >> >>> > >> >> --
>> >> >> >>> > >> >> Kevin
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> Luciano Resende wrote:
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>> Recently, people have been starting to talk about
>> >> >> better DAS
>> >> >> >>> > >> >>> integration
>> >> >> >>> > >> >>> with DAS, and below are some threads on the subject :
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> msg08833.html
>> >> >> >>> > >> >>>
>> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> msg08923.html
>> >> >> >>> > >> >>>
>> >> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> >> >> >>> msg09715.html
>> >> >> >>> >
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
>> >> >> what I'm
>> >> >> >>> > >> >>> saying is not
>> >> >> >>> > >> >>> yet available on SCA today.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Today, defining a service to work with a relational
>> >> >> >>> database, you
>> >> >> >>> > >> >>> will need
>> >> >> >>> > >> >>> to code the persistence side of the service where
>> CRUD
>> >> >> >>> operations
>> >> >> >>> > >> >>> to the
>> >> >> >>> > >> >>> database will be done.
>> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where coding
>> >> >> the
>> >> >> >>> CRUD
>> >> >> >>> > >> >>> operations on
>> >> >> >>> > >> >>> the persistence layer would be avoided as much as
>> >> >> possible.
>> >> >> >>> > >> >>> The idea would be to have a more "declarative DAS"
>> when
>> >> >> >>> defining
>> >> >> >>> > SCA
>> >> >> >>> > >> >>> Services, so you would either use some Annotations
>> >> >> or SCDL
>> >> >> to
>> >> >> >>> > >> have the
>> >> >> >>> > >> >>> "declarative DAS" configuration inside it.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> I was thinking on something like....
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> SCDL Definition would look something like this :
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> <component name="AccountDataService">
>> >> >> >>> > >> >>> <interface.java
>> >> >> >>> > >> >>>
>> >> >> class="bigbank.account.services.account.AccountService"/>
>> >> >> >>> > >> >>> <implementation.das="dasConfig.properties"
>> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> >> >> >>> > >> >>> </component>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> The AccountService Interface would look like this
>> >> >> (missing
>> >> >> >>> any
>> >> >> >>> > SCA
>> >> >> >>> > >> >>> annotations):
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> public List getAllCustomers();
>> >> >> >>> > >> >>> public Object getCustomerAccount(String
>> >> >> accountNumber);
>> >> >> >>> > >> >>> }
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> The DAS config would look like this, and would
>> have the
>> >> >> >>> > definition
>> >> >> >>> > >> >>> for the
>> >> >> >>> > >> >>> "all companies" command.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> <Config ...>
>> >> >> >>> > >> >>> ...
>> >> >> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
>> >> >> bigbank"/>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select * from
>> >> >> >>> CUSTOMERS"
>> >> >> >>> > >> >>> kind="Select"/>
>> >> >> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
>> >> >> >>> accountNumber,
>> >> >> >>> > >> >>> accountType, balance FROM accounts where
>> >> >> accountNumber = ?"
>> >> >> >>> > >> >>> kind="Select" />
>> >> >> >>> > >> >>> ...
>> >> >> >>> > >> >>> </Config>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
>> >> >> >>> > >> >>> - If a DAS config file is provided, based on the
>> >> >> >>> > SCDL definition,
>> >> >> >>> > >> we
>> >> >> >>> > >> >>> would look for "DAS command" based on the name of the
>> >> >> getter
>> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
>> >> >> command)
>> >> >> >>> > >> >>> - Otherwise, we would try to do a map directly to a
>> >> >> >>> > >> stored procedure
>> >> >> >>> > >> >>> - We could also have a way to force the mapping by
>> >> >> using
>> >> >> >>> > >> annotation
>> >> >> >>> > >> >>> (e.g@Procedure on the method level)
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Mapping between method parameter and command
>> parameter
>> >> >> >>> > >> >>> - We would need to define a method for mapping the
>> >> >> method
>> >> >> >>> > >> >>> parameters to
>> >> >> >>> > >> >>> the query paramters either based on position (
>> e.gfirst
>> >> >> >>> method
>> >> >> >>> > >> >>> parameter
>> >> >> >>> > >> >>> maps to the first command paramter), or we would do
>> some
>> >> >> >>> > mapping by
>> >> >> >>> > >> >>> name
>> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Note:
>> >> >> >>> > >> >>> - A SCDL connection information would override the
>> DAS
>> >> >> >>> Config
>> >> >> >>> > file
>> >> >> >>> > >> >>> connection information.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Benefits
>> >> >> >>> > >> >>> - It's All about simplicity and easy of use
>> >> >> >>> > >> >>> - This would allow a user to define a service
>> without
>> >> >> >>> having to
>> >> >> >>> >
>> >> >> >>> > >> >>> explicitly having to code any Data Access related
>> code.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Implementation approaches
>> >> >> >>> > >> >>> - Utilizing DAS : This approach would start from
>> the
>> >> >> >>> current
>> >> >> >>> > >> >>> Tuscany DAS
>> >> >> >>> > >> >>> implementation, where functionality would be already
>> >> >> >>> > available, but
>> >> >> >>> > >> >>> the
>> >> >> >>> > >> >>> service implementation would be tied to SDO and RDB
>> >> >> as this
>> >> >> >>> > is what
>> >> >> >>> > >> >>> DAS
>> >> >> >>> > >> >>> supports today.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> - Start simple and grow : We could start simple, by
>> >> >> >>> having a
>> >> >> >>> > >> simple
>> >> >> >>> > >> >>> implementation based on JDBC and would return some
>> >> >> simple
>> >> >> >>> > >> >>> collection as a
>> >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
>> could
>> >> >> >>> give us
>> >> >> >>> > a
>> >> >> >>> > >> >>> quick
>> >> >> >>> > >> >>> start to flush implementation details and get a
>> proven
>> >> >> >>> design,
>> >> >> >>> > and
>> >> >> >>> > >> >>> this
>> >> >> >>> > >> >>> could get evolved to use a DAS that would support
>> >> >> multiple
>> >> >> >>> > backends
>> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
>> >> >> non- SDO
>> >> >> >>> types
>> >> >> >>> > >> as a
>> >> >> >>> > >> >>> command
>> >> >> >>> > >> >>> result.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Toughts ?
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> - Luciano
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
>> wrote:
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> 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. Another thing we want to eventually
>> >> >> >>> explore is
>> >> >> >>> > >> >>>> exposing
>> >> >> >>> > >> >>>> a DAS as REST-oriented services. As we have seen
>> >> >> from the
>> >> >> >>> > parent
>> >> >> >>> > >> >>>> thread
>> >> >> >>> > >> >>>> there are almost too many possible approaches.
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> My first thought is to model the DAS as a service
>> and
>> >> >> >>> create a
>> >> >> >>> > new
>> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas). The
>> main
>> >> >> >>> reason
>> >> >> >>> > has
>> >> >> >>> > >> >>>> to do
>> >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
>> >> >> >>> > Jeremy mentioned
>> >> >> >>> > >> >>>> which
>> >> >> >>> > >> >>>> is all about creating data access services
>> >> >> >>> declaratively. A new
>> >> >> >>> > >> >>>> component type and a service that we build by hand
>> >> >> would be
>> >> >> >>> > a good
>> >> >> >>> > >> >>>> step
>> >> >> >>> > >> >>>> in this direction.
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> We might want to expose a DAS service with an
>> >> >> interface like
>> >> >> >>> > this:
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> public interface RDBDASService
>> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
>> >> >> >>> > >> >>>> DataObject execute(String commandName);
>> >> >> >>> > >> >>>> DataObject executeSQL(String abitrarySQL);
>> >> >> >>> > >> >>>> }
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> The service would be initialized with an optional
>> >> >> RDB DAS
>> >> >> >>> > >> config file
>> >> >> >>> > >> >>>> that defines connection properties, a set of
>> commands,
>> >> >> >>> etc. So,
>> >> >> >>> > >> >>>> different services implementing the same interface
>> >> >> could be
>> >> >> >>> > >> >>>> initialized
>> >> >> >>> > >> >>>> from separate config files.
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> Eventually, we might want to build services like
>> this:
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> public interface Customers_RDBDASService
>> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
>> >> >> >>> > >> >>>> DataObject getAllCustomersWithLastName
>> (String
>> >> >> >>> > lastName);
>> >> >> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID
>> (int
>> >> >> >>> > customerId);
>> >> >> >>> > >> >>>> }
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> But, for this to be very useful would probably
>> require
>> >> >> >>> some code
>> >> >> >>> > >> >>>> generation tooling.
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> Thoughts?
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> --Kevin
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> Luciano Resende wrote:
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
>> >> >> declarative
>> >> >> >>> > DAS and
>> >> >> >>> > >> >>>> will be
>> >> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
>> >> >> >>> > >> >>>> >
>> >> >> >>> > >> >>>> > - Luciano
>> >> >> >>> > >> >>>> >
>> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
>> >> >> 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 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.
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
>> >> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
>> >> >> >>> > should welcome
>> >> >> >>> > >> it
>> >> >> >>> > >> >>>> >> like we would any other contribution.
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >> >> 3) to access data through an application
>> >> >> service with
>> >> >> >>> > >> >>>> declarative
>> >> >> >>> > >> >>>> >> >> implementation by DAS
>> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
>> >> >> >>> > >> >>>> >> --
>> >> >> >>> > >> >>>> >> Jeremy
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >>
>> >> >> >>>
>> >> >>
>> --------------------------------------------------------------------
>> >> >> >>> > >> -
>> >> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >>> unsubscribe@ws.apache.org
>> >> >> >>> > >> >>>> >> For additional commands, e-mail:
>> >> >> >>> > tuscany-dev-help@ws.apache.org
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >>
>> >> >> >>>
>> >> >>
>> --------------------------------------------------------------------
>> >> >> >>> > >> -
>> >> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
>> >> >> >>> unsubscribe@ws.apache.org
>> >> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
>> >> >> >>> help@ws.apache.org
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> >
>> >> >> >>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> unsubscribe@ws.apache.org
>> >> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
>> >> >> >>> help@ws.apache.org
>> >> >> >>> > >> >>
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> >
>> >> >> >>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
>> >> >> unsubscribe@ws.apache.org
>> >> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
>> >> >> help@ws.apache.org
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> unsubscribe@ws.apache.org
>> >> >> >>> > >> For additional commands, e-mail: tuscany-dev-
>> >> >> help@ws.apache.org
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> > To unsubscribe, e-mail:
>> tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >>> > For additional commands, e-mail:
>> tuscany-dev-help@ws.apache.org
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> >>> For additional commands, e-mail:
>> tuscany-dev-help@ws.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>
>> >> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi,
I am trying to create a container for DAS-SCA too (not just for stored
procedure) and will be able to send a working code in ML over the weekend.
Below is summary of what I got so far from the previous mail discussions and
some questions.
The integration between DAS and SCA can happen at application level as
service or at container level.
2 different possible approaches –
static – e.g. getAllCustomers
dynamic – e.g. execute("all customers");
For application level service – it is the sample *
sample-StoredProcedureService.jar* or what Luciano is providing in more
details, is an example. In *sample-StoredProcedureService.jar* example
dynamic approach is followed
For container approach – again static or dynamic approach can be followed.
For static – it's like providing service for getAllCompanies(),
getAllCustomers() etc. whereas for dynamic its like execute(command) where
command can be "getAllCompanies", "getAllCustomers". Etc.
I am working on a container implementation where dynamic
approach is followed.
There are 2 places where extensibility is required –
1) for providing different data access mechanisms. i.e. today there is
RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the scdl will
be same, but the exampleconfig.xml will change.
In the container I am working on - Scdl has a new tag
Scdl has a new tag
<da:implementation.da script="customersOrders/CustomersOrders.xml"
dataAccessType="rdb"/>
Here, dataAccessType – is the key which tells whether it's RDB or something
else. And the xml script provides the connection and data store details.
2) for RDB-DAS – providing support for different databases (this
portion should be part of DAS and not SCA.) In the current container I am
working on it is provided as a package -
org.apache.tuscany.container.dataaccessshelper package - which should
finally go into DAS codeline(?).
For static approach we may need some code generation tooling. Also could not
understand how this can be merged into RESTful interfaces. (this was
mentioned in some mail conversation)
Regards,
Amita
On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Luciano Resende wrote:
>
> > Comments in-line...
> >
> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >>
> >>
> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> >>
> >> > Hi,
> >> >
> >> > I would also like to understand this a little better ... here I am
> >> > thinking
> >> > aloud and hope the others will help in getting my persceptions
> >> > right...
> >> >
> >> > I guess firstly it is a question of how or where we want to
> >> > position 'DAS
> >> > Integration' in SCA. Is is something we want to integrate as the
> >> > Application Layer, which I understand is what Amita is trying
> >> > presently and
> >> > which Jim refers to as component implementation. In this option
> >> > we get to
> >> > do some sort of a service wrapper to DAS and then it becomes a
> >> > demonstration
> >> > of two Tuscany subprojects integrating at application level.
> >> >
> >
> >
> >
> > Yes, I think we have space to position DAS both ways, and integrating
> > in the
> > application layer by exposing DAS as a service would be a very easy and
> > quick, this could be exposed as a sample app, and could show we are
> > working
> > on getting a better integration between DAS and SCA
> >
> >
> >> Or do we want to position DAS at the infrastructure layer as another
> >> > extension type (either container or binding). I guess this is
> >> > where Ant
> >> > started this - proposing a JDBC container / binding for component
> >> > implementation in StoredProcedures.
> >> I was thinking a DAS was a way to declaratively model heterogeneous
> >> data as a service and offer a mechanism for remoting that data. In
> >> other words, it provided the ability for an application to perform
> >> CRUD using a high-level contract (interface) and having those
> >> operations take place across a service network. How this is hooked
> >> into the SCA container is probably best done as an extension type,
> >> i.e. someone could specify:
> >>
> >> <component name="Foo">
> >> <implementation.das>
> >> <interface.java ....>
> >> </implementation.das>
> >> </component>
> >
> >
> >
> >
> > Yes, this goes back to the way I was thinking on my original proposal.
> >
> >
> >> If this is the path we should take
> >> > then we probably have to think beyond DAS - to something more
> >> > general - of
> >> > which DAS is just a special case. I suppose this is what Jim has
> also
> >> > suggested in trying to explore other persistence mechanisms.
> >> >
> >> This may be the crux of the confusion. I was thinking DAS provides a
> >> general mechanism for accessing heterogeneous data and is only right
> >> now tied to SQL because of resource constraints (i.e. we have to
> >> start somewhere). Ultimately, DAS should provide the infrastructure
> >> for dealing with multiple, varied data stores and mechanisms for
> >> querying across them. In other words, I guess I am saying DAS should
> >> be the general solution (declarative and heterogeneous) since if it
> >> is only a programmatic way to access relational data then its value
> >> is less clear in comparison to things such as JDBC 4 or JPA.
> >
> >
> >
> >
> > Yes, the current status of DAS implementation is RDB only. I would say
> > that,
> > in the future, I'd like to see a heterogeneous DAS that would give you
> > access to different data stores, and probably support non-SDO types as
> > well.
> >
> >> I too feel that this is something that must be done as an extension
> >> > type -
> >> > but yet to get my hands on the general scheme of things that DAS
> >> > can slip
> >> > into. Infact the other thread where Jeremy has taken forward a
> >> > proposal to
> >> > the specs group on resources tempts me to think that there is going
> >> > to be
> >> > something in that which we can leverage from.
> >> >
> >> I think resources are orthogonal as they are about a component
> >> implementation's contract with its container. Declarative data
> >> services on the other hand are about application constructs that can
> >> be wired to.
> >>
> >> > I hope to get a better understanding this as we go along in this
> >> > thread :)
> >> >
> >> Me too :-) As soon as I have trouble explaining technologies to .NET
> >> people and they say "you Unix/Java people are at it again with a
> >> thousand ways to do the same exact thing" it causes me to think that
> >> maybe we need to clarify our message.
> >
> >
> >
> >
> > If we all think it would be useful, I could try to summarize the
> > thread on
> > the wiki with a more clean proposal incorporating all your feedback ,
> > what
> > you guys think ?
>
> Yes. Great idea.
>
> >
> >
> > Jim
> >
> >> > Thanks
> >> >
> >> > - Venkat
> >> >
> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >>
> >> >> Jim Marino wrote:
> >> >>
> >> >> > When I first read the thread on this, I thought the DAS service
> >> >> would
> >> >> > be a component extension type (e.g. analogous to a
> >> >> > implementation.java or implementation.ejb) and not a component
> >> >> > implementation type, which would allow for dynamic and eventually
> >> >> > declarative configuration styles.
> >> >>
> >> >> I have not very familiar with the terminology so I am not sure what
> a
> >> >> "component extension type" is. But, I do think we eventually want
> >> >> "implementation.rdbdas". Wouldn't this be a new implementation
> type?
> >> >>
> >> >> It looks like Amita chose to start with a POJO. I notice the use
> >> >> of "
> >> >> implementation.java".
> >> >>
> >> >> > Either way, though, I am curious as to why
> >> >> >
> >> >> > public DAS configureService(String configFile);
> >> >> >
> >> >> > exists as part of the service definition? If the DAS service was a
> >> >> > component extension type, it could be handled as part of the
> >> >> > application bootstrap. If the DAS service was a component
> >> >> > implementation type, the configuration file URI could be passed
> >> >> in as
> >> >> > a property and then processed in an initializer method decorated
> by
> >> >> > the SCA @Init annotation. In the latter case, if the
> implementation
> >> >> > of DASService thread-safe (hopefully it is since configuration
> >> >> would
> >> >> > seem to be a heavyweight operation), then I would make the
> >> >> component
> >> >> > module scoped to avoid initialization overhead on every
> resolution.
> >> >>
> >> >> >
> >> >> > In both approaches (extension vs. implementation type), having
> >> >> > configuration exposed to the application doesn't quite feel right,
> >> >> > since that is what DI tries to externalize.
> >> >>
> >> >> I agree. The configuration should be part of the initialization and
> >> >> should use SCA patterns to do this. I think that Amita meant to use
> >> >> eventually use a component property for the DAS config info but
> >> >> started
> >> >> with a method.
> >> >>
> >> >> >
> >> >> > Also, I was thinking that in having this a component extension
> >> >> type,
> >> >> > the service interfaces returned from a resolution could include
> the
> >> >> > dynamic one described below or static ones people have mentioned.
> I
> >> >> > guess it is best to start with the easier-to-implement part
> >> >> first and
> >> >> > support the dynamic interface.
> >> >> >
> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> >> >> > understand what DAS provides in relation to other persistence
> >> >> > technologies. Outside of the Java world, Microsoft is promoting
> >> >> LINQ
> >> >> > which is really interesting, and it would be informative to
> compare
> >> >> > the goals of DAS with that approach (there are obvious differences
> >> >> > such as having the query language a strongly-typed part of the
> >> >> > programming language, e.g. C#, and LINQ's use of closures).
> >> >> >
> >> >> > In contrasting DAS to O-R technologies, I see the primary use
> cases
> >> >> > for the former being a quick way to issue a query that may be
> >> >> > executed against *heterogeneous* data stores and have that data
> >> >> flow
> >> >> > remotely or to a client that is not necessarily Java-based. One
> key
> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> >> (Hibernate
> >> >> > and JPA are about as easy):
> >> >> >
> >> >> IMO the primary use case for DAS is an application that is SDO-
> >> >> centric
> >> >> and is taking advantage of its disconnected capabilities. The RDB
> >> >> DAS
> >> >> is built to work with SDO and uses the change summary to drive
> >> >> changes
> >> >> made to a disconnected data graph back to some store. This is not
> to
> >> >> say that a relational DAS could not be built on top of JPA, in fact,
> >> >> this might be a very useful thing to do. The implementation we
> >> >> currently have provides a very straightforward implicit mapping from
> >> >> DataObjects to Tables. If more capable mapping is needed then it
> >> >> makes
> >> >> sense to use the JPA-defined technology and artifacts. A modified
> >> >> Entity manager might be needed to take advantage of SDO's change
> >> >> summary.
> >> >>
> >> >> >
> >> >> > public interface CustomerDao extends BaseQuery {
> >> >> > @Select("select * from customers where city = ?1")
> >> >> > DataSet<Customer> findCustomersFrom(String city);
> >> >> > }
> >> >> >
> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> >> > (CustomerDao.class, datasource);
> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >> >
> >> >> >
> >> >> > The other key is remote data and change lists. I think there are
> >> >> > (literally) about a thousand ways that already exist to handle the
> >> >> > "local" data case. For change lists, interop with ADO.NET's change
> >> >> > summary facilities would be interesting.
> >> >>
> >> >> I agree. Also, it looks like Xcalia may have a similar thought:
> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >> >>
> >> >> >
> >> >> > I'm playing devil's advocate a bit with DAS, but I think it is
> >> >> > important we have a clear statement as to when it is appropriate
> >> >> and
> >> >> > not appropriate to use. One place to start would be to compare
> >> >> it to
> >> >> > JDBC 4 and JPA.
> >> >>
> >> >> We can get started with JPA:
> >> >>
> >> >> * JPA is java-specific, container-based, built around a
> connected
> >> >> data model and offers a complete O/R mapping for POJOs
> >> >>
> >> >> * The RDB DAS is a java implementation of a language - neutral
> >> >> concept (hopefully specified some day) that is containerless,
> >> >> assumes a disconnected data model and provides a simple,
> >> >> implicit
> >> >> mapping for SDO DataObjects (Dynamic or Static) to relational
> >> >> tables.
> >> >>
> >> >> Anything else?
> >> >>
> >> >> >
> >> >> > Jim
> >> >> >
> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >> >
> >> >> >> Hi Amita
> >> >> >>
> >> >> >> I think we were both going on the same way, with the DAS Service
> >> >> >> sample,
> >> >> >> altough i had the interface more like this, to be more flexible :
> >> >> >>
> >> >> >> public interface DASService {
> >> >> >>
> >> >> >> public DAS configureService(String configFile);
> >> >> >
> >> >> >
> >> >> >> public DataObject executeCommand(String commandName);
> >> >> >> public DataObject execute(String newCommand);
> >> >> >> public void applyChanges(DataObject graphRoot);
> >> >> >> }
> >> >> >>
> >> >> >>
> >> >> >> As for having it as a sample, maybe we could defined the
> >> >> DASService
> >> >> >> as one
> >> >> >> sample itself, and have a second version of companyWeb that would
> >> >> >> consume
> >> >> >> the service, something like :
> >> >> >>
> >> >> >> das\samples\companyWeb
> >> >> >> das\samples\dasService
> >> >> >> das\samples.companyWeb.service
> >> >> >>
> >> >> >> or, more like BigBank
> >> >> >>
> >> >> >> das\samples\companyweb.Service\dasService
> >> >> >> das\samples\companyweb.Service\webClient
> >> >> >>
> >> >> >> Or even in sampleApps...
> >> >> >>
> >> >> >> Toughts ?
> >> >> >>
> >> >> >>
> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
> >> >> >>
> >> >> >>>
> >> >> >>> Hi ,
> >> >> >>> I am also following up another thread
> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> msg09944.html
> >> >> >>> on the
> >> >> >>> similar issue (JDBC stored procedure container
> >> >> >>> using DAS)
> >> >> >>> Besides the fact that I am actively working on the container
> >> >> work,
> >> >> >>> I also
> >> >> >>> have tried to
> >> >> >>> develop a sample based on the below discussion, following
> dynamic
> >> >> >>> approach.
> >> >> >>>
> >> >> >>> I am attaching the same here. Please take a look and give your
> >> >> >>> suggestions.
> >> >> >>> In this, StoredProcedureService implementation has
> >> >> setConfigInfo (DAS
> >> >> >>> Config) and
> >> >> >>> execute(Any SQL). This can be made more complete with
> >> >> executeSQL(),
> >> >> >>> applyChanges()
> >> >> >>> etc.
> >> >> >>>
> >> >> >>> Can this be added to the existing set of samples?
> >> >> >>>
> >> >> >>> Regards,
> >> >> >>> Amita
> >> >> >>>
> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >>> >
> >> >> >>> > Luciano Resende wrote:
> >> >> >>> >
> >> >> >>> > > Kevin, from what I understood from your suggestion, it was
> >> >> >>> looking to
> >> >> >>> > me
> >> >> >>> > > more like exposing DAS as a service :
> >> >> >>> > >
> >> >> >>> > >>> public interface RDBDASService
> >> >> >>> > >>> DataObject execute(String commandName);
> >> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
> >> >> >>> > >>> void applyChanges(DataObject graphRoot);
> >> >> >>> > >>> }
> >> >> >>> > >>
> >> >> >>> > Yes, I am talking about exposing a DAS Service configured
> >> >> with a
> >> >> >>> > specific set of capabilities/commands defined in the DAS
> config
> >> >> >>> file.
> >> >> >>> > So, if the implementation of the service interface above was
> >> >> >>> configured
> >> >> >>> > to work with Customers they would use the service like this:
> >> >> >>> >
> >> >> >>> > List customers = myRDBDASService.execute
> ("getAllCustomers");
> >> >> >>> > String name = customers.get(0).getString("name");
> >> >> >>> >
> >> >> >>> > This is not much different than the static interface you
> >> >> proposed,
> >> >> >>> > right?
> >> >> >>> >
> >> >> >>> > > And then, when a service developer defines the
> >> >> AccountService,
> >> >> >>> he will
> >> >> >>> >
> >> >> >>> > > have
> >> >> >>> > > to know about yet another service, about how DAS works,
> >> >> how it is
> >> >> >>> > > configured, etc, etc... is that right ?
> >> >> >>> > >
> >> >> >>> > The abilities of the service are defined by the DAS config
> >> >> file.
> >> >> >>> So,
> >> >> >>> > the person or tool that provides the config file must
> >> >> understand
> >> >> >>> how the
> >> >> >>> >
> >> >> >>> > RDB DAS APIs work. There is no getting around this.
> >> >> >>> >
> >> >> >>> > > My proposal was going more towards allowing the service
> >> >> >>> developer to
> >> >> >>> > > focus
> >> >> >>> > > on defining the service, and let the "declarative das" to
> >> >> >>> handle the
> >> >> >>> > > persistent layer....
> >> >> >>> > >
> >> >> >>> > The DAS config file is the declaration of an instance of the
> >> >> >>> DAS. That
> >> >> >>> > instance can be exposed as a dynamic or typed service/
> >> >> interface.
> >> >> >>> That
> >> >> >>> > seems to be the main discussion we are having. Although, I
> >> >> may be
> >> >> >>> > missing something.
> >> >> >>> >
> >> >> >>> > > Also, by defining some conventions over configuration
> >> >> and/or using
> >> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
> >> >> >>> procedure),
> >> >> >>> > the
> >> >> >>> > > service developer could really define a service that
> >> >> interacts
> >> >> >>> with a
> >> >> >>> > > RDB,
> >> >> >>> > > without having to code the service persistence layer.
> >> >> >>> > >
> >> >> >>> > There is a lot of potential for the use of annotations.
> >> >> >>> >
> >> >> >>> > >
> >> >> >>> > > - Luciano
> >> >> >>> > >
> >> >> >>> > >
> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
> >> >> >>> > >
> >> >> >>> > >>
> >> >> >>> > >> The real difference between the two approaches is that
> >> >> one is
> >> >> >>> "Typed"
> >> >> >>> > or
> >> >> >>> > >> static and the other is dynamic. I think both are needed
> >> >> but was
> >> >> >>> > >> suggesting that we start with dynamic since it is the most
> >> >> >>> flexible
> >> >> >>> > and
> >> >> >>> > >> seems to be a reasonable stepping stone towards a static
> >> >> >>> capability.
> >> >> >>> > >>
> >> >> >>> > >> With either, the user does not need to know about
> >> >> traditional
> >> >> >>> > >> persistence frameworks. With the dynamic approach,
> however,
> >> >> >>> the user
> >> >> >>> > >> does need to know about the dynamic SDO API.
> >> >> >>> > >>
> >> >> >>> > >> So, with the static interface the user might write:
> >> >> >>> > >>
> >> >> >>> > >> List customers = accountService.getAllCustomers();
> >> >> >>> > >> String name = ((Customer)customers.get(0)).getName();
> >> >> >>> > >>
> >> >> >>> > >> The equivalent dynamic API might be:
> >> >> >>> > >>
> >> >> >>> > >> List customers = dasService.execute("getAllCustomers");
> >> >> >>> > >> String name = ((DataObject)customers.get(0)).getString
> >> >> >>> ("name");
> >> >> >>> > >>
> >> >> >>> > >> The first is probably a little easier for the application
> >> >> >>> developer
> >> >> >>> > but
> >> >> >>> > >> the second is much easier for the service developer. IMO,
> >> >> the
> >> >> >>> dynamic
> >> >> >>> > >> case is the best place to start and, again, we
> >> >> definitely will
> >> >> >>> want
> >> >> >>> > >> support for both.
> >> >> >>> > >>
> >> >> >>> > >> Thanks.
> >> >> >>> > >> --
> >> >> >>> > >> Kevin
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >> Jeremy Boynes wrote:
> >> >> >>> > >>
> >> >> >>> > >> > I think this would be useful but it seems more like a
> >> >> >>> traditional
> >> >> >>> > >> > persistence API than what Luciano was suggesting. With
> >> >> this
> >> >> >>> one a
> >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
> >> >> strings
> >> >> >>> etc.
> >> >> >>> > >> > just like they would if they were using raw JDBC or JPA.
> >> >> >>> > >> >
> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more about
> >> >> >>> expressing
> >> >> >>> > >> > high-level CRUD operations as operations on a service
> >> >> >>> interface:
> >> >> >>> > >> >
> >> >> >>> > >> >>> public interface AccountService {
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> public List getAllCustomers();
> >> >> >>> > >> >>> public Object getCustomerAccount(String
> >> >> accountNumber);
> >> >> >>> > >> >>> }
> >> >> >>> > >> >>
> >> >> >>> > >> >
> >> >> >>> > >> > which is all application level concepts rather
> >> >> than persistence
> >> >> >>> > level
> >> >> >>> > >> > concepts. I'd actually go a little further and put that
> >> >> >>> right into
> >> >> >>> > >> > the service contract:
> >> >> >>> > >> >
> >> >> >>> > >> > public interface AccountService {
> >> >> >>> > >> > List<Customer> getAllCustomers();
> >> >> >>> > >> > Account getCustomerAccount(String accountNumber);
> >> >> >>> > >> > }
> >> >> >>> > >> >
> >> >> >>> > >> > In a ideal world, if the user was able to accept
> >> >> standardized
> >> >> >>> > >> > mappings (a la Rails et al) then no further configuration
> >> >> >>> would be
> >> >> >>> > >> > needed except to add this to the logical assembly:
> >> >> >>> > >> >
> >> >> >>> > >> > <component name="AccountStore">
> >> >> >>> > >> > <implementation.das resource="MySQLDatabase"/>
> >> >> >>> > >> > </component>
> >> >> >>> > >> >
> >> >> >>> > >> > With SCA's ability to translate service contracts, this
> >> >> >>> should be
> >> >> >>> > >> > callable from and deployable to any SCA runtime
> >> >> regardless of
> >> >> >>> > whether
> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> >> >> running on
> >> >> a
> >> >> >>> > Java,
> >> >> >>> > >> > C++ or PHP platform.
> >> >> >>> > >> >
> >> >> >>> > >> > The important thing here is that the client is
> >> >> isolated from
> >> >> >>> how
> >> >> >>> > the
> >> >> >>> > >> > DAS component is provided. We could have multiple
> >> >> declarative
> >> >> >>> > >> > implementations, say one based on RDB-DAS and one that
> did
> >> >> >>> stuff
> >> >> >>> > with
> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
> >> >> altering
> >> >> >>> the
> >> >> >>> > >> > client at all/ they could switch to a custom coded
> version
> >> >> >>> written
> >> >> >>> > in
> >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
> >> >> >>> > >> >
> >> >> >>> > >> > --
> >> >> >>> > >> > Jeremy
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >> >> >>> > >> >
> >> >> >>> > >> >> 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 code specific to
> >> >> a new
> >> >> >>> > >> >> service. Instead, the service will be "instantiated"
> >> >> based
> >> >> >>> on the
> >> >> >>> >
> >> >> >>> > >> >> provided DAS config file. The service interface
> >> >> might look
> >> >> >>> like
> >> >> >>> > >> this:
> >> >> >>> > >> >>
> >> >> >>> > >> >> public interface RDBDASService
> >> >> >>> > >> >> DataObject execute(String commandName);
> >> >> >>> > >> >> DataObject executeSQL(String abitrarySQL);
> >> >> >>> > >> >> void applyChanges(DataObject graphRoot);
> >> >> >>> > >> >> }
> >> >> >>> > >> >>
> >> >> >>> > >> >> So, depending on the config file used to instantiate the
> >> >> >>> service,
> >> >> >>> > >> >> this interface could be used to return Customers/
> >> >> Accounts or
> >> >> >>> > >> >> Toasters. In fact, a lot could be achieved with no
> >> >> >>> > configuration at
> >> >> >>> > >> >> all by restricting use to: DataObject executeSQL(String
> >> >> >>> > >> abitrarySQL);
> >> >> >>> > >> >>
> >> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
> >> >> >>> mod_mbox/ws-
> >> >> >>> > >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >> >> >>> > >> >>
> >> >> >>> > >> >> Once this was working it should be straightforward to
> >> >> build
> >> >> >>> more
> >> >> >>> > >> >> strongly typed services and possible put together some
> >> >> >>> generation
> >> >> >>> > >> >> tooling. We could also start looking at support for a
> >> >> more
> >> >> >>> > RESTFul
> >> >> >>> > >> >> interface.
> >> >> >>> > >> >> --
> >> >> >>> > >> >> Kevin
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >> Luciano Resende wrote:
> >> >> >>> > >> >>
> >> >> >>> > >> >>> Recently, people have been starting to talk about
> >> >> better DAS
> >> >> >>> > >> >>> integration
> >> >> >>> > >> >>> with DAS, and below are some threads on the subject :
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> msg08833.html
> >> >> >>> > >> >>>
> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> msg08923.html
> >> >> >>> > >> >>>
> >> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >> >>> msg09715.html
> >> >> >>> >
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
> >> >> what I'm
> >> >> >>> > >> >>> saying is not
> >> >> >>> > >> >>> yet available on SCA today.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Today, defining a service to work with a relational
> >> >> >>> database, you
> >> >> >>> > >> >>> will need
> >> >> >>> > >> >>> to code the persistence side of the service where CRUD
> >> >> >>> operations
> >> >> >>> > >> >>> to the
> >> >> >>> > >> >>> database will be done.
> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where coding
> >> >> the
> >> >> >>> CRUD
> >> >> >>> > >> >>> operations on
> >> >> >>> > >> >>> the persistence layer would be avoided as much as
> >> >> possible.
> >> >> >>> > >> >>> The idea would be to have a more "declarative DAS" when
> >> >> >>> defining
> >> >> >>> > SCA
> >> >> >>> > >> >>> Services, so you would either use some Annotations
> >> >> or SCDL
> >> >> to
> >> >> >>> > >> have the
> >> >> >>> > >> >>> "declarative DAS" configuration inside it.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> I was thinking on something like....
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> SCDL Definition would look something like this :
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> <component name="AccountDataService">
> >> >> >>> > >> >>> <interface.java
> >> >> >>> > >> >>>
> >> >> class="bigbank.account.services.account.AccountService"/>
> >> >> >>> > >> >>> <implementation.das="dasConfig.properties"
> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >> >>> > >> >>> </component>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> The AccountService Interface would look like this
> >> >> (missing
> >> >> >>> any
> >> >> >>> > SCA
> >> >> >>> > >> >>> annotations):
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> public interface AccountService {
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> public List getAllCustomers();
> >> >> >>> > >> >>> public Object getCustomerAccount(String
> >> >> accountNumber);
> >> >> >>> > >> >>> }
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> The DAS config would look like this, and would have the
> >> >> >>> > definition
> >> >> >>> > >> >>> for the
> >> >> >>> > >> >>> "all companies" command.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> <Config ...>
> >> >> >>> > >> >>> ...
> >> >> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
> >> >> bigbank"/>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select * from
> >> >> >>> CUSTOMERS"
> >> >> >>> > >> >>> kind="Select"/>
> >> >> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
> >> >> >>> accountNumber,
> >> >> >>> > >> >>> accountType, balance FROM accounts where
> >> >> accountNumber = ?"
> >> >> >>> > >> >>> kind="Select" />
> >> >> >>> > >> >>> ...
> >> >> >>> > >> >>> </Config>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
> >> >> >>> > >> >>> - If a DAS config file is provided, based on the
> >> >> >>> > SCDL definition,
> >> >> >>> > >> we
> >> >> >>> > >> >>> would look for "DAS command" based on the name of the
> >> >> getter
> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> >> >> command)
> >> >> >>> > >> >>> - Otherwise, we would try to do a map directly to a
> >> >> >>> > >> stored procedure
> >> >> >>> > >> >>> - We could also have a way to force the mapping by
> >> >> using
> >> >> >>> > >> annotation
> >> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Mapping between method parameter and command parameter
> >> >> >>> > >> >>> - We would need to define a method for mapping the
> >> >> method
> >> >> >>> > >> >>> parameters to
> >> >> >>> > >> >>> the query paramters either based on position ( e.gfirst
> >> >> >>> method
> >> >> >>> > >> >>> parameter
> >> >> >>> > >> >>> maps to the first command paramter), or we would do
> some
> >> >> >>> > mapping by
> >> >> >>> > >> >>> name
> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Note:
> >> >> >>> > >> >>> - A SCDL connection information would override the
> DAS
> >> >> >>> Config
> >> >> >>> > file
> >> >> >>> > >> >>> connection information.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Benefits
> >> >> >>> > >> >>> - It's All about simplicity and easy of use
> >> >> >>> > >> >>> - This would allow a user to define a service without
> >> >> >>> having to
> >> >> >>> >
> >> >> >>> > >> >>> explicitly having to code any Data Access related code.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Implementation approaches
> >> >> >>> > >> >>> - Utilizing DAS : This approach would start from the
> >> >> >>> current
> >> >> >>> > >> >>> Tuscany DAS
> >> >> >>> > >> >>> implementation, where functionality would be already
> >> >> >>> > available, but
> >> >> >>> > >> >>> the
> >> >> >>> > >> >>> service implementation would be tied to SDO and RDB
> >> >> as this
> >> >> >>> > is what
> >> >> >>> > >> >>> DAS
> >> >> >>> > >> >>> supports today.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> - Start simple and grow : We could start simple, by
> >> >> >>> having a
> >> >> >>> > >> simple
> >> >> >>> > >> >>> implementation based on JDBC and would return some
> >> >> simple
> >> >> >>> > >> >>> collection as a
> >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
> could
> >> >> >>> give us
> >> >> >>> > a
> >> >> >>> > >> >>> quick
> >> >> >>> > >> >>> start to flush implementation details and get a proven
> >> >> >>> design,
> >> >> >>> > and
> >> >> >>> > >> >>> this
> >> >> >>> > >> >>> could get evolved to use a DAS that would support
> >> >> multiple
> >> >> >>> > backends
> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
> >> >> non- SDO
> >> >> >>> types
> >> >> >>> > >> as a
> >> >> >>> > >> >>> command
> >> >> >>> > >> >>> result.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Toughts ?
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> - Luciano
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> 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. Another thing we want to eventually
> >> >> >>> explore is
> >> >> >>> > >> >>>> exposing
> >> >> >>> > >> >>>> a DAS as REST-oriented services. As we have seen
> >> >> from the
> >> >> >>> > parent
> >> >> >>> > >> >>>> thread
> >> >> >>> > >> >>>> there are almost too many possible approaches.
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> My first thought is to model the DAS as a service and
> >> >> >>> create a
> >> >> >>> > new
> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas). The main
> >> >> >>> reason
> >> >> >>> > has
> >> >> >>> > >> >>>> to do
> >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
> >> >> >>> > Jeremy mentioned
> >> >> >>> > >> >>>> which
> >> >> >>> > >> >>>> is all about creating data access services
> >> >> >>> declaratively. A new
> >> >> >>> > >> >>>> component type and a service that we build by hand
> >> >> would be
> >> >> >>> > a good
> >> >> >>> > >> >>>> step
> >> >> >>> > >> >>>> in this direction.
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> >> interface like
> >> >> >>> > this:
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> public interface RDBDASService
> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >> >> >>> > >> >>>> DataObject execute(String commandName);
> >> >> >>> > >> >>>> DataObject executeSQL(String abitrarySQL);
> >> >> >>> > >> >>>> }
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> The service would be initialized with an optional
> >> >> RDB DAS
> >> >> >>> > >> config file
> >> >> >>> > >> >>>> that defines connection properties, a set of commands,
> >> >> >>> etc. So,
> >> >> >>> > >> >>>> different services implementing the same interface
> >> >> could be
> >> >> >>> > >> >>>> initialized
> >> >> >>> > >> >>>> from separate config files.
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> Eventually, we might want to build services like this:
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> public interface Customers_RDBDASService
> >> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >> >> >>> > >> >>>> DataObject getAllCustomersWithLastName (String
> >> >> >>> > lastName);
> >> >> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID (int
> >> >> >>> > customerId);
> >> >> >>> > >> >>>> }
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> But, for this to be very useful would probably require
> >> >> >>> some code
> >> >> >>> > >> >>>> generation tooling.
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> Thoughts?
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> --Kevin
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> Luciano Resende wrote:
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> >> >> declarative
> >> >> >>> > DAS and
> >> >> >>> > >> >>>> will be
> >> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
> >> >> >>> > >> >>>> >
> >> >> >>> > >> >>>> > - Luciano
> >> >> >>> > >> >>>> >
> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
> >> >> 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 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.
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
> >> >> >>> > should welcome
> >> >> >>> > >> it
> >> >> >>> > >> >>>> >> like we would any other contribution.
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >> >> 3) to access data through an application
> >> >> service with
> >> >> >>> > >> >>>> declarative
> >> >> >>> > >> >>>> >> >> implementation by DAS
> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
> >> >> >>> > >> >>>> >> --
> >> >> >>> > >> >>>> >> Jeremy
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>>
> >> >> >>> > >>
> >> >> >>>
> >> >> --------------------------------------------------------------------
> >> >> >>> > >> -
> >> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> >>> unsubscribe@ws.apache.org
> >> >> >>> > >> >>>> >> For additional commands, e-mail:
> >> >> >>> > tuscany-dev-help@ws.apache.org
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>
> >> >> >>> > >>
> >> >> >>>
> >> >> --------------------------------------------------------------------
> >> >> >>> > >> -
> >> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
> >> >> >>> unsubscribe@ws.apache.org
> >> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
> >> >> >>> help@ws.apache.org
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> >
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
> >> >> unsubscribe@ws.apache.org
> >> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
> >> >> >>> help@ws.apache.org
> >> >> >>> > >> >>
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> >
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
> >> >> unsubscribe@ws.apache.org
> >> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
> >> >> help@ws.apache.org
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
> >> >> unsubscribe@ws.apache.org
> >> >> >>> > >> For additional commands, e-mail: tuscany-dev-
> >> >> help@ws.apache.org
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >>> > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Kevin Williams <ke...@qwest.net>.
Luciano Resende wrote:
> Comments in-line...
>
> On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
>
>>
>>
>> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
>>
>> > Hi,
>> >
>> > I would also like to understand this a little better ... here I am
>> > thinking
>> > aloud and hope the others will help in getting my persceptions
>> > right...
>> >
>> > I guess firstly it is a question of how or where we want to
>> > position 'DAS
>> > Integration' in SCA. Is is something we want to integrate as the
>> > Application Layer, which I understand is what Amita is trying
>> > presently and
>> > which Jim refers to as component implementation. In this option
>> > we get to
>> > do some sort of a service wrapper to DAS and then it becomes a
>> > demonstration
>> > of two Tuscany subprojects integrating at application level.
>> >
>
>
>
> Yes, I think we have space to position DAS both ways, and integrating
> in the
> application layer by exposing DAS as a service would be a very easy and
> quick, this could be exposed as a sample app, and could show we are
> working
> on getting a better integration between DAS and SCA
>
>
>> Or do we want to position DAS at the infrastructure layer as another
>> > extension type (either container or binding). I guess this is
>> > where Ant
>> > started this - proposing a JDBC container / binding for component
>> > implementation in StoredProcedures.
>> I was thinking a DAS was a way to declaratively model heterogeneous
>> data as a service and offer a mechanism for remoting that data. In
>> other words, it provided the ability for an application to perform
>> CRUD using a high-level contract (interface) and having those
>> operations take place across a service network. How this is hooked
>> into the SCA container is probably best done as an extension type,
>> i.e. someone could specify:
>>
>> <component name="Foo">
>> <implementation.das>
>> <interface.java ....>
>> </implementation.das>
>> </component>
>
>
>
>
> Yes, this goes back to the way I was thinking on my original proposal.
>
>
>> If this is the path we should take
>> > then we probably have to think beyond DAS - to something more
>> > general - of
>> > which DAS is just a special case. I suppose this is what Jim has also
>> > suggested in trying to explore other persistence mechanisms.
>> >
>> This may be the crux of the confusion. I was thinking DAS provides a
>> general mechanism for accessing heterogeneous data and is only right
>> now tied to SQL because of resource constraints (i.e. we have to
>> start somewhere). Ultimately, DAS should provide the infrastructure
>> for dealing with multiple, varied data stores and mechanisms for
>> querying across them. In other words, I guess I am saying DAS should
>> be the general solution (declarative and heterogeneous) since if it
>> is only a programmatic way to access relational data then its value
>> is less clear in comparison to things such as JDBC 4 or JPA.
>
>
>
>
> Yes, the current status of DAS implementation is RDB only. I would say
> that,
> in the future, I'd like to see a heterogeneous DAS that would give you
> access to different data stores, and probably support non-SDO types as
> well.
>
>> I too feel that this is something that must be done as an extension
>> > type -
>> > but yet to get my hands on the general scheme of things that DAS
>> > can slip
>> > into. Infact the other thread where Jeremy has taken forward a
>> > proposal to
>> > the specs group on resources tempts me to think that there is going
>> > to be
>> > something in that which we can leverage from.
>> >
>> I think resources are orthogonal as they are about a component
>> implementation's contract with its container. Declarative data
>> services on the other hand are about application constructs that can
>> be wired to.
>>
>> > I hope to get a better understanding this as we go along in this
>> > thread :)
>> >
>> Me too :-) As soon as I have trouble explaining technologies to .NET
>> people and they say "you Unix/Java people are at it again with a
>> thousand ways to do the same exact thing" it causes me to think that
>> maybe we need to clarify our message.
>
>
>
>
> If we all think it would be useful, I could try to summarize the
> thread on
> the wiki with a more clean proposal incorporating all your feedback ,
> what
> you guys think ?
Yes. Great idea.
>
>
> Jim
>
>> > Thanks
>> >
>> > - Venkat
>> >
>> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >>
>> >> Jim Marino wrote:
>> >>
>> >> > When I first read the thread on this, I thought the DAS service
>> >> would
>> >> > be a component extension type (e.g. analogous to a
>> >> > implementation.java or implementation.ejb) and not a component
>> >> > implementation type, which would allow for dynamic and eventually
>> >> > declarative configuration styles.
>> >>
>> >> I have not very familiar with the terminology so I am not sure what a
>> >> "component extension type" is. But, I do think we eventually want
>> >> "implementation.rdbdas". Wouldn't this be a new implementation type?
>> >>
>> >> It looks like Amita chose to start with a POJO. I notice the use
>> >> of "
>> >> implementation.java".
>> >>
>> >> > Either way, though, I am curious as to why
>> >> >
>> >> > public DAS configureService(String configFile);
>> >> >
>> >> > exists as part of the service definition? If the DAS service was a
>> >> > component extension type, it could be handled as part of the
>> >> > application bootstrap. If the DAS service was a component
>> >> > implementation type, the configuration file URI could be passed
>> >> in as
>> >> > a property and then processed in an initializer method decorated by
>> >> > the SCA @Init annotation. In the latter case, if the implementation
>> >> > of DASService thread-safe (hopefully it is since configuration
>> >> would
>> >> > seem to be a heavyweight operation), then I would make the
>> >> component
>> >> > module scoped to avoid initialization overhead on every resolution.
>> >>
>> >> >
>> >> > In both approaches (extension vs. implementation type), having
>> >> > configuration exposed to the application doesn't quite feel right,
>> >> > since that is what DI tries to externalize.
>> >>
>> >> I agree. The configuration should be part of the initialization and
>> >> should use SCA patterns to do this. I think that Amita meant to use
>> >> eventually use a component property for the DAS config info but
>> >> started
>> >> with a method.
>> >>
>> >> >
>> >> > Also, I was thinking that in having this a component extension
>> >> type,
>> >> > the service interfaces returned from a resolution could include the
>> >> > dynamic one described below or static ones people have mentioned. I
>> >> > guess it is best to start with the easier-to-implement part
>> >> first and
>> >> > support the dynamic interface.
>> >> >
>> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
>> >> > understand what DAS provides in relation to other persistence
>> >> > technologies. Outside of the Java world, Microsoft is promoting
>> >> LINQ
>> >> > which is really interesting, and it would be informative to compare
>> >> > the goals of DAS with that approach (there are obvious differences
>> >> > such as having the query language a strongly-typed part of the
>> >> > programming language, e.g. C#, and LINQ's use of closures).
>> >> >
>> >> > In contrasting DAS to O-R technologies, I see the primary use cases
>> >> > for the former being a quick way to issue a query that may be
>> >> > executed against *heterogeneous* data stores and have that data
>> >> flow
>> >> > remotely or to a client that is not necessarily Java-based. One key
>> >> > for me is heterogeneous data since JDBC 4 lets me do this
>> >> (Hibernate
>> >> > and JPA are about as easy):
>> >> >
>> >> IMO the primary use case for DAS is an application that is SDO-
>> >> centric
>> >> and is taking advantage of its disconnected capabilities. The RDB
>> >> DAS
>> >> is built to work with SDO and uses the change summary to drive
>> >> changes
>> >> made to a disconnected data graph back to some store. This is not to
>> >> say that a relational DAS could not be built on top of JPA, in fact,
>> >> this might be a very useful thing to do. The implementation we
>> >> currently have provides a very straightforward implicit mapping from
>> >> DataObjects to Tables. If more capable mapping is needed then it
>> >> makes
>> >> sense to use the JPA-defined technology and artifacts. A modified
>> >> Entity manager might be needed to take advantage of SDO's change
>> >> summary.
>> >>
>> >> >
>> >> > public interface CustomerDao extends BaseQuery {
>> >> > @Select("select * from customers where city = ?1")
>> >> > DataSet<Customer> findCustomersFrom(String city);
>> >> > }
>> >> >
>> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
>> >> > (CustomerDao.class, datasource);
>> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
>> >> >
>> >> >
>> >> > The other key is remote data and change lists. I think there are
>> >> > (literally) about a thousand ways that already exist to handle the
>> >> > "local" data case. For change lists, interop with ADO.NET's change
>> >> > summary facilities would be interesting.
>> >>
>> >> I agree. Also, it looks like Xcalia may have a similar thought:
>> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
>> >>
>> >> >
>> >> > I'm playing devil's advocate a bit with DAS, but I think it is
>> >> > important we have a clear statement as to when it is appropriate
>> >> and
>> >> > not appropriate to use. One place to start would be to compare
>> >> it to
>> >> > JDBC 4 and JPA.
>> >>
>> >> We can get started with JPA:
>> >>
>> >> * JPA is java-specific, container-based, built around a connected
>> >> data model and offers a complete O/R mapping for POJOs
>> >>
>> >> * The RDB DAS is a java implementation of a language - neutral
>> >> concept (hopefully specified some day) that is containerless,
>> >> assumes a disconnected data model and provides a simple,
>> >> implicit
>> >> mapping for SDO DataObjects (Dynamic or Static) to relational
>> >> tables.
>> >>
>> >> Anything else?
>> >>
>> >> >
>> >> > Jim
>> >> >
>> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>> >> >
>> >> >> Hi Amita
>> >> >>
>> >> >> I think we were both going on the same way, with the DAS Service
>> >> >> sample,
>> >> >> altough i had the interface more like this, to be more flexible :
>> >> >>
>> >> >> public interface DASService {
>> >> >>
>> >> >> public DAS configureService(String configFile);
>> >> >
>> >> >
>> >> >> public DataObject executeCommand(String commandName);
>> >> >> public DataObject execute(String newCommand);
>> >> >> public void applyChanges(DataObject graphRoot);
>> >> >> }
>> >> >>
>> >> >>
>> >> >> As for having it as a sample, maybe we could defined the
>> >> DASService
>> >> >> as one
>> >> >> sample itself, and have a second version of companyWeb that would
>> >> >> consume
>> >> >> the service, something like :
>> >> >>
>> >> >> das\samples\companyWeb
>> >> >> das\samples\dasService
>> >> >> das\samples.companyWeb.service
>> >> >>
>> >> >> or, more like BigBank
>> >> >>
>> >> >> das\samples\companyweb.Service\dasService
>> >> >> das\samples\companyweb.Service\webClient
>> >> >>
>> >> >> Or even in sampleApps...
>> >> >>
>> >> >> Toughts ?
>> >> >>
>> >> >>
>> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
>> >> >>
>> >> >>>
>> >> >>> Hi ,
>> >> >>> I am also following up another thread
>> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> msg09944.html
>> >> >>> on the
>> >> >>> similar issue (JDBC stored procedure container
>> >> >>> using DAS)
>> >> >>> Besides the fact that I am actively working on the container
>> >> work,
>> >> >>> I also
>> >> >>> have tried to
>> >> >>> develop a sample based on the below discussion, following dynamic
>> >> >>> approach.
>> >> >>>
>> >> >>> I am attaching the same here. Please take a look and give your
>> >> >>> suggestions.
>> >> >>> In this, StoredProcedureService implementation has
>> >> setConfigInfo (DAS
>> >> >>> Config) and
>> >> >>> execute(Any SQL). This can be made more complete with
>> >> executeSQL(),
>> >> >>> applyChanges()
>> >> >>> etc.
>> >> >>>
>> >> >>> Can this be added to the existing set of samples?
>> >> >>>
>> >> >>> Regards,
>> >> >>> Amita
>> >> >>>
>> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >>> >
>> >> >>> > Luciano Resende wrote:
>> >> >>> >
>> >> >>> > > Kevin, from what I understood from your suggestion, it was
>> >> >>> looking to
>> >> >>> > me
>> >> >>> > > more like exposing DAS as a service :
>> >> >>> > >
>> >> >>> > >>> public interface RDBDASService
>> >> >>> > >>> DataObject execute(String commandName);
>> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
>> >> >>> > >>> void applyChanges(DataObject graphRoot);
>> >> >>> > >>> }
>> >> >>> > >>
>> >> >>> > Yes, I am talking about exposing a DAS Service configured
>> >> with a
>> >> >>> > specific set of capabilities/commands defined in the DAS config
>> >> >>> file.
>> >> >>> > So, if the implementation of the service interface above was
>> >> >>> configured
>> >> >>> > to work with Customers they would use the service like this:
>> >> >>> >
>> >> >>> > List customers = myRDBDASService.execute("getAllCustomers");
>> >> >>> > String name = customers.get(0).getString("name");
>> >> >>> >
>> >> >>> > This is not much different than the static interface you
>> >> proposed,
>> >> >>> > right?
>> >> >>> >
>> >> >>> > > And then, when a service developer defines the
>> >> AccountService,
>> >> >>> he will
>> >> >>> >
>> >> >>> > > have
>> >> >>> > > to know about yet another service, about how DAS works,
>> >> how it is
>> >> >>> > > configured, etc, etc... is that right ?
>> >> >>> > >
>> >> >>> > The abilities of the service are defined by the DAS config
>> >> file.
>> >> >>> So,
>> >> >>> > the person or tool that provides the config file must
>> >> understand
>> >> >>> how the
>> >> >>> >
>> >> >>> > RDB DAS APIs work. There is no getting around this.
>> >> >>> >
>> >> >>> > > My proposal was going more towards allowing the service
>> >> >>> developer to
>> >> >>> > > focus
>> >> >>> > > on defining the service, and let the "declarative das" to
>> >> >>> handle the
>> >> >>> > > persistent layer....
>> >> >>> > >
>> >> >>> > The DAS config file is the declaration of an instance of the
>> >> >>> DAS. That
>> >> >>> > instance can be exposed as a dynamic or typed service/
>> >> interface.
>> >> >>> That
>> >> >>> > seems to be the main discussion we are having. Although, I
>> >> may be
>> >> >>> > missing something.
>> >> >>> >
>> >> >>> > > Also, by defining some conventions over configuration
>> >> and/or using
>> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
>> >> >>> procedure),
>> >> >>> > the
>> >> >>> > > service developer could really define a service that
>> >> interacts
>> >> >>> with a
>> >> >>> > > RDB,
>> >> >>> > > without having to code the service persistence layer.
>> >> >>> > >
>> >> >>> > There is a lot of potential for the use of annotations.
>> >> >>> >
>> >> >>> > >
>> >> >>> > > - Luciano
>> >> >>> > >
>> >> >>> > >
>> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
>> >> >>> > >
>> >> >>> > >>
>> >> >>> > >> The real difference between the two approaches is that
>> >> one is
>> >> >>> "Typed"
>> >> >>> > or
>> >> >>> > >> static and the other is dynamic. I think both are needed
>> >> but was
>> >> >>> > >> suggesting that we start with dynamic since it is the most
>> >> >>> flexible
>> >> >>> > and
>> >> >>> > >> seems to be a reasonable stepping stone towards a static
>> >> >>> capability.
>> >> >>> > >>
>> >> >>> > >> With either, the user does not need to know about
>> >> traditional
>> >> >>> > >> persistence frameworks. With the dynamic approach, however,
>> >> >>> the user
>> >> >>> > >> does need to know about the dynamic SDO API.
>> >> >>> > >>
>> >> >>> > >> So, with the static interface the user might write:
>> >> >>> > >>
>> >> >>> > >> List customers = accountService.getAllCustomers();
>> >> >>> > >> String name = ((Customer)customers.get(0)).getName();
>> >> >>> > >>
>> >> >>> > >> The equivalent dynamic API might be:
>> >> >>> > >>
>> >> >>> > >> List customers = dasService.execute("getAllCustomers");
>> >> >>> > >> String name = ((DataObject)customers.get(0)).getString
>> >> >>> ("name");
>> >> >>> > >>
>> >> >>> > >> The first is probably a little easier for the application
>> >> >>> developer
>> >> >>> > but
>> >> >>> > >> the second is much easier for the service developer. IMO,
>> >> the
>> >> >>> dynamic
>> >> >>> > >> case is the best place to start and, again, we
>> >> definitely will
>> >> >>> want
>> >> >>> > >> support for both.
>> >> >>> > >>
>> >> >>> > >> Thanks.
>> >> >>> > >> --
>> >> >>> > >> Kevin
>> >> >>> > >>
>> >> >>> > >>
>> >> >>> > >>
>> >> >>> > >>
>> >> >>> > >>
>> >> >>> > >>
>> >> >>> > >> Jeremy Boynes wrote:
>> >> >>> > >>
>> >> >>> > >> > I think this would be useful but it seems more like a
>> >> >>> traditional
>> >> >>> > >> > persistence API than what Luciano was suggesting. With
>> >> this
>> >> >>> one a
>> >> >>> > >> > user needs to know about DataObject's, commands, SQL
>> >> strings
>> >> >>> etc.
>> >> >>> > >> > just like they would if they were using raw JDBC or JPA.
>> >> >>> > >> >
>> >> >>> > >> > On the other hand, Luciano's proposal seemed more about
>> >> >>> expressing
>> >> >>> > >> > high-level CRUD operations as operations on a service
>> >> >>> interface:
>> >> >>> > >> >
>> >> >>> > >> >>> public interface AccountService {
>> >> >>> > >> >>>
>> >> >>> > >> >>> public List getAllCustomers();
>> >> >>> > >> >>> public Object getCustomerAccount(String
>> >> accountNumber);
>> >> >>> > >> >>> }
>> >> >>> > >> >>
>> >> >>> > >> >
>> >> >>> > >> > which is all application level concepts rather
>> >> than persistence
>> >> >>> > level
>> >> >>> > >> > concepts. I'd actually go a little further and put that
>> >> >>> right into
>> >> >>> > >> > the service contract:
>> >> >>> > >> >
>> >> >>> > >> > public interface AccountService {
>> >> >>> > >> > List<Customer> getAllCustomers();
>> >> >>> > >> > Account getCustomerAccount(String accountNumber);
>> >> >>> > >> > }
>> >> >>> > >> >
>> >> >>> > >> > In a ideal world, if the user was able to accept
>> >> standardized
>> >> >>> > >> > mappings (a la Rails et al) then no further configuration
>> >> >>> would be
>> >> >>> > >> > needed except to add this to the logical assembly:
>> >> >>> > >> >
>> >> >>> > >> > <component name="AccountStore">
>> >> >>> > >> > <implementation.das resource="MySQLDatabase"/>
>> >> >>> > >> > </component>
>> >> >>> > >> >
>> >> >>> > >> > With SCA's ability to translate service contracts, this
>> >> >>> should be
>> >> >>> > >> > callable from and deployable to any SCA runtime
>> >> regardless of
>> >> >>> > whether
>> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
>> >> running on
>> >> a
>> >> >>> > Java,
>> >> >>> > >> > C++ or PHP platform.
>> >> >>> > >> >
>> >> >>> > >> > The important thing here is that the client is
>> >> isolated from
>> >> >>> how
>> >> >>> > the
>> >> >>> > >> > DAS component is provided. We could have multiple
>> >> declarative
>> >> >>> > >> > implementations, say one based on RDB-DAS and one that did
>> >> >>> stuff
>> >> >>> > with
>> >> >>> > >> > XML databases like Xindice; alternatively, /without
>> >> altering
>> >> >>> the
>> >> >>> > >> > client at all/ they could switch to a custom coded version
>> >> >>> written
>> >> >>> > in
>> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
>> >> >>> > >> >
>> >> >>> > >> > --
>> >> >>> > >> > Jeremy
>> >> >>> > >> >
>> >> >>> > >> >
>> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>> >> >>> > >> >
>> >> >>> > >> >> 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 code specific to
>> >> a new
>> >> >>> > >> >> service. Instead, the service will be "instantiated"
>> >> based
>> >> >>> on the
>> >> >>> >
>> >> >>> > >> >> provided DAS config file. The service interface
>> >> might look
>> >> >>> like
>> >> >>> > >> this:
>> >> >>> > >> >>
>> >> >>> > >> >> public interface RDBDASService
>> >> >>> > >> >> DataObject execute(String commandName);
>> >> >>> > >> >> DataObject executeSQL(String abitrarySQL);
>> >> >>> > >> >> void applyChanges(DataObject graphRoot);
>> >> >>> > >> >> }
>> >> >>> > >> >>
>> >> >>> > >> >> So, depending on the config file used to instantiate the
>> >> >>> service,
>> >> >>> > >> >> this interface could be used to return Customers/
>> >> Accounts or
>> >> >>> > >> >> Toasters. In fact, a lot could be achieved with no
>> >> >>> > configuration at
>> >> >>> > >> >> all by restricting use to: DataObject executeSQL(String
>> >> >>> > >> abitrarySQL);
>> >> >>> > >> >>
>> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
>> >> >>> mod_mbox/ws-
>> >> >>> > >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net %3e
>> >> >>> > >> >>
>> >> >>> > >> >> Once this was working it should be straightforward to
>> >> build
>> >> >>> more
>> >> >>> > >> >> strongly typed services and possible put together some
>> >> >>> generation
>> >> >>> > >> >> tooling. We could also start looking at support for a
>> >> more
>> >> >>> > RESTFul
>> >> >>> > >> >> interface.
>> >> >>> > >> >> --
>> >> >>> > >> >> Kevin
>> >> >>> > >> >>
>> >> >>> > >> >>
>> >> >>> > >> >>
>> >> >>> > >> >>
>> >> >>> > >> >> Luciano Resende wrote:
>> >> >>> > >> >>
>> >> >>> > >> >>> Recently, people have been starting to talk about
>> >> better DAS
>> >> >>> > >> >>> integration
>> >> >>> > >> >>> with DAS, and below are some threads on the subject :
>> >> >>> > >> >>>
>> >> >>> > >> >>>
>> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> msg08833.html
>> >> >>> > >> >>>
>> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> msg08923.html
>> >> >>> > >> >>>
>> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> >> >>> msg09715.html
>> >> >>> >
>> >> >>> > >> >>>
>> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
>> >> what I'm
>> >> >>> > >> >>> saying is not
>> >> >>> > >> >>> yet available on SCA today.
>> >> >>> > >> >>>
>> >> >>> > >> >>> Today, defining a service to work with a relational
>> >> >>> database, you
>> >> >>> > >> >>> will need
>> >> >>> > >> >>> to code the persistence side of the service where CRUD
>> >> >>> operations
>> >> >>> > >> >>> to the
>> >> >>> > >> >>> database will be done.
>> >> >>> > >> >>> I was thinking on a simpler, easier way, where coding
>> >> the
>> >> >>> CRUD
>> >> >>> > >> >>> operations on
>> >> >>> > >> >>> the persistence layer would be avoided as much as
>> >> possible.
>> >> >>> > >> >>> The idea would be to have a more "declarative DAS" when
>> >> >>> defining
>> >> >>> > SCA
>> >> >>> > >> >>> Services, so you would either use some Annotations
>> >> or SCDL
>> >> to
>> >> >>> > >> have the
>> >> >>> > >> >>> "declarative DAS" configuration inside it.
>> >> >>> > >> >>>
>> >> >>> > >> >>> I was thinking on something like....
>> >> >>> > >> >>>
>> >> >>> > >> >>> SCDL Definition would look something like this :
>> >> >>> > >> >>>
>> >> >>> > >> >>> <component name="AccountDataService">
>> >> >>> > >> >>> <interface.java
>> >> >>> > >> >>>
>> >> class="bigbank.account.services.account.AccountService"/>
>> >> >>> > >> >>> <implementation.das="dasConfig.properties"
>> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> >> >>> > >> >>> </component>
>> >> >>> > >> >>>
>> >> >>> > >> >>> The AccountService Interface would look like this
>> >> (missing
>> >> >>> any
>> >> >>> > SCA
>> >> >>> > >> >>> annotations):
>> >> >>> > >> >>>
>> >> >>> > >> >>> public interface AccountService {
>> >> >>> > >> >>>
>> >> >>> > >> >>> public List getAllCustomers();
>> >> >>> > >> >>> public Object getCustomerAccount(String
>> >> accountNumber);
>> >> >>> > >> >>> }
>> >> >>> > >> >>>
>> >> >>> > >> >>> The DAS config would look like this, and would have the
>> >> >>> > definition
>> >> >>> > >> >>> for the
>> >> >>> > >> >>> "all companies" command.
>> >> >>> > >> >>>
>> >> >>> > >> >>> <Config ...>
>> >> >>> > >> >>> ...
>> >> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
>> >> bigbank"/>
>> >> >>> > >> >>>
>> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select * from
>> >> >>> CUSTOMERS"
>> >> >>> > >> >>> kind="Select"/>
>> >> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
>> >> >>> accountNumber,
>> >> >>> > >> >>> accountType, balance FROM accounts where
>> >> accountNumber = ?"
>> >> >>> > >> >>> kind="Select" />
>> >> >>> > >> >>> ...
>> >> >>> > >> >>> </Config>
>> >> >>> > >> >>>
>> >> >>> > >> >>>
>> >> >>> > >> >>> Mapping between interface methods and DAS Commands
>> >> >>> > >> >>> - If a DAS config file is provided, based on the
>> >> >>> > SCDL definition,
>> >> >>> > >> we
>> >> >>> > >> >>> would look for "DAS command" based on the name of the
>> >> getter
>> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
>> >> command)
>> >> >>> > >> >>> - Otherwise, we would try to do a map directly to a
>> >> >>> > >> stored procedure
>> >> >>> > >> >>> - We could also have a way to force the mapping by
>> >> using
>> >> >>> > >> annotation
>> >> >>> > >> >>> (e.g@Procedure on the method level)
>> >> >>> > >> >>>
>> >> >>> > >> >>> Mapping between method parameter and command parameter
>> >> >>> > >> >>> - We would need to define a method for mapping the
>> >> method
>> >> >>> > >> >>> parameters to
>> >> >>> > >> >>> the query paramters either based on position ( e.g first
>> >> >>> method
>> >> >>> > >> >>> parameter
>> >> >>> > >> >>> maps to the first command paramter), or we would do some
>> >> >>> > mapping by
>> >> >>> > >> >>> name
>> >> >>> > >> >>> (currently not available in Tuscany DAS)
>> >> >>> > >> >>>
>> >> >>> > >> >>> Note:
>> >> >>> > >> >>> - A SCDL connection information would override the DAS
>> >> >>> Config
>> >> >>> > file
>> >> >>> > >> >>> connection information.
>> >> >>> > >> >>>
>> >> >>> > >> >>>
>> >> >>> > >> >>> Benefits
>> >> >>> > >> >>> - It's All about simplicity and easy of use
>> >> >>> > >> >>> - This would allow a user to define a service without
>> >> >>> having to
>> >> >>> >
>> >> >>> > >> >>> explicitly having to code any Data Access related code.
>> >> >>> > >> >>>
>> >> >>> > >> >>>
>> >> >>> > >> >>> Implementation approaches
>> >> >>> > >> >>> - Utilizing DAS : This approach would start from the
>> >> >>> current
>> >> >>> > >> >>> Tuscany DAS
>> >> >>> > >> >>> implementation, where functionality would be already
>> >> >>> > available, but
>> >> >>> > >> >>> the
>> >> >>> > >> >>> service implementation would be tied to SDO and RDB
>> >> as this
>> >> >>> > is what
>> >> >>> > >> >>> DAS
>> >> >>> > >> >>> supports today.
>> >> >>> > >> >>>
>> >> >>> > >> >>> - Start simple and grow : We could start simple, by
>> >> >>> having a
>> >> >>> > >> simple
>> >> >>> > >> >>> implementation based on JDBC and would return some
>> >> simple
>> >> >>> > >> >>> collection as a
>> >> >>> > >> >>> return type (e.g List or a even a Recordset), this could
>> >> >>> give us
>> >> >>> > a
>> >> >>> > >> >>> quick
>> >> >>> > >> >>> start to flush implementation details and get a proven
>> >> >>> design,
>> >> >>> > and
>> >> >>> > >> >>> this
>> >> >>> > >> >>> could get evolved to use a DAS that would support
>> >> multiple
>> >> >>> > backends
>> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
>> >> non- SDO
>> >> >>> types
>> >> >>> > >> as a
>> >> >>> > >> >>> command
>> >> >>> > >> >>> result.
>> >> >>> > >> >>>
>> >> >>> > >> >>>
>> >> >>> > >> >>> Toughts ?
>> >> >>> > >> >>>
>> >> >>> > >> >>> - Luciano
>> >> >>> > >> >>>
>> >> >>> > >> >>>
>> >> >>> > >> >>>
>> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >>> > >> >>>
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> 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. Another thing we want to eventually
>> >> >>> explore is
>> >> >>> > >> >>>> exposing
>> >> >>> > >> >>>> a DAS as REST-oriented services. As we have seen
>> >> from the
>> >> >>> > parent
>> >> >>> > >> >>>> thread
>> >> >>> > >> >>>> there are almost too many possible approaches.
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> My first thought is to model the DAS as a service and
>> >> >>> create a
>> >> >>> > new
>> >> >>> > >> >>>> implementation kind (implementation.rdbdas). The main
>> >> >>> reason
>> >> >>> > has
>> >> >>> > >> >>>> to do
>> >> >>> > >> >>>> with the potential declarative aspect of DAS that
>> >> >>> > Jeremy mentioned
>> >> >>> > >> >>>> which
>> >> >>> > >> >>>> is all about creating data access services
>> >> >>> declaratively. A new
>> >> >>> > >> >>>> component type and a service that we build by hand
>> >> would be
>> >> >>> > a good
>> >> >>> > >> >>>> step
>> >> >>> > >> >>>> in this direction.
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> We might want to expose a DAS service with an
>> >> interface like
>> >> >>> > this:
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> public interface RDBDASService
>> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
>> >> >>> > >> >>>> DataObject execute(String commandName);
>> >> >>> > >> >>>> DataObject executeSQL(String abitrarySQL);
>> >> >>> > >> >>>> }
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> The service would be initialized with an optional
>> >> RDB DAS
>> >> >>> > >> config file
>> >> >>> > >> >>>> that defines connection properties, a set of commands,
>> >> >>> etc. So,
>> >> >>> > >> >>>> different services implementing the same interface
>> >> could be
>> >> >>> > >> >>>> initialized
>> >> >>> > >> >>>> from separate config files.
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> Eventually, we might want to build services like this:
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> public interface Customers_RDBDASService
>> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
>> >> >>> > >> >>>> DataObject getAllCustomersWithLastName (String
>> >> >>> > lastName);
>> >> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID (int
>> >> >>> > customerId);
>> >> >>> > >> >>>> }
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> But, for this to be very useful would probably require
>> >> >>> some code
>> >> >>> > >> >>>> generation tooling.
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> Thoughts?
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> --Kevin
>> >> >>> > >> >>>>
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> Luciano Resende wrote:
>> >> >>> > >> >>>>
>> >> >>> > >> >>>> > I'm starting to look in ways we could have a
>> >> declarative
>> >> >>> > DAS and
>> >> >>> > >> >>>> will be
>> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
>> >> >>> > >> >>>> >
>> >> >>> > >> >>>> > - Luciano
>> >> >>> > >> >>>> >
>> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
>> >> 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 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.
>> >> >>> > >> >>>> >>
>> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
>> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
>> >> >>> > should welcome
>> >> >>> > >> it
>> >> >>> > >> >>>> >> like we would any other contribution.
>> >> >>> > >> >>>> >>
>> >> >>> > >> >>>> >> >> 3) to access data through an application
>> >> service with
>> >> >>> > >> >>>> declarative
>> >> >>> > >> >>>> >> >> implementation by DAS
>> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
>> >> >>> > >> >>>> >>
>> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
>> >> >>> > >> >>>> >> --
>> >> >>> > >> >>>> >> Jeremy
>> >> >>> > >> >>>> >>
>> >> >>> > >> >>>> >>
>> >> >>> > >> >>>>
>> >> >>> > >>
>> >> >>>
>> >> --------------------------------------------------------------------
>> >> >>> > >> -
>> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >>> unsubscribe@ws.apache.org
>> >> >>> > >> >>>> >> For additional commands, e-mail:
>> >> >>> > tuscany-dev-help@ws.apache.org
>> >> >>> > >> >>>> >>
>> >> >>> > >> >>>> >>
>> >> >>> > >> >>>> >
>> >> >>> > >> >>>>
>> >> >>> > >> >>>>
>> >> >>> > >> >>>>
>> >> >>> > >> >>>>
>> >> >>> > >>
>> >> >>>
>> >> --------------------------------------------------------------------
>> >> >>> > >> -
>> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
>> >> >>> unsubscribe@ws.apache.org
>> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
>> >> >>> help@ws.apache.org
>> >> >>> > >> >>>>
>> >> >>> > >> >>>>
>> >> >>> > >> >>>
>> >> >>> > >> >>
>> >> >>> > >> >>
>> >> >>> > >> >>
>> >> >>> > >> >>
>> >> >>> >
>> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> unsubscribe@ws.apache.org
>> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
>> >> >>> help@ws.apache.org
>> >> >>> > >> >>
>> >> >>> > >> >
>> >> >>> > >> >
>> >> >>> > >> >
>> >> >>> >
>> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
>> >> unsubscribe@ws.apache.org
>> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
>> >> help@ws.apache.org
>> >> >>> > >> >
>> >> >>> > >> >
>> >> >>> > >> >
>> >> >>> > >> >
>> >> >>> > >>
>> >> >>> > >>
>> >> >>> > >>
>> >> >>> > >>
>> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
>> >> unsubscribe@ws.apache.org
>> >> >>> > >> For additional commands, e-mail: tuscany-dev-
>> >> help@ws.apache.org
>> >> >>> > >>
>> >> >>> > >>
>> >> >>> > >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >
>> >> >
>> >> >
>> >> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Luciano Resende <lu...@gmail.com>.
Comments in-line...
On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
>
> > Hi,
> >
> > I would also like to understand this a little better ... here I am
> > thinking
> > aloud and hope the others will help in getting my persceptions
> > right...
> >
> > I guess firstly it is a question of how or where we want to
> > position 'DAS
> > Integration' in SCA. Is is something we want to integrate as the
> > Application Layer, which I understand is what Amita is trying
> > presently and
> > which Jim refers to as component implementation. In this option
> > we get to
> > do some sort of a service wrapper to DAS and then it becomes a
> > demonstration
> > of two Tuscany subprojects integrating at application level.
> >
Yes, I think we have space to position DAS both ways, and integrating in the
application layer by exposing DAS as a service would be a very easy and
quick, this could be exposed as a sample app, and could show we are working
on getting a better integration between DAS and SCA
> Or do we want to position DAS at the infrastructure layer as another
> > extension type (either container or binding). I guess this is
> > where Ant
> > started this - proposing a JDBC container / binding for component
> > implementation in StoredProcedures.
> I was thinking a DAS was a way to declaratively model heterogeneous
> data as a service and offer a mechanism for remoting that data. In
> other words, it provided the ability for an application to perform
> CRUD using a high-level contract (interface) and having those
> operations take place across a service network. How this is hooked
> into the SCA container is probably best done as an extension type,
> i.e. someone could specify:
>
> <component name="Foo">
> <implementation.das>
> <interface.java ....>
> </implementation.das>
> </component>
Yes, this goes back to the way I was thinking on my original proposal.
> If this is the path we should take
> > then we probably have to think beyond DAS - to something more
> > general - of
> > which DAS is just a special case. I suppose this is what Jim has also
> > suggested in trying to explore other persistence mechanisms.
> >
> This may be the crux of the confusion. I was thinking DAS provides a
> general mechanism for accessing heterogeneous data and is only right
> now tied to SQL because of resource constraints (i.e. we have to
> start somewhere). Ultimately, DAS should provide the infrastructure
> for dealing with multiple, varied data stores and mechanisms for
> querying across them. In other words, I guess I am saying DAS should
> be the general solution (declarative and heterogeneous) since if it
> is only a programmatic way to access relational data then its value
> is less clear in comparison to things such as JDBC 4 or JPA.
Yes, the current status of DAS implementation is RDB only. I would say that,
in the future, I'd like to see a heterogeneous DAS that would give you
access to different data stores, and probably support non-SDO types as well.
> I too feel that this is something that must be done as an extension
> > type -
> > but yet to get my hands on the general scheme of things that DAS
> > can slip
> > into. Infact the other thread where Jeremy has taken forward a
> > proposal to
> > the specs group on resources tempts me to think that there is going
> > to be
> > something in that which we can leverage from.
> >
> I think resources are orthogonal as they are about a component
> implementation's contract with its container. Declarative data
> services on the other hand are about application constructs that can
> be wired to.
>
> > I hope to get a better understanding this as we go along in this
> > thread :)
> >
> Me too :-) As soon as I have trouble explaining technologies to .NET
> people and they say "you Unix/Java people are at it again with a
> thousand ways to do the same exact thing" it causes me to think that
> maybe we need to clarify our message.
If we all think it would be useful, I could try to summarize the thread on
the wiki with a more clean proposal incorporating all your feedback , what
you guys think ?
Jim
> > Thanks
> >
> > - Venkat
> >
> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >>
> >> Jim Marino wrote:
> >>
> >> > When I first read the thread on this, I thought the DAS service
> >> would
> >> > be a component extension type (e.g. analogous to a
> >> > implementation.java or implementation.ejb) and not a component
> >> > implementation type, which would allow for dynamic and eventually
> >> > declarative configuration styles.
> >>
> >> I have not very familiar with the terminology so I am not sure what a
> >> "component extension type" is. But, I do think we eventually want
> >> "implementation.rdbdas". Wouldn't this be a new implementation type?
> >>
> >> It looks like Amita chose to start with a POJO. I notice the use
> >> of "
> >> implementation.java".
> >>
> >> > Either way, though, I am curious as to why
> >> >
> >> > public DAS configureService(String configFile);
> >> >
> >> > exists as part of the service definition? If the DAS service was a
> >> > component extension type, it could be handled as part of the
> >> > application bootstrap. If the DAS service was a component
> >> > implementation type, the configuration file URI could be passed
> >> in as
> >> > a property and then processed in an initializer method decorated by
> >> > the SCA @Init annotation. In the latter case, if the implementation
> >> > of DASService thread-safe (hopefully it is since configuration
> >> would
> >> > seem to be a heavyweight operation), then I would make the
> >> component
> >> > module scoped to avoid initialization overhead on every resolution.
> >>
> >> >
> >> > In both approaches (extension vs. implementation type), having
> >> > configuration exposed to the application doesn't quite feel right,
> >> > since that is what DI tries to externalize.
> >>
> >> I agree. The configuration should be part of the initialization and
> >> should use SCA patterns to do this. I think that Amita meant to use
> >> eventually use a component property for the DAS config info but
> >> started
> >> with a method.
> >>
> >> >
> >> > Also, I was thinking that in having this a component extension
> >> type,
> >> > the service interfaces returned from a resolution could include the
> >> > dynamic one described below or static ones people have mentioned. I
> >> > guess it is best to start with the easier-to-implement part
> >> first and
> >> > support the dynamic interface.
> >> >
> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> >> > understand what DAS provides in relation to other persistence
> >> > technologies. Outside of the Java world, Microsoft is promoting
> >> LINQ
> >> > which is really interesting, and it would be informative to compare
> >> > the goals of DAS with that approach (there are obvious differences
> >> > such as having the query language a strongly-typed part of the
> >> > programming language, e.g. C#, and LINQ's use of closures).
> >> >
> >> > In contrasting DAS to O-R technologies, I see the primary use cases
> >> > for the former being a quick way to issue a query that may be
> >> > executed against *heterogeneous* data stores and have that data
> >> flow
> >> > remotely or to a client that is not necessarily Java-based. One key
> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> (Hibernate
> >> > and JPA are about as easy):
> >> >
> >> IMO the primary use case for DAS is an application that is SDO-
> >> centric
> >> and is taking advantage of its disconnected capabilities. The RDB
> >> DAS
> >> is built to work with SDO and uses the change summary to drive
> >> changes
> >> made to a disconnected data graph back to some store. This is not to
> >> say that a relational DAS could not be built on top of JPA, in fact,
> >> this might be a very useful thing to do. The implementation we
> >> currently have provides a very straightforward implicit mapping from
> >> DataObjects to Tables. If more capable mapping is needed then it
> >> makes
> >> sense to use the JPA-defined technology and artifacts. A modified
> >> Entity manager might be needed to take advantage of SDO's change
> >> summary.
> >>
> >> >
> >> > public interface CustomerDao extends BaseQuery {
> >> > @Select("select * from customers where city = ?1")
> >> > DataSet<Customer> findCustomersFrom(String city);
> >> > }
> >> >
> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> > (CustomerDao.class, datasource);
> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >
> >> >
> >> > The other key is remote data and change lists. I think there are
> >> > (literally) about a thousand ways that already exist to handle the
> >> > "local" data case. For change lists, interop with ADO.NET's change
> >> > summary facilities would be interesting.
> >>
> >> I agree. Also, it looks like Xcalia may have a similar thought:
> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >>
> >> >
> >> > I'm playing devil's advocate a bit with DAS, but I think it is
> >> > important we have a clear statement as to when it is appropriate
> >> and
> >> > not appropriate to use. One place to start would be to compare
> >> it to
> >> > JDBC 4 and JPA.
> >>
> >> We can get started with JPA:
> >>
> >> * JPA is java-specific, container-based, built around a connected
> >> data model and offers a complete O/R mapping for POJOs
> >>
> >> * The RDB DAS is a java implementation of a language - neutral
> >> concept (hopefully specified some day) that is containerless,
> >> assumes a disconnected data model and provides a simple,
> >> implicit
> >> mapping for SDO DataObjects (Dynamic or Static) to relational
> >> tables.
> >>
> >> Anything else?
> >>
> >> >
> >> > Jim
> >> >
> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >
> >> >> Hi Amita
> >> >>
> >> >> I think we were both going on the same way, with the DAS Service
> >> >> sample,
> >> >> altough i had the interface more like this, to be more flexible :
> >> >>
> >> >> public interface DASService {
> >> >>
> >> >> public DAS configureService(String configFile);
> >> >
> >> >
> >> >> public DataObject executeCommand(String commandName);
> >> >> public DataObject execute(String newCommand);
> >> >> public void applyChanges(DataObject graphRoot);
> >> >> }
> >> >>
> >> >>
> >> >> As for having it as a sample, maybe we could defined the
> >> DASService
> >> >> as one
> >> >> sample itself, and have a second version of companyWeb that would
> >> >> consume
> >> >> the service, something like :
> >> >>
> >> >> das\samples\companyWeb
> >> >> das\samples\dasService
> >> >> das\samples.companyWeb.service
> >> >>
> >> >> or, more like BigBank
> >> >>
> >> >> das\samples\companyweb.Service\dasService
> >> >> das\samples\companyweb.Service\webClient
> >> >>
> >> >> Or even in sampleApps...
> >> >>
> >> >> Toughts ?
> >> >>
> >> >>
> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
> >> >>
> >> >>>
> >> >>> Hi ,
> >> >>> I am also following up another thread
> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> msg09944.html
> >> >>> on the
> >> >>> similar issue (JDBC stored procedure container
> >> >>> using DAS)
> >> >>> Besides the fact that I am actively working on the container
> >> work,
> >> >>> I also
> >> >>> have tried to
> >> >>> develop a sample based on the below discussion, following dynamic
> >> >>> approach.
> >> >>>
> >> >>> I am attaching the same here. Please take a look and give your
> >> >>> suggestions.
> >> >>> In this, StoredProcedureService implementation has
> >> setConfigInfo (DAS
> >> >>> Config) and
> >> >>> execute(Any SQL). This can be made more complete with
> >> executeSQL(),
> >> >>> applyChanges()
> >> >>> etc.
> >> >>>
> >> >>> Can this be added to the existing set of samples?
> >> >>>
> >> >>> Regards,
> >> >>> Amita
> >> >>>
> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >>> >
> >> >>> > Luciano Resende wrote:
> >> >>> >
> >> >>> > > Kevin, from what I understood from your suggestion, it was
> >> >>> looking to
> >> >>> > me
> >> >>> > > more like exposing DAS as a service :
> >> >>> > >
> >> >>> > >>> public interface RDBDASService
> >> >>> > >>> DataObject execute(String commandName);
> >> >>> > >>> DataObject executeSQL(String abitrarySQL);
> >> >>> > >>> void applyChanges(DataObject graphRoot);
> >> >>> > >>> }
> >> >>> > >>
> >> >>> > Yes, I am talking about exposing a DAS Service configured
> >> with a
> >> >>> > specific set of capabilities/commands defined in the DAS config
> >> >>> file.
> >> >>> > So, if the implementation of the service interface above was
> >> >>> configured
> >> >>> > to work with Customers they would use the service like this:
> >> >>> >
> >> >>> > List customers = myRDBDASService.execute("getAllCustomers");
> >> >>> > String name = customers.get(0).getString("name");
> >> >>> >
> >> >>> > This is not much different than the static interface you
> >> proposed,
> >> >>> > right?
> >> >>> >
> >> >>> > > And then, when a service developer defines the
> >> AccountService,
> >> >>> he will
> >> >>> >
> >> >>> > > have
> >> >>> > > to know about yet another service, about how DAS works,
> >> how it is
> >> >>> > > configured, etc, etc... is that right ?
> >> >>> > >
> >> >>> > The abilities of the service are defined by the DAS config
> >> file.
> >> >>> So,
> >> >>> > the person or tool that provides the config file must
> >> understand
> >> >>> how the
> >> >>> >
> >> >>> > RDB DAS APIs work. There is no getting around this.
> >> >>> >
> >> >>> > > My proposal was going more towards allowing the service
> >> >>> developer to
> >> >>> > > focus
> >> >>> > > on defining the service, and let the "declarative das" to
> >> >>> handle the
> >> >>> > > persistent layer....
> >> >>> > >
> >> >>> > The DAS config file is the declaration of an instance of the
> >> >>> DAS. That
> >> >>> > instance can be exposed as a dynamic or typed service/
> >> interface.
> >> >>> That
> >> >>> > seems to be the main discussion we are having. Although, I
> >> may be
> >> >>> > missing something.
> >> >>> >
> >> >>> > > Also, by defining some conventions over configuration
> >> and/or using
> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
> >> >>> procedure),
> >> >>> > the
> >> >>> > > service developer could really define a service that
> >> interacts
> >> >>> with a
> >> >>> > > RDB,
> >> >>> > > without having to code the service persistence layer.
> >> >>> > >
> >> >>> > There is a lot of potential for the use of annotations.
> >> >>> >
> >> >>> > >
> >> >>> > > - Luciano
> >> >>> > >
> >> >>> > >
> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
> >> >>> > >
> >> >>> > >>
> >> >>> > >> The real difference between the two approaches is that
> >> one is
> >> >>> "Typed"
> >> >>> > or
> >> >>> > >> static and the other is dynamic. I think both are needed
> >> but was
> >> >>> > >> suggesting that we start with dynamic since it is the most
> >> >>> flexible
> >> >>> > and
> >> >>> > >> seems to be a reasonable stepping stone towards a static
> >> >>> capability.
> >> >>> > >>
> >> >>> > >> With either, the user does not need to know about
> >> traditional
> >> >>> > >> persistence frameworks. With the dynamic approach, however,
> >> >>> the user
> >> >>> > >> does need to know about the dynamic SDO API.
> >> >>> > >>
> >> >>> > >> So, with the static interface the user might write:
> >> >>> > >>
> >> >>> > >> List customers = accountService.getAllCustomers();
> >> >>> > >> String name = ((Customer)customers.get(0)).getName();
> >> >>> > >>
> >> >>> > >> The equivalent dynamic API might be:
> >> >>> > >>
> >> >>> > >> List customers = dasService.execute("getAllCustomers");
> >> >>> > >> String name = ((DataObject)customers.get(0)).getString
> >> >>> ("name");
> >> >>> > >>
> >> >>> > >> The first is probably a little easier for the application
> >> >>> developer
> >> >>> > but
> >> >>> > >> the second is much easier for the service developer. IMO,
> >> the
> >> >>> dynamic
> >> >>> > >> case is the best place to start and, again, we
> >> definitely will
> >> >>> want
> >> >>> > >> support for both.
> >> >>> > >>
> >> >>> > >> Thanks.
> >> >>> > >> --
> >> >>> > >> Kevin
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >> Jeremy Boynes wrote:
> >> >>> > >>
> >> >>> > >> > I think this would be useful but it seems more like a
> >> >>> traditional
> >> >>> > >> > persistence API than what Luciano was suggesting. With
> >> this
> >> >>> one a
> >> >>> > >> > user needs to know about DataObject's, commands, SQL
> >> strings
> >> >>> etc.
> >> >>> > >> > just like they would if they were using raw JDBC or JPA.
> >> >>> > >> >
> >> >>> > >> > On the other hand, Luciano's proposal seemed more about
> >> >>> expressing
> >> >>> > >> > high-level CRUD operations as operations on a service
> >> >>> interface:
> >> >>> > >> >
> >> >>> > >> >>> public interface AccountService {
> >> >>> > >> >>>
> >> >>> > >> >>> public List getAllCustomers();
> >> >>> > >> >>> public Object getCustomerAccount(String
> >> accountNumber);
> >> >>> > >> >>> }
> >> >>> > >> >>
> >> >>> > >> >
> >> >>> > >> > which is all application level concepts rather
> >> than persistence
> >> >>> > level
> >> >>> > >> > concepts. I'd actually go a little further and put that
> >> >>> right into
> >> >>> > >> > the service contract:
> >> >>> > >> >
> >> >>> > >> > public interface AccountService {
> >> >>> > >> > List<Customer> getAllCustomers();
> >> >>> > >> > Account getCustomerAccount(String accountNumber);
> >> >>> > >> > }
> >> >>> > >> >
> >> >>> > >> > In a ideal world, if the user was able to accept
> >> standardized
> >> >>> > >> > mappings (a la Rails et al) then no further configuration
> >> >>> would be
> >> >>> > >> > needed except to add this to the logical assembly:
> >> >>> > >> >
> >> >>> > >> > <component name="AccountStore">
> >> >>> > >> > <implementation.das resource="MySQLDatabase"/>
> >> >>> > >> > </component>
> >> >>> > >> >
> >> >>> > >> > With SCA's ability to translate service contracts, this
> >> >>> should be
> >> >>> > >> > callable from and deployable to any SCA runtime
> >> regardless of
> >> >>> > whether
> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> >> running on
> >> a
> >> >>> > Java,
> >> >>> > >> > C++ or PHP platform.
> >> >>> > >> >
> >> >>> > >> > The important thing here is that the client is
> >> isolated from
> >> >>> how
> >> >>> > the
> >> >>> > >> > DAS component is provided. We could have multiple
> >> declarative
> >> >>> > >> > implementations, say one based on RDB-DAS and one that did
> >> >>> stuff
> >> >>> > with
> >> >>> > >> > XML databases like Xindice; alternatively, /without
> >> altering
> >> >>> the
> >> >>> > >> > client at all/ they could switch to a custom coded version
> >> >>> written
> >> >>> > in
> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
> >> >>> > >> >
> >> >>> > >> > --
> >> >>> > >> > Jeremy
> >> >>> > >> >
> >> >>> > >> >
> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >> >>> > >> >
> >> >>> > >> >> 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 code specific to
> >> a new
> >> >>> > >> >> service. Instead, the service will be "instantiated"
> >> based
> >> >>> on the
> >> >>> >
> >> >>> > >> >> provided DAS config file. The service interface
> >> might look
> >> >>> like
> >> >>> > >> this:
> >> >>> > >> >>
> >> >>> > >> >> public interface RDBDASService
> >> >>> > >> >> DataObject execute(String commandName);
> >> >>> > >> >> DataObject executeSQL(String abitrarySQL);
> >> >>> > >> >> void applyChanges(DataObject graphRoot);
> >> >>> > >> >> }
> >> >>> > >> >>
> >> >>> > >> >> So, depending on the config file used to instantiate the
> >> >>> service,
> >> >>> > >> >> this interface could be used to return Customers/
> >> Accounts or
> >> >>> > >> >> Toasters. In fact, a lot could be achieved with no
> >> >>> > configuration at
> >> >>> > >> >> all by restricting use to: DataObject executeSQL(String
> >> >>> > >> abitrarySQL);
> >> >>> > >> >>
> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
> >> >>> mod_mbox/ws-
> >> >>> > >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net %3e
> >> >>> > >> >>
> >> >>> > >> >> Once this was working it should be straightforward to
> >> build
> >> >>> more
> >> >>> > >> >> strongly typed services and possible put together some
> >> >>> generation
> >> >>> > >> >> tooling. We could also start looking at support for a
> >> more
> >> >>> > RESTFul
> >> >>> > >> >> interface.
> >> >>> > >> >> --
> >> >>> > >> >> Kevin
> >> >>> > >> >>
> >> >>> > >> >>
> >> >>> > >> >>
> >> >>> > >> >>
> >> >>> > >> >> Luciano Resende wrote:
> >> >>> > >> >>
> >> >>> > >> >>> Recently, people have been starting to talk about
> >> better DAS
> >> >>> > >> >>> integration
> >> >>> > >> >>> with DAS, and below are some threads on the subject :
> >> >>> > >> >>>
> >> >>> > >> >>>
> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> msg08833.html
> >> >>> > >> >>>
> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> msg08923.html
> >> >>> > >> >>>
> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >>> msg09715.html
> >> >>> >
> >> >>> > >> >>>
> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
> >> what I'm
> >> >>> > >> >>> saying is not
> >> >>> > >> >>> yet available on SCA today.
> >> >>> > >> >>>
> >> >>> > >> >>> Today, defining a service to work with a relational
> >> >>> database, you
> >> >>> > >> >>> will need
> >> >>> > >> >>> to code the persistence side of the service where CRUD
> >> >>> operations
> >> >>> > >> >>> to the
> >> >>> > >> >>> database will be done.
> >> >>> > >> >>> I was thinking on a simpler, easier way, where coding
> >> the
> >> >>> CRUD
> >> >>> > >> >>> operations on
> >> >>> > >> >>> the persistence layer would be avoided as much as
> >> possible.
> >> >>> > >> >>> The idea would be to have a more "declarative DAS" when
> >> >>> defining
> >> >>> > SCA
> >> >>> > >> >>> Services, so you would either use some Annotations
> >> or SCDL
> >> to
> >> >>> > >> have the
> >> >>> > >> >>> "declarative DAS" configuration inside it.
> >> >>> > >> >>>
> >> >>> > >> >>> I was thinking on something like....
> >> >>> > >> >>>
> >> >>> > >> >>> SCDL Definition would look something like this :
> >> >>> > >> >>>
> >> >>> > >> >>> <component name="AccountDataService">
> >> >>> > >> >>> <interface.java
> >> >>> > >> >>>
> >> class="bigbank.account.services.account.AccountService"/>
> >> >>> > >> >>> <implementation.das="dasConfig.properties"
> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >>> > >> >>> </component>
> >> >>> > >> >>>
> >> >>> > >> >>> The AccountService Interface would look like this
> >> (missing
> >> >>> any
> >> >>> > SCA
> >> >>> > >> >>> annotations):
> >> >>> > >> >>>
> >> >>> > >> >>> public interface AccountService {
> >> >>> > >> >>>
> >> >>> > >> >>> public List getAllCustomers();
> >> >>> > >> >>> public Object getCustomerAccount(String
> >> accountNumber);
> >> >>> > >> >>> }
> >> >>> > >> >>>
> >> >>> > >> >>> The DAS config would look like this, and would have the
> >> >>> > definition
> >> >>> > >> >>> for the
> >> >>> > >> >>> "all companies" command.
> >> >>> > >> >>>
> >> >>> > >> >>> <Config ...>
> >> >>> > >> >>> ...
> >> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
> >> bigbank"/>
> >> >>> > >> >>>
> >> >>> > >> >>> <Command name="getAllCustomers" SQL="select * from
> >> >>> CUSTOMERS"
> >> >>> > >> >>> kind="Select"/>
> >> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
> >> >>> accountNumber,
> >> >>> > >> >>> accountType, balance FROM accounts where
> >> accountNumber = ?"
> >> >>> > >> >>> kind="Select" />
> >> >>> > >> >>> ...
> >> >>> > >> >>> </Config>
> >> >>> > >> >>>
> >> >>> > >> >>>
> >> >>> > >> >>> Mapping between interface methods and DAS Commands
> >> >>> > >> >>> - If a DAS config file is provided, based on the
> >> >>> > SCDL definition,
> >> >>> > >> we
> >> >>> > >> >>> would look for "DAS command" based on the name of the
> >> getter
> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> >> command)
> >> >>> > >> >>> - Otherwise, we would try to do a map directly to a
> >> >>> > >> stored procedure
> >> >>> > >> >>> - We could also have a way to force the mapping by
> >> using
> >> >>> > >> annotation
> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >>> > >> >>>
> >> >>> > >> >>> Mapping between method parameter and command parameter
> >> >>> > >> >>> - We would need to define a method for mapping the
> >> method
> >> >>> > >> >>> parameters to
> >> >>> > >> >>> the query paramters either based on position ( e.g first
> >> >>> method
> >> >>> > >> >>> parameter
> >> >>> > >> >>> maps to the first command paramter), or we would do some
> >> >>> > mapping by
> >> >>> > >> >>> name
> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >>> > >> >>>
> >> >>> > >> >>> Note:
> >> >>> > >> >>> - A SCDL connection information would override the DAS
> >> >>> Config
> >> >>> > file
> >> >>> > >> >>> connection information.
> >> >>> > >> >>>
> >> >>> > >> >>>
> >> >>> > >> >>> Benefits
> >> >>> > >> >>> - It's All about simplicity and easy of use
> >> >>> > >> >>> - This would allow a user to define a service without
> >> >>> having to
> >> >>> >
> >> >>> > >> >>> explicitly having to code any Data Access related code.
> >> >>> > >> >>>
> >> >>> > >> >>>
> >> >>> > >> >>> Implementation approaches
> >> >>> > >> >>> - Utilizing DAS : This approach would start from the
> >> >>> current
> >> >>> > >> >>> Tuscany DAS
> >> >>> > >> >>> implementation, where functionality would be already
> >> >>> > available, but
> >> >>> > >> >>> the
> >> >>> > >> >>> service implementation would be tied to SDO and RDB
> >> as this
> >> >>> > is what
> >> >>> > >> >>> DAS
> >> >>> > >> >>> supports today.
> >> >>> > >> >>>
> >> >>> > >> >>> - Start simple and grow : We could start simple, by
> >> >>> having a
> >> >>> > >> simple
> >> >>> > >> >>> implementation based on JDBC and would return some
> >> simple
> >> >>> > >> >>> collection as a
> >> >>> > >> >>> return type (e.g List or a even a Recordset), this could
> >> >>> give us
> >> >>> > a
> >> >>> > >> >>> quick
> >> >>> > >> >>> start to flush implementation details and get a proven
> >> >>> design,
> >> >>> > and
> >> >>> > >> >>> this
> >> >>> > >> >>> could get evolved to use a DAS that would support
> >> multiple
> >> >>> > backends
> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
> >> non- SDO
> >> >>> types
> >> >>> > >> as a
> >> >>> > >> >>> command
> >> >>> > >> >>> result.
> >> >>> > >> >>>
> >> >>> > >> >>>
> >> >>> > >> >>> Toughts ?
> >> >>> > >> >>>
> >> >>> > >> >>> - Luciano
> >> >>> > >> >>>
> >> >>> > >> >>>
> >> >>> > >> >>>
> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >>> > >> >>>
> >> >>> > >> >>>>
> >> >>> > >> >>>> 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. Another thing we want to eventually
> >> >>> explore is
> >> >>> > >> >>>> exposing
> >> >>> > >> >>>> a DAS as REST-oriented services. As we have seen
> >> from the
> >> >>> > parent
> >> >>> > >> >>>> thread
> >> >>> > >> >>>> there are almost too many possible approaches.
> >> >>> > >> >>>>
> >> >>> > >> >>>> My first thought is to model the DAS as a service and
> >> >>> create a
> >> >>> > new
> >> >>> > >> >>>> implementation kind (implementation.rdbdas). The main
> >> >>> reason
> >> >>> > has
> >> >>> > >> >>>> to do
> >> >>> > >> >>>> with the potential declarative aspect of DAS that
> >> >>> > Jeremy mentioned
> >> >>> > >> >>>> which
> >> >>> > >> >>>> is all about creating data access services
> >> >>> declaratively. A new
> >> >>> > >> >>>> component type and a service that we build by hand
> >> would be
> >> >>> > a good
> >> >>> > >> >>>> step
> >> >>> > >> >>>> in this direction.
> >> >>> > >> >>>>
> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> interface like
> >> >>> > this:
> >> >>> > >> >>>>
> >> >>> > >> >>>> public interface RDBDASService
> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >> >>> > >> >>>> DataObject execute(String commandName);
> >> >>> > >> >>>> DataObject executeSQL(String abitrarySQL);
> >> >>> > >> >>>> }
> >> >>> > >> >>>>
> >> >>> > >> >>>> The service would be initialized with an optional
> >> RDB DAS
> >> >>> > >> config file
> >> >>> > >> >>>> that defines connection properties, a set of commands,
> >> >>> etc. So,
> >> >>> > >> >>>> different services implementing the same interface
> >> could be
> >> >>> > >> >>>> initialized
> >> >>> > >> >>>> from separate config files.
> >> >>> > >> >>>>
> >> >>> > >> >>>> Eventually, we might want to build services like this:
> >> >>> > >> >>>>
> >> >>> > >> >>>> public interface Customers_RDBDASService
> >> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >> >>> > >> >>>> DataObject getAllCustomersWithLastName (String
> >> >>> > lastName);
> >> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID (int
> >> >>> > customerId);
> >> >>> > >> >>>> }
> >> >>> > >> >>>>
> >> >>> > >> >>>> But, for this to be very useful would probably require
> >> >>> some code
> >> >>> > >> >>>> generation tooling.
> >> >>> > >> >>>>
> >> >>> > >> >>>> Thoughts?
> >> >>> > >> >>>>
> >> >>> > >> >>>> --Kevin
> >> >>> > >> >>>>
> >> >>> > >> >>>>
> >> >>> > >> >>>> Luciano Resende wrote:
> >> >>> > >> >>>>
> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> >> declarative
> >> >>> > DAS and
> >> >>> > >> >>>> will be
> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
> >> >>> > >> >>>> >
> >> >>> > >> >>>> > - Luciano
> >> >>> > >> >>>> >
> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
> >> 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 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.
> >> >>> > >> >>>> >>
> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
> >> >>> > should welcome
> >> >>> > >> it
> >> >>> > >> >>>> >> like we would any other contribution.
> >> >>> > >> >>>> >>
> >> >>> > >> >>>> >> >> 3) to access data through an application
> >> service with
> >> >>> > >> >>>> declarative
> >> >>> > >> >>>> >> >> implementation by DAS
> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >>> > >> >>>> >>
> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
> >> >>> > >> >>>> >> --
> >> >>> > >> >>>> >> Jeremy
> >> >>> > >> >>>> >>
> >> >>> > >> >>>> >>
> >> >>> > >> >>>>
> >> >>> > >>
> >> >>>
> >> --------------------------------------------------------------------
> >> >>> > >> -
> >> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
> >> >>> unsubscribe@ws.apache.org
> >> >>> > >> >>>> >> For additional commands, e-mail:
> >> >>> > tuscany-dev-help@ws.apache.org
> >> >>> > >> >>>> >>
> >> >>> > >> >>>> >>
> >> >>> > >> >>>> >
> >> >>> > >> >>>>
> >> >>> > >> >>>>
> >> >>> > >> >>>>
> >> >>> > >> >>>>
> >> >>> > >>
> >> >>>
> >> --------------------------------------------------------------------
> >> >>> > >> -
> >> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
> >> >>> unsubscribe@ws.apache.org
> >> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
> >> >>> help@ws.apache.org
> >> >>> > >> >>>>
> >> >>> > >> >>>>
> >> >>> > >> >>>
> >> >>> > >> >>
> >> >>> > >> >>
> >> >>> > >> >>
> >> >>> > >> >>
> >> >>> >
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
> >> unsubscribe@ws.apache.org
> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
> >> >>> help@ws.apache.org
> >> >>> > >> >>
> >> >>> > >> >
> >> >>> > >> >
> >> >>> > >> >
> >> >>> >
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
> >> unsubscribe@ws.apache.org
> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
> >> help@ws.apache.org
> >> >>> > >> >
> >> >>> > >> >
> >> >>> > >> >
> >> >>> > >> >
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> > >> To unsubscribe, e-mail: tuscany-dev-
> >> unsubscribe@ws.apache.org
> >> >>> > >> For additional commands, e-mail: tuscany-dev-
> >> help@ws.apache.org
> >> >>> > >>
> >> >>> > >>
> >> >>> > >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>>
> >> >>>
> >> >>>
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> Hi,
>
> I would also like to understand this a little better ... here I am
> thinking
> aloud and hope the others will help in getting my persceptions
> right...
>
> I guess firstly it is a question of how or where we want to
> position 'DAS
> Integration' in SCA. Is is something we want to integrate as the
> Application Layer, which I understand is what Amita is trying
> presently and
> which Jim refers to as component implementation. In this option
> we get to
> do some sort of a service wrapper to DAS and then it becomes a
> demonstration
> of two Tuscany subprojects integrating at application level.
>
> Or do we want to position DAS at the infrastructure layer as another
> extension type (either container or binding). I guess this is
> where Ant
> started this - proposing a JDBC container / binding for component
> implementation in StoredProcedures.
I was thinking a DAS was a way to declaratively model heterogeneous
data as a service and offer a mechanism for remoting that data. In
other words, it provided the ability for an application to perform
CRUD using a high-level contract (interface) and having those
operations take place across a service network. How this is hooked
into the SCA container is probably best done as an extension type,
i.e. someone could specify:
<component name="Foo">
<implementation.das>
<interface.java ....>
</implementation.das>
</component>
> If this is the path we should take
> then we probably have to think beyond DAS - to something more
> general - of
> which DAS is just a special case. I suppose this is what Jim has also
> suggested in trying to explore other persistence mechanisms.
>
This may be the crux of the confusion. I was thinking DAS provides a
general mechanism for accessing heterogeneous data and is only right
now tied to SQL because of resource constraints (i.e. we have to
start somewhere). Ultimately, DAS should provide the infrastructure
for dealing with multiple, varied data stores and mechanisms for
querying across them. In other words, I guess I am saying DAS should
be the general solution (declarative and heterogeneous) since if it
is only a programmatic way to access relational data then its value
is less clear in comparison to things such as JDBC 4 or JPA.
> I too feel that this is something that must be done as an extension
> type -
> but yet to get my hands on the general scheme of things that DAS
> can slip
> into. Infact the other thread where Jeremy has taken forward a
> proposal to
> the specs group on resources tempts me to think that there is going
> to be
> something in that which we can leverage from.
>
I think resources are orthogonal as they are about a component
implementation's contract with its container. Declarative data
services on the other hand are about application constructs that can
be wired to.
> I hope to get a better understanding this as we go along in this
> thread :)
>
Me too :-) As soon as I have trouble explaining technologies to .NET
people and they say "you Unix/Java people are at it again with a
thousand ways to do the same exact thing" it causes me to think that
maybe we need to clarify our message.
Jim
> Thanks
>
> - Venkat
>
> On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>>
>> Jim Marino wrote:
>>
>> > When I first read the thread on this, I thought the DAS service
>> would
>> > be a component extension type (e.g. analogous to a
>> > implementation.java or implementation.ejb) and not a component
>> > implementation type, which would allow for dynamic and eventually
>> > declarative configuration styles.
>>
>> I have not very familiar with the terminology so I am not sure what a
>> "component extension type" is. But, I do think we eventually want
>> "implementation.rdbdas". Wouldn't this be a new implementation type?
>>
>> It looks like Amita chose to start with a POJO. I notice the use
>> of "
>> implementation.java".
>>
>> > Either way, though, I am curious as to why
>> >
>> > public DAS configureService(String configFile);
>> >
>> > exists as part of the service definition? If the DAS service was a
>> > component extension type, it could be handled as part of the
>> > application bootstrap. If the DAS service was a component
>> > implementation type, the configuration file URI could be passed
>> in as
>> > a property and then processed in an initializer method decorated by
>> > the SCA @Init annotation. In the latter case, if the implementation
>> > of DASService thread-safe (hopefully it is since configuration
>> would
>> > seem to be a heavyweight operation), then I would make the
>> component
>> > module scoped to avoid initialization overhead on every resolution.
>>
>> >
>> > In both approaches (extension vs. implementation type), having
>> > configuration exposed to the application doesn't quite feel right,
>> > since that is what DI tries to externalize.
>>
>> I agree. The configuration should be part of the initialization and
>> should use SCA patterns to do this. I think that Amita meant to use
>> eventually use a component property for the DAS config info but
>> started
>> with a method.
>>
>> >
>> > Also, I was thinking that in having this a component extension
>> type,
>> > the service interfaces returned from a resolution could include the
>> > dynamic one described below or static ones people have mentioned. I
>> > guess it is best to start with the easier-to-implement part
>> first and
>> > support the dynamic interface.
>> >
>> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
>> > understand what DAS provides in relation to other persistence
>> > technologies. Outside of the Java world, Microsoft is promoting
>> LINQ
>> > which is really interesting, and it would be informative to compare
>> > the goals of DAS with that approach (there are obvious differences
>> > such as having the query language a strongly-typed part of the
>> > programming language, e.g. C#, and LINQ's use of closures).
>> >
>> > In contrasting DAS to O-R technologies, I see the primary use cases
>> > for the former being a quick way to issue a query that may be
>> > executed against *heterogeneous* data stores and have that data
>> flow
>> > remotely or to a client that is not necessarily Java-based. One key
>> > for me is heterogeneous data since JDBC 4 lets me do this
>> (Hibernate
>> > and JPA are about as easy):
>> >
>> IMO the primary use case for DAS is an application that is SDO-
>> centric
>> and is taking advantage of its disconnected capabilities. The RDB
>> DAS
>> is built to work with SDO and uses the change summary to drive
>> changes
>> made to a disconnected data graph back to some store. This is not to
>> say that a relational DAS could not be built on top of JPA, in fact,
>> this might be a very useful thing to do. The implementation we
>> currently have provides a very straightforward implicit mapping from
>> DataObjects to Tables. If more capable mapping is needed then it
>> makes
>> sense to use the JPA-defined technology and artifacts. A modified
>> Entity manager might be needed to take advantage of SDO's change
>> summary.
>>
>> >
>> > public interface CustomerDao extends BaseQuery {
>> > @Select("select * from customers where city = ?1")
>> > DataSet<Customer> findCustomersFrom(String city);
>> > }
>> >
>> > CustomerDao cd = QueryObjectFactory.createQueryObject
>> > (CustomerDao.class, datasource);
>> > DataSet<Customer> r = cd.findCustomersFrom(city);
>> >
>> >
>> > The other key is remote data and change lists. I think there are
>> > (literally) about a thousand ways that already exist to handle the
>> > "local" data case. For change lists, interop with ADO.NET's change
>> > summary facilities would be interesting.
>>
>> I agree. Also, it looks like Xcalia may have a similar thought:
>> http://www.xcalia.com/news/PR_2006-10-23.jsp
>>
>> >
>> > I'm playing devil's advocate a bit with DAS, but I think it is
>> > important we have a clear statement as to when it is appropriate
>> and
>> > not appropriate to use. One place to start would be to compare
>> it to
>> > JDBC 4 and JPA.
>>
>> We can get started with JPA:
>>
>> * JPA is java-specific, container-based, built around a connected
>> data model and offers a complete O/R mapping for POJOs
>>
>> * The RDB DAS is a java implementation of a language - neutral
>> concept (hopefully specified some day) that is containerless,
>> assumes a disconnected data model and provides a simple,
>> implicit
>> mapping for SDO DataObjects (Dynamic or Static) to relational
>> tables.
>>
>> Anything else?
>>
>> >
>> > Jim
>> >
>> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>> >
>> >> Hi Amita
>> >>
>> >> I think we were both going on the same way, with the DAS Service
>> >> sample,
>> >> altough i had the interface more like this, to be more flexible :
>> >>
>> >> public interface DASService {
>> >>
>> >> public DAS configureService(String configFile);
>> >
>> >
>> >> public DataObject executeCommand(String commandName);
>> >> public DataObject execute(String newCommand);
>> >> public void applyChanges(DataObject graphRoot);
>> >> }
>> >>
>> >>
>> >> As for having it as a sample, maybe we could defined the
>> DASService
>> >> as one
>> >> sample itself, and have a second version of companyWeb that would
>> >> consume
>> >> the service, something like :
>> >>
>> >> das\samples\companyWeb
>> >> das\samples\dasService
>> >> das\samples.companyWeb.service
>> >>
>> >> or, more like BigBank
>> >>
>> >> das\samples\companyweb.Service\dasService
>> >> das\samples\companyweb.Service\webClient
>> >>
>> >> Or even in sampleApps...
>> >>
>> >> Toughts ?
>> >>
>> >>
>> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
>> >>
>> >>>
>> >>> Hi ,
>> >>> I am also following up another thread
>> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> msg09944.html
>> >>> on the
>> >>> similar issue (JDBC stored procedure container
>> >>> using DAS)
>> >>> Besides the fact that I am actively working on the container
>> work,
>> >>> I also
>> >>> have tried to
>> >>> develop a sample based on the below discussion, following dynamic
>> >>> approach.
>> >>>
>> >>> I am attaching the same here. Please take a look and give your
>> >>> suggestions.
>> >>> In this, StoredProcedureService implementation has
>> setConfigInfo (DAS
>> >>> Config) and
>> >>> execute(Any SQL). This can be made more complete with
>> executeSQL(),
>> >>> applyChanges()
>> >>> etc.
>> >>>
>> >>> Can this be added to the existing set of samples?
>> >>>
>> >>> Regards,
>> >>> Amita
>> >>>
>> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >>> >
>> >>> > Luciano Resende wrote:
>> >>> >
>> >>> > > Kevin, from what I understood from your suggestion, it was
>> >>> looking to
>> >>> > me
>> >>> > > more like exposing DAS as a service :
>> >>> > >
>> >>> > >>> public interface RDBDASService
>> >>> > >>> DataObject execute(String commandName);
>> >>> > >>> DataObject executeSQL(String abitrarySQL);
>> >>> > >>> void applyChanges(DataObject graphRoot);
>> >>> > >>> }
>> >>> > >>
>> >>> > Yes, I am talking about exposing a DAS Service configured
>> with a
>> >>> > specific set of capabilities/commands defined in the DAS config
>> >>> file.
>> >>> > So, if the implementation of the service interface above was
>> >>> configured
>> >>> > to work with Customers they would use the service like this:
>> >>> >
>> >>> > List customers = myRDBDASService.execute("getAllCustomers");
>> >>> > String name = customers.get(0).getString("name");
>> >>> >
>> >>> > This is not much different than the static interface you
>> proposed,
>> >>> > right?
>> >>> >
>> >>> > > And then, when a service developer defines the
>> AccountService,
>> >>> he will
>> >>> >
>> >>> > > have
>> >>> > > to know about yet another service, about how DAS works,
>> how it is
>> >>> > > configured, etc, etc... is that right ?
>> >>> > >
>> >>> > The abilities of the service are defined by the DAS config
>> file.
>> >>> So,
>> >>> > the person or tool that provides the config file must
>> understand
>> >>> how the
>> >>> >
>> >>> > RDB DAS APIs work. There is no getting around this.
>> >>> >
>> >>> > > My proposal was going more towards allowing the service
>> >>> developer to
>> >>> > > focus
>> >>> > > on defining the service, and let the "declarative das" to
>> >>> handle the
>> >>> > > persistent layer....
>> >>> > >
>> >>> > The DAS config file is the declaration of an instance of the
>> >>> DAS. That
>> >>> > instance can be exposed as a dynamic or typed service/
>> interface.
>> >>> That
>> >>> > seems to be the main discussion we are having. Although, I
>> may be
>> >>> > missing something.
>> >>> >
>> >>> > > Also, by defining some conventions over configuration
>> and/or using
>> >>> > > annotations (e.g @Procedure to force mapping to a stored
>> >>> procedure),
>> >>> > the
>> >>> > > service developer could really define a service that
>> interacts
>> >>> with a
>> >>> > > RDB,
>> >>> > > without having to code the service persistence layer.
>> >>> > >
>> >>> > There is a lot of potential for the use of annotations.
>> >>> >
>> >>> > >
>> >>> > > - Luciano
>> >>> > >
>> >>> > >
>> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
>> >>> > >
>> >>> > >>
>> >>> > >> The real difference between the two approaches is that
>> one is
>> >>> "Typed"
>> >>> > or
>> >>> > >> static and the other is dynamic. I think both are needed
>> but was
>> >>> > >> suggesting that we start with dynamic since it is the most
>> >>> flexible
>> >>> > and
>> >>> > >> seems to be a reasonable stepping stone towards a static
>> >>> capability.
>> >>> > >>
>> >>> > >> With either, the user does not need to know about
>> traditional
>> >>> > >> persistence frameworks. With the dynamic approach, however,
>> >>> the user
>> >>> > >> does need to know about the dynamic SDO API.
>> >>> > >>
>> >>> > >> So, with the static interface the user might write:
>> >>> > >>
>> >>> > >> List customers = accountService.getAllCustomers();
>> >>> > >> String name = ((Customer)customers.get(0)).getName();
>> >>> > >>
>> >>> > >> The equivalent dynamic API might be:
>> >>> > >>
>> >>> > >> List customers = dasService.execute("getAllCustomers");
>> >>> > >> String name = ((DataObject)customers.get(0)).getString
>> >>> ("name");
>> >>> > >>
>> >>> > >> The first is probably a little easier for the application
>> >>> developer
>> >>> > but
>> >>> > >> the second is much easier for the service developer. IMO,
>> the
>> >>> dynamic
>> >>> > >> case is the best place to start and, again, we
>> definitely will
>> >>> want
>> >>> > >> support for both.
>> >>> > >>
>> >>> > >> Thanks.
>> >>> > >> --
>> >>> > >> Kevin
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >> Jeremy Boynes wrote:
>> >>> > >>
>> >>> > >> > I think this would be useful but it seems more like a
>> >>> traditional
>> >>> > >> > persistence API than what Luciano was suggesting. With
>> this
>> >>> one a
>> >>> > >> > user needs to know about DataObject's, commands, SQL
>> strings
>> >>> etc.
>> >>> > >> > just like they would if they were using raw JDBC or JPA.
>> >>> > >> >
>> >>> > >> > On the other hand, Luciano's proposal seemed more about
>> >>> expressing
>> >>> > >> > high-level CRUD operations as operations on a service
>> >>> interface:
>> >>> > >> >
>> >>> > >> >>> public interface AccountService {
>> >>> > >> >>>
>> >>> > >> >>> public List getAllCustomers();
>> >>> > >> >>> public Object getCustomerAccount(String
>> accountNumber);
>> >>> > >> >>> }
>> >>> > >> >>
>> >>> > >> >
>> >>> > >> > which is all application level concepts rather
>> than persistence
>> >>> > level
>> >>> > >> > concepts. I'd actually go a little further and put that
>> >>> right into
>> >>> > >> > the service contract:
>> >>> > >> >
>> >>> > >> > public interface AccountService {
>> >>> > >> > List<Customer> getAllCustomers();
>> >>> > >> > Account getCustomerAccount(String accountNumber);
>> >>> > >> > }
>> >>> > >> >
>> >>> > >> > In a ideal world, if the user was able to accept
>> standardized
>> >>> > >> > mappings (a la Rails et al) then no further configuration
>> >>> would be
>> >>> > >> > needed except to add this to the logical assembly:
>> >>> > >> >
>> >>> > >> > <component name="AccountStore">
>> >>> > >> > <implementation.das resource="MySQLDatabase"/>
>> >>> > >> > </component>
>> >>> > >> >
>> >>> > >> > With SCA's ability to translate service contracts, this
>> >>> should be
>> >>> > >> > callable from and deployable to any SCA runtime
>> regardless of
>> >>> > whether
>> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
>> running on
>> a
>> >>> > Java,
>> >>> > >> > C++ or PHP platform.
>> >>> > >> >
>> >>> > >> > The important thing here is that the client is
>> isolated from
>> >>> how
>> >>> > the
>> >>> > >> > DAS component is provided. We could have multiple
>> declarative
>> >>> > >> > implementations, say one based on RDB-DAS and one that did
>> >>> stuff
>> >>> > with
>> >>> > >> > XML databases like Xindice; alternatively, /without
>> altering
>> >>> the
>> >>> > >> > client at all/ they could switch to a custom coded version
>> >>> written
>> >>> > in
>> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
>> >>> > >> >
>> >>> > >> > --
>> >>> > >> > Jeremy
>> >>> > >> >
>> >>> > >> >
>> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>> >>> > >> >
>> >>> > >> >> 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 code specific to
>> a new
>> >>> > >> >> service. Instead, the service will be "instantiated"
>> based
>> >>> on the
>> >>> >
>> >>> > >> >> provided DAS config file. The service interface
>> might look
>> >>> like
>> >>> > >> this:
>> >>> > >> >>
>> >>> > >> >> public interface RDBDASService
>> >>> > >> >> DataObject execute(String commandName);
>> >>> > >> >> DataObject executeSQL(String abitrarySQL);
>> >>> > >> >> void applyChanges(DataObject graphRoot);
>> >>> > >> >> }
>> >>> > >> >>
>> >>> > >> >> So, depending on the config file used to instantiate the
>> >>> service,
>> >>> > >> >> this interface could be used to return Customers/
>> Accounts or
>> >>> > >> >> Toasters. In fact, a lot could be achieved with no
>> >>> > configuration at
>> >>> > >> >> all by restricting use to: DataObject executeSQL(String
>> >>> > >> abitrarySQL);
>> >>> > >> >>
>> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
>> >>> mod_mbox/ws-
>> >>> > >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net %3e
>> >>> > >> >>
>> >>> > >> >> Once this was working it should be straightforward to
>> build
>> >>> more
>> >>> > >> >> strongly typed services and possible put together some
>> >>> generation
>> >>> > >> >> tooling. We could also start looking at support for a
>> more
>> >>> > RESTFul
>> >>> > >> >> interface.
>> >>> > >> >> --
>> >>> > >> >> Kevin
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >> Luciano Resende wrote:
>> >>> > >> >>
>> >>> > >> >>> Recently, people have been starting to talk about
>> better DAS
>> >>> > >> >>> integration
>> >>> > >> >>> with DAS, and below are some threads on the subject :
>> >>> > >> >>>
>> >>> > >> >>>
>> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> msg08833.html
>> >>> > >> >>>
>> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> msg08923.html
>> >>> > >> >>>
>> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> >>> msg09715.html
>> >>> >
>> >>> > >> >>>
>> >>> > >> >>> I'm new on the SCA side, so please help me make sure
>> what I'm
>> >>> > >> >>> saying is not
>> >>> > >> >>> yet available on SCA today.
>> >>> > >> >>>
>> >>> > >> >>> Today, defining a service to work with a relational
>> >>> database, you
>> >>> > >> >>> will need
>> >>> > >> >>> to code the persistence side of the service where CRUD
>> >>> operations
>> >>> > >> >>> to the
>> >>> > >> >>> database will be done.
>> >>> > >> >>> I was thinking on a simpler, easier way, where coding
>> the
>> >>> CRUD
>> >>> > >> >>> operations on
>> >>> > >> >>> the persistence layer would be avoided as much as
>> possible.
>> >>> > >> >>> The idea would be to have a more "declarative DAS" when
>> >>> defining
>> >>> > SCA
>> >>> > >> >>> Services, so you would either use some Annotations
>> or SCDL
>> to
>> >>> > >> have the
>> >>> > >> >>> "declarative DAS" configuration inside it.
>> >>> > >> >>>
>> >>> > >> >>> I was thinking on something like....
>> >>> > >> >>>
>> >>> > >> >>> SCDL Definition would look something like this :
>> >>> > >> >>>
>> >>> > >> >>> <component name="AccountDataService">
>> >>> > >> >>> <interface.java
>> >>> > >> >>>
>> class="bigbank.account.services.account.AccountService"/>
>> >>> > >> >>> <implementation.das="dasConfig.properties"
>> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> >>> > >> >>> </component>
>> >>> > >> >>>
>> >>> > >> >>> The AccountService Interface would look like this
>> (missing
>> >>> any
>> >>> > SCA
>> >>> > >> >>> annotations):
>> >>> > >> >>>
>> >>> > >> >>> public interface AccountService {
>> >>> > >> >>>
>> >>> > >> >>> public List getAllCustomers();
>> >>> > >> >>> public Object getCustomerAccount(String
>> accountNumber);
>> >>> > >> >>> }
>> >>> > >> >>>
>> >>> > >> >>> The DAS config would look like this, and would have the
>> >>> > definition
>> >>> > >> >>> for the
>> >>> > >> >>> "all companies" command.
>> >>> > >> >>>
>> >>> > >> >>> <Config ...>
>> >>> > >> >>> ...
>> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/
>> bigbank"/>
>> >>> > >> >>>
>> >>> > >> >>> <Command name="getAllCustomers" SQL="select * from
>> >>> CUSTOMERS"
>> >>> > >> >>> kind="Select"/>
>> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
>> >>> accountNumber,
>> >>> > >> >>> accountType, balance FROM accounts where
>> accountNumber = ?"
>> >>> > >> >>> kind="Select" />
>> >>> > >> >>> ...
>> >>> > >> >>> </Config>
>> >>> > >> >>>
>> >>> > >> >>>
>> >>> > >> >>> Mapping between interface methods and DAS Commands
>> >>> > >> >>> - If a DAS config file is provided, based on the
>> >>> > SCDL definition,
>> >>> > >> we
>> >>> > >> >>> would look for "DAS command" based on the name of the
>> getter
>> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
>> command)
>> >>> > >> >>> - Otherwise, we would try to do a map directly to a
>> >>> > >> stored procedure
>> >>> > >> >>> - We could also have a way to force the mapping by
>> using
>> >>> > >> annotation
>> >>> > >> >>> (e.g@Procedure on the method level)
>> >>> > >> >>>
>> >>> > >> >>> Mapping between method parameter and command parameter
>> >>> > >> >>> - We would need to define a method for mapping the
>> method
>> >>> > >> >>> parameters to
>> >>> > >> >>> the query paramters either based on position ( e.g first
>> >>> method
>> >>> > >> >>> parameter
>> >>> > >> >>> maps to the first command paramter), or we would do some
>> >>> > mapping by
>> >>> > >> >>> name
>> >>> > >> >>> (currently not available in Tuscany DAS)
>> >>> > >> >>>
>> >>> > >> >>> Note:
>> >>> > >> >>> - A SCDL connection information would override the DAS
>> >>> Config
>> >>> > file
>> >>> > >> >>> connection information.
>> >>> > >> >>>
>> >>> > >> >>>
>> >>> > >> >>> Benefits
>> >>> > >> >>> - It's All about simplicity and easy of use
>> >>> > >> >>> - This would allow a user to define a service without
>> >>> having to
>> >>> >
>> >>> > >> >>> explicitly having to code any Data Access related code.
>> >>> > >> >>>
>> >>> > >> >>>
>> >>> > >> >>> Implementation approaches
>> >>> > >> >>> - Utilizing DAS : This approach would start from the
>> >>> current
>> >>> > >> >>> Tuscany DAS
>> >>> > >> >>> implementation, where functionality would be already
>> >>> > available, but
>> >>> > >> >>> the
>> >>> > >> >>> service implementation would be tied to SDO and RDB
>> as this
>> >>> > is what
>> >>> > >> >>> DAS
>> >>> > >> >>> supports today.
>> >>> > >> >>>
>> >>> > >> >>> - Start simple and grow : We could start simple, by
>> >>> having a
>> >>> > >> simple
>> >>> > >> >>> implementation based on JDBC and would return some
>> simple
>> >>> > >> >>> collection as a
>> >>> > >> >>> return type (e.g List or a even a Recordset), this could
>> >>> give us
>> >>> > a
>> >>> > >> >>> quick
>> >>> > >> >>> start to flush implementation details and get a proven
>> >>> design,
>> >>> > and
>> >>> > >> >>> this
>> >>> > >> >>> could get evolved to use a DAS that would support
>> multiple
>> >>> > backends
>> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
>> non- SDO
>> >>> types
>> >>> > >> as a
>> >>> > >> >>> command
>> >>> > >> >>> result.
>> >>> > >> >>>
>> >>> > >> >>>
>> >>> > >> >>> Toughts ?
>> >>> > >> >>>
>> >>> > >> >>> - Luciano
>> >>> > >> >>>
>> >>> > >> >>>
>> >>> > >> >>>
>> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
>> >>> > >> >>>
>> >>> > >> >>>>
>> >>> > >> >>>> 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. Another thing we want to eventually
>> >>> explore is
>> >>> > >> >>>> exposing
>> >>> > >> >>>> a DAS as REST-oriented services. As we have seen
>> from the
>> >>> > parent
>> >>> > >> >>>> thread
>> >>> > >> >>>> there are almost too many possible approaches.
>> >>> > >> >>>>
>> >>> > >> >>>> My first thought is to model the DAS as a service and
>> >>> create a
>> >>> > new
>> >>> > >> >>>> implementation kind (implementation.rdbdas). The main
>> >>> reason
>> >>> > has
>> >>> > >> >>>> to do
>> >>> > >> >>>> with the potential declarative aspect of DAS that
>> >>> > Jeremy mentioned
>> >>> > >> >>>> which
>> >>> > >> >>>> is all about creating data access services
>> >>> declaratively. A new
>> >>> > >> >>>> component type and a service that we build by hand
>> would be
>> >>> > a good
>> >>> > >> >>>> step
>> >>> > >> >>>> in this direction.
>> >>> > >> >>>>
>> >>> > >> >>>> We might want to expose a DAS service with an
>> interface like
>> >>> > this:
>> >>> > >> >>>>
>> >>> > >> >>>> public interface RDBDASService
>> >>> > >> >>>> void applyChanges(DataObject graphRoot);
>> >>> > >> >>>> DataObject execute(String commandName);
>> >>> > >> >>>> DataObject executeSQL(String abitrarySQL);
>> >>> > >> >>>> }
>> >>> > >> >>>>
>> >>> > >> >>>> The service would be initialized with an optional
>> RDB DAS
>> >>> > >> config file
>> >>> > >> >>>> that defines connection properties, a set of commands,
>> >>> etc. So,
>> >>> > >> >>>> different services implementing the same interface
>> could be
>> >>> > >> >>>> initialized
>> >>> > >> >>>> from separate config files.
>> >>> > >> >>>>
>> >>> > >> >>>> Eventually, we might want to build services like this:
>> >>> > >> >>>>
>> >>> > >> >>>> public interface Customers_RDBDASService
>> >>> > >> >>>> void applyChanges(DataObject graphRoot);
>> >>> > >> >>>> DataObject getAllCustomersWithLastName (String
>> >>> > lastName);
>> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID (int
>> >>> > customerId);
>> >>> > >> >>>> }
>> >>> > >> >>>>
>> >>> > >> >>>> But, for this to be very useful would probably require
>> >>> some code
>> >>> > >> >>>> generation tooling.
>> >>> > >> >>>>
>> >>> > >> >>>> Thoughts?
>> >>> > >> >>>>
>> >>> > >> >>>> --Kevin
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >> >>>> Luciano Resende wrote:
>> >>> > >> >>>>
>> >>> > >> >>>> > I'm starting to look in ways we could have a
>> declarative
>> >>> > DAS and
>> >>> > >> >>>> will be
>> >>> > >> >>>> > posting my progress into the list / wiki soon...
>> >>> > >> >>>> >
>> >>> > >> >>>> > - Luciano
>> >>> > >> >>>> >
>> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
>> 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 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.
>> >>> > >> >>>> >>
>> >>> > >> >>>> >> "Thanks for volunteering" :-)
>> >>> > >> >>>> >> If someone wants to contribute these, I think we
>> >>> > should welcome
>> >>> > >> it
>> >>> > >> >>>> >> like we would any other contribution.
>> >>> > >> >>>> >>
>> >>> > >> >>>> >> >> 3) to access data through an application
>> service with
>> >>> > >> >>>> declarative
>> >>> > >> >>>> >> >> implementation by DAS
>> >>> > >> >>>> >> > Yes, that's the value I see in DAS
>> >>> > >> >>>> >>
>> >>> > >> >>>> >> I think this is already on the DAS folks radar.
>> >>> > >> >>>> >> --
>> >>> > >> >>>> >> Jeremy
>> >>> > >> >>>> >>
>> >>> > >> >>>> >>
>> >>> > >> >>>>
>> >>> > >>
>> >>>
>> --------------------------------------------------------------------
>> >>> > >> -
>> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
>> >>> unsubscribe@ws.apache.org
>> >>> > >> >>>> >> For additional commands, e-mail:
>> >>> > tuscany-dev-help@ws.apache.org
>> >>> > >> >>>> >>
>> >>> > >> >>>> >>
>> >>> > >> >>>> >
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >>
>> >>>
>> --------------------------------------------------------------------
>> >>> > >> -
>> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
>> >>> unsubscribe@ws.apache.org
>> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
>> >>> help@ws.apache.org
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >> >>>
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >>
>> >>> >
>> >>>
>> ---------------------------------------------------------------------
>> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> >>> > >> >> For additional commands, e-mail: tuscany-dev-
>> >>> help@ws.apache.org
>> >>> > >> >>
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> >
>> >>>
>> ---------------------------------------------------------------------
>> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> >>> > >> > For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>>
>> ---------------------------------------------------------------------
>> >>> > >> To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> >>> > >> For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >>> > >>
>> >>> > >>
>> >>> > >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>> >
>> >>> >
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>>
>> >>>
>> >>>
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I would also like to understand this a little better ... here I am thinking
aloud and hope the others will help in getting my persceptions right...
I guess firstly it is a question of how or where we want to position 'DAS
Integration' in SCA. Is is something we want to integrate as the
Application Layer, which I understand is what Amita is trying presently and
which Jim refers to as component implementation. In this option we get to
do some sort of a service wrapper to DAS and then it becomes a demonstration
of two Tuscany subprojects integrating at application level.
Or do we want to position DAS at the infrastructure layer as another
extension type (either container or binding). I guess this is where Ant
started this - proposing a JDBC container / binding for component
implementation in StoredProcedures. If this is the path we should take
then we probably have to think beyond DAS - to something more general - of
which DAS is just a special case. I suppose this is what Jim has also
suggested in trying to explore other persistence mechanisms.
I too feel that this is something that must be done as an extension type -
but yet to get my hands on the general scheme of things that DAS can slip
into. Infact the other thread where Jeremy has taken forward a proposal to
the specs group on resources tempts me to think that there is going to be
something in that which we can leverage from.
I hope to get a better understanding this as we go along in this thread :)
Thanks
- Venkat
On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Jim Marino wrote:
>
> > When I first read the thread on this, I thought the DAS service would
> > be a component extension type (e.g. analogous to a
> > implementation.java or implementation.ejb) and not a component
> > implementation type, which would allow for dynamic and eventually
> > declarative configuration styles.
>
> I have not very familiar with the terminology so I am not sure what a
> "component extension type" is. But, I do think we eventually want
> "implementation.rdbdas". Wouldn't this be a new implementation type?
>
> It looks like Amita chose to start with a POJO. I notice the use of "
> implementation.java".
>
> > Either way, though, I am curious as to why
> >
> > public DAS configureService(String configFile);
> >
> > exists as part of the service definition? If the DAS service was a
> > component extension type, it could be handled as part of the
> > application bootstrap. If the DAS service was a component
> > implementation type, the configuration file URI could be passed in as
> > a property and then processed in an initializer method decorated by
> > the SCA @Init annotation. In the latter case, if the implementation
> > of DASService thread-safe (hopefully it is since configuration would
> > seem to be a heavyweight operation), then I would make the component
> > module scoped to avoid initialization overhead on every resolution.
>
> >
> > In both approaches (extension vs. implementation type), having
> > configuration exposed to the application doesn't quite feel right,
> > since that is what DI tries to externalize.
>
> I agree. The configuration should be part of the initialization and
> should use SCA patterns to do this. I think that Amita meant to use
> eventually use a component property for the DAS config info but started
> with a method.
>
> >
> > Also, I was thinking that in having this a component extension type,
> > the service interfaces returned from a resolution could include the
> > dynamic one described below or static ones people have mentioned. I
> > guess it is best to start with the easier-to-implement part first and
> > support the dynamic interface.
> >
> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> > understand what DAS provides in relation to other persistence
> > technologies. Outside of the Java world, Microsoft is promoting LINQ
> > which is really interesting, and it would be informative to compare
> > the goals of DAS with that approach (there are obvious differences
> > such as having the query language a strongly-typed part of the
> > programming language, e.g. C#, and LINQ's use of closures).
> >
> > In contrasting DAS to O-R technologies, I see the primary use cases
> > for the former being a quick way to issue a query that may be
> > executed against *heterogeneous* data stores and have that data flow
> > remotely or to a client that is not necessarily Java-based. One key
> > for me is heterogeneous data since JDBC 4 lets me do this (Hibernate
> > and JPA are about as easy):
> >
> IMO the primary use case for DAS is an application that is SDO-centric
> and is taking advantage of its disconnected capabilities. The RDB DAS
> is built to work with SDO and uses the change summary to drive changes
> made to a disconnected data graph back to some store. This is not to
> say that a relational DAS could not be built on top of JPA, in fact,
> this might be a very useful thing to do. The implementation we
> currently have provides a very straightforward implicit mapping from
> DataObjects to Tables. If more capable mapping is needed then it makes
> sense to use the JPA-defined technology and artifacts. A modified
> Entity manager might be needed to take advantage of SDO's change summary.
>
> >
> > public interface CustomerDao extends BaseQuery {
> > @Select("select * from customers where city = ?1")
> > DataSet<Customer> findCustomersFrom(String city);
> > }
> >
> > CustomerDao cd = QueryObjectFactory.createQueryObject
> > (CustomerDao.class, datasource);
> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >
> >
> > The other key is remote data and change lists. I think there are
> > (literally) about a thousand ways that already exist to handle the
> > "local" data case. For change lists, interop with ADO.NET's change
> > summary facilities would be interesting.
>
> I agree. Also, it looks like Xcalia may have a similar thought:
> http://www.xcalia.com/news/PR_2006-10-23.jsp
>
> >
> > I'm playing devil's advocate a bit with DAS, but I think it is
> > important we have a clear statement as to when it is appropriate and
> > not appropriate to use. One place to start would be to compare it to
> > JDBC 4 and JPA.
>
> We can get started with JPA:
>
> * JPA is java-specific, container-based, built around a connected
> data model and offers a complete O/R mapping for POJOs
>
> * The RDB DAS is a java implementation of a language - neutral
> concept (hopefully specified some day) that is containerless,
> assumes a disconnected data model and provides a simple, implicit
> mapping for SDO DataObjects (Dynamic or Static) to relational
> tables.
>
> Anything else?
>
> >
> > Jim
> >
> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >
> >> Hi Amita
> >>
> >> I think we were both going on the same way, with the DAS Service
> >> sample,
> >> altough i had the interface more like this, to be more flexible :
> >>
> >> public interface DASService {
> >>
> >> public DAS configureService(String configFile);
> >
> >
> >> public DataObject executeCommand(String commandName);
> >> public DataObject execute(String newCommand);
> >> public void applyChanges(DataObject graphRoot);
> >> }
> >>
> >>
> >> As for having it as a sample, maybe we could defined the DASService
> >> as one
> >> sample itself, and have a second version of companyWeb that would
> >> consume
> >> the service, something like :
> >>
> >> das\samples\companyWeb
> >> das\samples\dasService
> >> das\samples.companyWeb.service
> >>
> >> or, more like BigBank
> >>
> >> das\samples\companyweb.Service\dasService
> >> das\samples\companyweb.Service\webClient
> >>
> >> Or even in sampleApps...
> >>
> >> Toughts ?
> >>
> >>
> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
> >>
> >>>
> >>> Hi ,
> >>> I am also following up another thread
> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg09944.html
> >>> on the
> >>> similar issue (JDBC stored procedure container
> >>> using DAS)
> >>> Besides the fact that I am actively working on the container work,
> >>> I also
> >>> have tried to
> >>> develop a sample based on the below discussion, following dynamic
> >>> approach.
> >>>
> >>> I am attaching the same here. Please take a look and give your
> >>> suggestions.
> >>> In this, StoredProcedureService implementation has setConfigInfo (DAS
> >>> Config) and
> >>> execute(Any SQL). This can be made more complete with executeSQL(),
> >>> applyChanges()
> >>> etc.
> >>>
> >>> Can this be added to the existing set of samples?
> >>>
> >>> Regards,
> >>> Amita
> >>>
> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >>> >
> >>> > Luciano Resende wrote:
> >>> >
> >>> > > Kevin, from what I understood from your suggestion, it was
> >>> looking to
> >>> > me
> >>> > > more like exposing DAS as a service :
> >>> > >
> >>> > >>> public interface RDBDASService
> >>> > >>> DataObject execute(String commandName);
> >>> > >>> DataObject executeSQL(String abitrarySQL);
> >>> > >>> void applyChanges(DataObject graphRoot);
> >>> > >>> }
> >>> > >>
> >>> > Yes, I am talking about exposing a DAS Service configured with a
> >>> > specific set of capabilities/commands defined in the DAS config
> >>> file.
> >>> > So, if the implementation of the service interface above was
> >>> configured
> >>> > to work with Customers they would use the service like this:
> >>> >
> >>> > List customers = myRDBDASService.execute("getAllCustomers");
> >>> > String name = customers.get(0).getString("name");
> >>> >
> >>> > This is not much different than the static interface you proposed,
> >>> > right?
> >>> >
> >>> > > And then, when a service developer defines the AccountService,
> >>> he will
> >>> >
> >>> > > have
> >>> > > to know about yet another service, about how DAS works, how it is
> >>> > > configured, etc, etc... is that right ?
> >>> > >
> >>> > The abilities of the service are defined by the DAS config file.
> >>> So,
> >>> > the person or tool that provides the config file must understand
> >>> how the
> >>> >
> >>> > RDB DAS APIs work. There is no getting around this.
> >>> >
> >>> > > My proposal was going more towards allowing the service
> >>> developer to
> >>> > > focus
> >>> > > on defining the service, and let the "declarative das" to
> >>> handle the
> >>> > > persistent layer....
> >>> > >
> >>> > The DAS config file is the declaration of an instance of the
> >>> DAS. That
> >>> > instance can be exposed as a dynamic or typed service/ interface.
> >>> That
> >>> > seems to be the main discussion we are having. Although, I may be
> >>> > missing something.
> >>> >
> >>> > > Also, by defining some conventions over configuration
> and/or using
> >>> > > annotations (e.g @Procedure to force mapping to a stored
> >>> procedure),
> >>> > the
> >>> > > service developer could really define a service that interacts
> >>> with a
> >>> > > RDB,
> >>> > > without having to code the service persistence layer.
> >>> > >
> >>> > There is a lot of potential for the use of annotations.
> >>> >
> >>> > >
> >>> > > - Luciano
> >>> > >
> >>> > >
> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
> >>> > >
> >>> > >>
> >>> > >> The real difference between the two approaches is that one is
> >>> "Typed"
> >>> > or
> >>> > >> static and the other is dynamic. I think both are needed
> but was
> >>> > >> suggesting that we start with dynamic since it is the most
> >>> flexible
> >>> > and
> >>> > >> seems to be a reasonable stepping stone towards a static
> >>> capability.
> >>> > >>
> >>> > >> With either, the user does not need to know about traditional
> >>> > >> persistence frameworks. With the dynamic approach, however,
> >>> the user
> >>> > >> does need to know about the dynamic SDO API.
> >>> > >>
> >>> > >> So, with the static interface the user might write:
> >>> > >>
> >>> > >> List customers = accountService.getAllCustomers();
> >>> > >> String name = ((Customer)customers.get(0)).getName();
> >>> > >>
> >>> > >> The equivalent dynamic API might be:
> >>> > >>
> >>> > >> List customers = dasService.execute("getAllCustomers");
> >>> > >> String name = ((DataObject)customers.get(0)).getString
> >>> ("name");
> >>> > >>
> >>> > >> The first is probably a little easier for the application
> >>> developer
> >>> > but
> >>> > >> the second is much easier for the service developer. IMO, the
> >>> dynamic
> >>> > >> case is the best place to start and, again, we definitely will
> >>> want
> >>> > >> support for both.
> >>> > >>
> >>> > >> Thanks.
> >>> > >> --
> >>> > >> Kevin
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >> Jeremy Boynes wrote:
> >>> > >>
> >>> > >> > I think this would be useful but it seems more like a
> >>> traditional
> >>> > >> > persistence API than what Luciano was suggesting. With this
> >>> one a
> >>> > >> > user needs to know about DataObject's, commands, SQL strings
> >>> etc.
> >>> > >> > just like they would if they were using raw JDBC or JPA.
> >>> > >> >
> >>> > >> > On the other hand, Luciano's proposal seemed more about
> >>> expressing
> >>> > >> > high-level CRUD operations as operations on a service
> >>> interface:
> >>> > >> >
> >>> > >> >>> public interface AccountService {
> >>> > >> >>>
> >>> > >> >>> public List getAllCustomers();
> >>> > >> >>> public Object getCustomerAccount(String accountNumber);
> >>> > >> >>> }
> >>> > >> >>
> >>> > >> >
> >>> > >> > which is all application level concepts rather
> than persistence
> >>> > level
> >>> > >> > concepts. I'd actually go a little further and put that
> >>> right into
> >>> > >> > the service contract:
> >>> > >> >
> >>> > >> > public interface AccountService {
> >>> > >> > List<Customer> getAllCustomers();
> >>> > >> > Account getCustomerAccount(String accountNumber);
> >>> > >> > }
> >>> > >> >
> >>> > >> > In a ideal world, if the user was able to accept standardized
> >>> > >> > mappings (a la Rails et al) then no further configuration
> >>> would be
> >>> > >> > needed except to add this to the logical assembly:
> >>> > >> >
> >>> > >> > <component name="AccountStore">
> >>> > >> > <implementation.das resource="MySQLDatabase"/>
> >>> > >> > </component>
> >>> > >> >
> >>> > >> > With SCA's ability to translate service contracts, this
> >>> should be
> >>> > >> > callable from and deployable to any SCA runtime regardless of
> >>> > whether
> >>> > >> > it was being accessed locally, by WS-*, by IIOP or running on
> a
> >>> > Java,
> >>> > >> > C++ or PHP platform.
> >>> > >> >
> >>> > >> > The important thing here is that the client is isolated from
> >>> how
> >>> > the
> >>> > >> > DAS component is provided. We could have multiple declarative
> >>> > >> > implementations, say one based on RDB-DAS and one that did
> >>> stuff
> >>> > with
> >>> > >> > XML databases like Xindice; alternatively, /without altering
> >>> the
> >>> > >> > client at all/ they could switch to a custom coded version
> >>> written
> >>> > in
> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
> >>> > >> >
> >>> > >> > --
> >>> > >> > Jeremy
> >>> > >> >
> >>> > >> >
> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >>> > >> >
> >>> > >> >> 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 code specific to a new
> >>> > >> >> service. Instead, the service will be "instantiated" based
> >>> on the
> >>> >
> >>> > >> >> provided DAS config file. The service interface might look
> >>> like
> >>> > >> this:
> >>> > >> >>
> >>> > >> >> public interface RDBDASService
> >>> > >> >> DataObject execute(String commandName);
> >>> > >> >> DataObject executeSQL(String abitrarySQL);
> >>> > >> >> void applyChanges(DataObject graphRoot);
> >>> > >> >> }
> >>> > >> >>
> >>> > >> >> So, depending on the config file used to instantiate the
> >>> service,
> >>> > >> >> this interface could be used to return Customers/Accounts or
> >>> > >> >> Toasters. In fact, a lot could be achieved with no
> >>> > configuration at
> >>> > >> >> all by restricting use to: DataObject executeSQL(String
> >>> > >> abitrarySQL);
> >>> > >> >>
> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
> >>> mod_mbox/ws-
> >>> > >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net %3e
> >>> > >> >>
> >>> > >> >> Once this was working it should be straightforward to build
> >>> more
> >>> > >> >> strongly typed services and possible put together some
> >>> generation
> >>> > >> >> tooling. We could also start looking at support for a more
> >>> > RESTFul
> >>> > >> >> interface.
> >>> > >> >> --
> >>> > >> >> Kevin
> >>> > >> >>
> >>> > >> >>
> >>> > >> >>
> >>> > >> >>
> >>> > >> >> Luciano Resende wrote:
> >>> > >> >>
> >>> > >> >>> Recently, people have been starting to talk about better DAS
> >>> > >> >>> integration
> >>> > >> >>> with DAS, and below are some threads on the subject :
> >>> > >> >>>
> >>> > >> >>>
> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08833.html
> >>> > >> >>>
> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08923.html
> >>> > >> >>>
> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >>> msg09715.html
> >>> >
> >>> > >> >>>
> >>> > >> >>> I'm new on the SCA side, so please help me make sure
> what I'm
> >>> > >> >>> saying is not
> >>> > >> >>> yet available on SCA today.
> >>> > >> >>>
> >>> > >> >>> Today, defining a service to work with a relational
> >>> database, you
> >>> > >> >>> will need
> >>> > >> >>> to code the persistence side of the service where CRUD
> >>> operations
> >>> > >> >>> to the
> >>> > >> >>> database will be done.
> >>> > >> >>> I was thinking on a simpler, easier way, where coding the
> >>> CRUD
> >>> > >> >>> operations on
> >>> > >> >>> the persistence layer would be avoided as much as possible.
> >>> > >> >>> The idea would be to have a more "declarative DAS" when
> >>> defining
> >>> > SCA
> >>> > >> >>> Services, so you would either use some Annotations or SCDL
> to
> >>> > >> have the
> >>> > >> >>> "declarative DAS" configuration inside it.
> >>> > >> >>>
> >>> > >> >>> I was thinking on something like....
> >>> > >> >>>
> >>> > >> >>> SCDL Definition would look something like this :
> >>> > >> >>>
> >>> > >> >>> <component name="AccountDataService">
> >>> > >> >>> <interface.java
> >>> > >> >>> class="bigbank.account.services.account.AccountService"/>
> >>> > >> >>> <implementation.das="dasConfig.properties"
> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >>> > >> >>> </component>
> >>> > >> >>>
> >>> > >> >>> The AccountService Interface would look like this (missing
> >>> any
> >>> > SCA
> >>> > >> >>> annotations):
> >>> > >> >>>
> >>> > >> >>> public interface AccountService {
> >>> > >> >>>
> >>> > >> >>> public List getAllCustomers();
> >>> > >> >>> public Object getCustomerAccount(String accountNumber);
> >>> > >> >>> }
> >>> > >> >>>
> >>> > >> >>> The DAS config would look like this, and would have the
> >>> > definition
> >>> > >> >>> for the
> >>> > >> >>> "all companies" command.
> >>> > >> >>>
> >>> > >> >>> <Config ...>
> >>> > >> >>> ...
> >>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/bigbank"/>
> >>> > >> >>>
> >>> > >> >>> <Command name="getAllCustomers" SQL="select * from
> >>> CUSTOMERS"
> >>> > >> >>> kind="Select"/>
> >>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
> >>> accountNumber,
> >>> > >> >>> accountType, balance FROM accounts where accountNumber = ?"
> >>> > >> >>> kind="Select" />
> >>> > >> >>> ...
> >>> > >> >>> </Config>
> >>> > >> >>>
> >>> > >> >>>
> >>> > >> >>> Mapping between interface methods and DAS Commands
> >>> > >> >>> - If a DAS config file is provided, based on the
> >>> > SCDL definition,
> >>> > >> we
> >>> > >> >>> would look for "DAS command" based on the name of the getter
> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers command)
> >>> > >> >>> - Otherwise, we would try to do a map directly to a
> >>> > >> stored procedure
> >>> > >> >>> - We could also have a way to force the mapping by using
> >>> > >> annotation
> >>> > >> >>> (e.g@Procedure on the method level)
> >>> > >> >>>
> >>> > >> >>> Mapping between method parameter and command parameter
> >>> > >> >>> - We would need to define a method for mapping the method
> >>> > >> >>> parameters to
> >>> > >> >>> the query paramters either based on position ( e.g first
> >>> method
> >>> > >> >>> parameter
> >>> > >> >>> maps to the first command paramter), or we would do some
> >>> > mapping by
> >>> > >> >>> name
> >>> > >> >>> (currently not available in Tuscany DAS)
> >>> > >> >>>
> >>> > >> >>> Note:
> >>> > >> >>> - A SCDL connection information would override the DAS
> >>> Config
> >>> > file
> >>> > >> >>> connection information.
> >>> > >> >>>
> >>> > >> >>>
> >>> > >> >>> Benefits
> >>> > >> >>> - It's All about simplicity and easy of use
> >>> > >> >>> - This would allow a user to define a service without
> >>> having to
> >>> >
> >>> > >> >>> explicitly having to code any Data Access related code.
> >>> > >> >>>
> >>> > >> >>>
> >>> > >> >>> Implementation approaches
> >>> > >> >>> - Utilizing DAS : This approach would start from the
> >>> current
> >>> > >> >>> Tuscany DAS
> >>> > >> >>> implementation, where functionality would be already
> >>> > available, but
> >>> > >> >>> the
> >>> > >> >>> service implementation would be tied to SDO and RDB as this
> >>> > is what
> >>> > >> >>> DAS
> >>> > >> >>> supports today.
> >>> > >> >>>
> >>> > >> >>> - Start simple and grow : We could start simple, by
> >>> having a
> >>> > >> simple
> >>> > >> >>> implementation based on JDBC and would return some simple
> >>> > >> >>> collection as a
> >>> > >> >>> return type (e.g List or a even a Recordset), this could
> >>> give us
> >>> > a
> >>> > >> >>> quick
> >>> > >> >>> start to flush implementation details and get a proven
> >>> design,
> >>> > and
> >>> > >> >>> this
> >>> > >> >>> could get evolved to use a DAS that would support multiple
> >>> > backends
> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as non- SDO
> >>> types
> >>> > >> as a
> >>> > >> >>> command
> >>> > >> >>> result.
> >>> > >> >>>
> >>> > >> >>>
> >>> > >> >>> Toughts ?
> >>> > >> >>>
> >>> > >> >>> - Luciano
> >>> > >> >>>
> >>> > >> >>>
> >>> > >> >>>
> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
> >>> > >> >>>
> >>> > >> >>>>
> >>> > >> >>>> 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. Another thing we want to eventually
> >>> explore is
> >>> > >> >>>> exposing
> >>> > >> >>>> a DAS as REST-oriented services. As we have seen from the
> >>> > parent
> >>> > >> >>>> thread
> >>> > >> >>>> there are almost too many possible approaches.
> >>> > >> >>>>
> >>> > >> >>>> My first thought is to model the DAS as a service and
> >>> create a
> >>> > new
> >>> > >> >>>> implementation kind (implementation.rdbdas). The main
> >>> reason
> >>> > has
> >>> > >> >>>> to do
> >>> > >> >>>> with the potential declarative aspect of DAS that
> >>> > Jeremy mentioned
> >>> > >> >>>> which
> >>> > >> >>>> is all about creating data access services
> >>> declaratively. A new
> >>> > >> >>>> component type and a service that we build by hand would be
> >>> > a good
> >>> > >> >>>> step
> >>> > >> >>>> in this direction.
> >>> > >> >>>>
> >>> > >> >>>> We might want to expose a DAS service with an
> interface like
> >>> > this:
> >>> > >> >>>>
> >>> > >> >>>> public interface RDBDASService
> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >>> > >> >>>> DataObject execute(String commandName);
> >>> > >> >>>> DataObject executeSQL(String abitrarySQL);
> >>> > >> >>>> }
> >>> > >> >>>>
> >>> > >> >>>> The service would be initialized with an optional RDB DAS
> >>> > >> config file
> >>> > >> >>>> that defines connection properties, a set of commands,
> >>> etc. So,
> >>> > >> >>>> different services implementing the same interface could be
> >>> > >> >>>> initialized
> >>> > >> >>>> from separate config files.
> >>> > >> >>>>
> >>> > >> >>>> Eventually, we might want to build services like this:
> >>> > >> >>>>
> >>> > >> >>>> public interface Customers_RDBDASService
> >>> > >> >>>> void applyChanges(DataObject graphRoot);
> >>> > >> >>>> DataObject getAllCustomersWithLastName (String
> >>> > lastName);
> >>> > >> >>>> DataObject getAll CustomersAndOrdersForID (int
> >>> > customerId);
> >>> > >> >>>> }
> >>> > >> >>>>
> >>> > >> >>>> But, for this to be very useful would probably require
> >>> some code
> >>> > >> >>>> generation tooling.
> >>> > >> >>>>
> >>> > >> >>>> Thoughts?
> >>> > >> >>>>
> >>> > >> >>>> --Kevin
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >> >>>> Luciano Resende wrote:
> >>> > >> >>>>
> >>> > >> >>>> > I'm starting to look in ways we could have a declarative
> >>> > DAS and
> >>> > >> >>>> will be
> >>> > >> >>>> > posting my progress into the list / wiki soon...
> >>> > >> >>>> >
> >>> > >> >>>> > - Luciano
> >>> > >> >>>> >
> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org > 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 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.
> >>> > >> >>>> >>
> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >>> > >> >>>> >> If someone wants to contribute these, I think we
> >>> > should welcome
> >>> > >> it
> >>> > >> >>>> >> like we would any other contribution.
> >>> > >> >>>> >>
> >>> > >> >>>> >> >> 3) to access data through an application service with
> >>> > >> >>>> declarative
> >>> > >> >>>> >> >> implementation by DAS
> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >>> > >> >>>> >>
> >>> > >> >>>> >> I think this is already on the DAS folks radar.
> >>> > >> >>>> >> --
> >>> > >> >>>> >> Jeremy
> >>> > >> >>>> >>
> >>> > >> >>>> >>
> >>> > >> >>>>
> >>> > >>
> >>> --------------------------------------------------------------------
> >>> > >> -
> >>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
> >>> unsubscribe@ws.apache.org
> >>> > >> >>>> >> For additional commands, e-mail:
> >>> > tuscany-dev-help@ws.apache.org
> >>> > >> >>>> >>
> >>> > >> >>>> >>
> >>> > >> >>>> >
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >>
> >>> --------------------------------------------------------------------
> >>> > >> -
> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
> >>> unsubscribe@ws.apache.org
> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
> >>> help@ws.apache.org
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >> >>>
> >>> > >> >>
> >>> > >> >>
> >>> > >> >>
> >>> > >> >>
> >>> >
> >>> ---------------------------------------------------------------------
> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> > >> >> For additional commands, e-mail: tuscany-dev-
> >>> help@ws.apache.org
> >>> > >> >>
> >>> > >> >
> >>> > >> >
> >>> > >> >
> >>> >
> >>> ---------------------------------------------------------------------
> >>> > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> > >> > For additional commands, e-mail: tuscany-dev-
> help@ws.apache.org
> >>> > >> >
> >>> > >> >
> >>> > >> >
> >>> > >> >
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >>
> >>> ---------------------------------------------------------------------
> >>> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> > >>
> >>> > >>
> >>> > >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Kevin Williams <ke...@qwest.net>.
Jim Marino wrote:
>
> On Oct 24, 2006, at 2:11 PM, Kevin Williams wrote:
>
>> Jim Marino wrote:
>>
>>> When I first read the thread on this, I thought the DAS service
>>> would be a component extension type (e.g. analogous to a
>>> implementation.java or implementation.ejb) and not a component
>>> implementation type, which would allow for dynamic and eventually
>>> declarative configuration styles.
>>
>>
>> I have not very familiar with the terminology so I am not sure what
>> a "component extension type" is. But, I do think we eventually
>> want "implementation.rdbdas". Wouldn't this be a new
>> implementation type?
>>
>> It looks like Amita chose to start with a POJO. I notice the use of
>> " implementation.java".
>>
> Yes that's it, something like implementation.das or
> implementation.rdbdas. Maybe there could be just be one
> implementation.das which could be configured to work with a number of
> different mediators for different types of data store?
>
>>
>>>
>>> I'm playing devil's advocate a bit with DAS, but I think it is
>>> important we have a clear statement as to when it is appropriate
>>> and not appropriate to use. One place to start would be to compare
>>> it to JDBC 4 and JPA.
>>
>>
>> We can get started with JPA:
>>
>> * JPA is java-specific, container-based, built around a connected
>> data model and offers a complete O/R mapping for POJOs
>>
>> * The RDB DAS is a java implementation of a language - neutral
>> concept (hopefully specified some day) that is containerless,
>> assumes a disconnected data model and provides a simple, implicit
>> mapping for SDO DataObjects (Dynamic or Static) to relational
>> tables.
>>
>> Anything else?
>
> Hmm JPA is also "containerless" in that it will work in a J2SE
> environment (the JPA spec was separated out to accommodate this), has
> a disconnected model (e.g. the "merge" operation has these semantics)
> , and contains (somewhat) implicit mapping capabilities for POJOs
> (when greenfield databases are allowed).
>
Right! "Container" was a bad choice. I should have said: "JPA requires
that POJOs register with an Enity Manager thingee to monitor their
lifecycle". Also, IMO, the disconnected model seems to be an
afterthought in JPA and its implementation is likely to be inefficient
(I am thinking it might require a re-read of tables followed by a
compare to flush changes?). But, that behavior could probably be
modified to leverage the SDO change summary.
> I thought the difference would have been something to the effect of:
>
> - DAS provides a declarative veneer over heterogeneous mediators,
> such as JDBC, JPA, Hibernate, and XML store, etc.
I am having trouble with the term "declarative". I think that you mean
"exposed as a typed interface" but I am not sure.
> - DAS is used for "remoting" data to clients, some of which may not
> be Java-based.
>
> So, I would expect Java component implementations to make heavy use
> of "locally disconnected" persistence APIs such as Hibernate and JPA
> when manipulating application data that does not flow "as-is" (i.e.
> "shape not modified") to remote clients. DAS would be used when
> someone wants a simple declarative way to get at data (and
> performance is not the primary concern) or they need to send data to
> a remote client that is not necessarily Java.
Sounds good!
> An interesting case you mentioned would be to allow JPA, Hibernate,
> or JDBC 4 to function as the store mediator. I think this would be
> valuable in that it avoids having to re-specify mappings (most
> applications I would suspect have a need for "local" data) as well as
> allows for integration into the persistence infrastructure for things
> such as cache invalidation. In this case, DAS would be used to send
> data pulled from Hibernate or JPA down to a client such as a web
> browser, Swing app or a .NET app. Trying to do that today with those
> technologies is either not possible or not trivial.
>
> Right now I'm obviously tied up in SCA, otherwise I probably would
> have offered to create a prototype of this. As background, the reason
> why I am bringing this up is I am getting asked why we are
> introducing another persistence API.
I think the DAS is really a consistent way to retrieve data from some
store in terms of Data Objects; maybe its more of a pattern. I don't
really think of it as a new persistence API. But, I also get similar
comments.
> I'm getting this from Java people as well as a colleague heavily
> involved in the .NET world. I responded to him with the above
> description but I still feel it is not as simple a story as it should
> be (i.e. it doesn't fit in a sound bite). What do you think?
How about: "The DAS is a big pattern (perhaps specified some day) for
accessing data in terms of SDO DataObjects"
Or ... "The DAS and SDO enable your SOA Data Access requirements by
virtualizing the entire data experience!!"
Just kidding about the second one :-)
>
> Jim
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 24, 2006, at 2:11 PM, Kevin Williams wrote:
> Jim Marino wrote:
>
>> When I first read the thread on this, I thought the DAS service
>> would be a component extension type (e.g. analogous to a
>> implementation.java or implementation.ejb) and not a component
>> implementation type, which would allow for dynamic and eventually
>> declarative configuration styles.
>
> I have not very familiar with the terminology so I am not sure what
> a "component extension type" is. But, I do think we eventually
> want "implementation.rdbdas". Wouldn't this be a new
> implementation type?
>
> It looks like Amita chose to start with a POJO. I notice the use
> of " implementation.java".
>
Yes that's it, something like implementation.das or
implementation.rdbdas. Maybe there could be just be one
implementation.das which could be configured to work with a number of
different mediators for different types of data store?
>
>>
>> I'm playing devil's advocate a bit with DAS, but I think it is
>> important we have a clear statement as to when it is appropriate
>> and not appropriate to use. One place to start would be to
>> compare it to JDBC 4 and JPA.
>
> We can get started with JPA:
>
> * JPA is java-specific, container-based, built around a connected
> data model and offers a complete O/R mapping for POJOs
>
> * The RDB DAS is a java implementation of a language - neutral
> concept (hopefully specified some day) that is containerless,
> assumes a disconnected data model and provides a simple, implicit
> mapping for SDO DataObjects (Dynamic or Static) to relational
> tables.
>
> Anything else?
Hmm JPA is also "containerless" in that it will work in a J2SE
environment (the JPA spec was separated out to accommodate this), has
a disconnected model (e.g. the "merge" operation has these
semantics) , and contains (somewhat) implicit mapping capabilities
for POJOs (when greenfield databases are allowed).
I thought the difference would have been something to the effect of:
- DAS provides a declarative veneer over heterogeneous mediators,
such as JDBC, JPA, Hibernate, and XML store, etc.
- DAS is used for "remoting" data to clients, some of which may not
be Java-based.
So, I would expect Java component implementations to make heavy use
of "locally disconnected" persistence APIs such as Hibernate and JPA
when manipulating application data that does not flow "as-is" (i.e.
"shape not modified") to remote clients. DAS would be used when
someone wants a simple declarative way to get at data (and
performance is not the primary concern) or they need to send data to
a remote client that is not necessarily Java. An interesting case you
mentioned would be to allow JPA, Hibernate, or JDBC 4 to function as
the store mediator. I think this would be valuable in that it avoids
having to re-specify mappings (most applications I would suspect have
a need for "local" data) as well as allows for integration into the
persistence infrastructure for things such as cache invalidation. In
this case, DAS would be used to send data pulled from Hibernate or
JPA down to a client such as a web browser, Swing app or a .NET app.
Trying to do that today with those technologies is either not
possible or not trivial.
Right now I'm obviously tied up in SCA, otherwise I probably would
have offered to create a prototype of this. As background, the reason
why I am bringing this up is I am getting asked why we are
introducing another persistence API. I'm getting this from Java
people as well as a colleague heavily involved in the .NET world. I
responded to him with the above description but I still feel it is
not as simple a story as it should be (i.e. it doesn't fit in a sound
bite). What do you think?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Kevin Williams <ke...@qwest.net>.
Jim Marino wrote:
> When I first read the thread on this, I thought the DAS service would
> be a component extension type (e.g. analogous to a
> implementation.java or implementation.ejb) and not a component
> implementation type, which would allow for dynamic and eventually
> declarative configuration styles.
I have not very familiar with the terminology so I am not sure what a
"component extension type" is. But, I do think we eventually want
"implementation.rdbdas". Wouldn't this be a new implementation type?
It looks like Amita chose to start with a POJO. I notice the use of "
implementation.java".
> Either way, though, I am curious as to why
>
> public DAS configureService(String configFile);
>
> exists as part of the service definition? If the DAS service was a
> component extension type, it could be handled as part of the
> application bootstrap. If the DAS service was a component
> implementation type, the configuration file URI could be passed in as
> a property and then processed in an initializer method decorated by
> the SCA @Init annotation. In the latter case, if the implementation
> of DASService thread-safe (hopefully it is since configuration would
> seem to be a heavyweight operation), then I would make the component
> module scoped to avoid initialization overhead on every resolution.
>
> In both approaches (extension vs. implementation type), having
> configuration exposed to the application doesn't quite feel right,
> since that is what DI tries to externalize.
I agree. The configuration should be part of the initialization and
should use SCA patterns to do this. I think that Amita meant to use
eventually use a component property for the DAS config info but started
with a method.
>
> Also, I was thinking that in having this a component extension type,
> the service interfaces returned from a resolution could include the
> dynamic one described below or static ones people have mentioned. I
> guess it is best to start with the easier-to-implement part first and
> support the dynamic interface.
>
> FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> understand what DAS provides in relation to other persistence
> technologies. Outside of the Java world, Microsoft is promoting LINQ
> which is really interesting, and it would be informative to compare
> the goals of DAS with that approach (there are obvious differences
> such as having the query language a strongly-typed part of the
> programming language, e.g. C#, and LINQ's use of closures).
>
> In contrasting DAS to O-R technologies, I see the primary use cases
> for the former being a quick way to issue a query that may be
> executed against *heterogeneous* data stores and have that data flow
> remotely or to a client that is not necessarily Java-based. One key
> for me is heterogeneous data since JDBC 4 lets me do this (Hibernate
> and JPA are about as easy):
>
IMO the primary use case for DAS is an application that is SDO-centric
and is taking advantage of its disconnected capabilities. The RDB DAS
is built to work with SDO and uses the change summary to drive changes
made to a disconnected data graph back to some store. This is not to
say that a relational DAS could not be built on top of JPA, in fact,
this might be a very useful thing to do. The implementation we
currently have provides a very straightforward implicit mapping from
DataObjects to Tables. If more capable mapping is needed then it makes
sense to use the JPA-defined technology and artifacts. A modified
Entity manager might be needed to take advantage of SDO's change summary.
>
> public interface CustomerDao extends BaseQuery {
> @Select("select * from customers where city = ?1")
> DataSet<Customer> findCustomersFrom(String city);
> }
>
> CustomerDao cd = QueryObjectFactory.createQueryObject
> (CustomerDao.class, datasource);
> DataSet<Customer> r = cd.findCustomersFrom(city);
>
>
> The other key is remote data and change lists. I think there are
> (literally) about a thousand ways that already exist to handle the
> "local" data case. For change lists, interop with ADO.NET's change
> summary facilities would be interesting.
I agree. Also, it looks like Xcalia may have a similar thought:
http://www.xcalia.com/news/PR_2006-10-23.jsp
>
> I'm playing devil's advocate a bit with DAS, but I think it is
> important we have a clear statement as to when it is appropriate and
> not appropriate to use. One place to start would be to compare it to
> JDBC 4 and JPA.
We can get started with JPA:
* JPA is java-specific, container-based, built around a connected
data model and offers a complete O/R mapping for POJOs
* The RDB DAS is a java implementation of a language - neutral
concept (hopefully specified some day) that is containerless,
assumes a disconnected data model and provides a simple, implicit
mapping for SDO DataObjects (Dynamic or Static) to relational tables.
Anything else?
>
> Jim
>
> On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>
>> Hi Amita
>>
>> I think we were both going on the same way, with the DAS Service
>> sample,
>> altough i had the interface more like this, to be more flexible :
>>
>> public interface DASService {
>>
>> public DAS configureService(String configFile);
>
>
>> public DataObject executeCommand(String commandName);
>> public DataObject execute(String newCommand);
>> public void applyChanges(DataObject graphRoot);
>> }
>>
>>
>> As for having it as a sample, maybe we could defined the DASService
>> as one
>> sample itself, and have a second version of companyWeb that would
>> consume
>> the service, something like :
>>
>> das\samples\companyWeb
>> das\samples\dasService
>> das\samples.companyWeb.service
>>
>> or, more like BigBank
>>
>> das\samples\companyweb.Service\dasService
>> das\samples\companyweb.Service\webClient
>>
>> Or even in sampleApps...
>>
>> Toughts ?
>>
>>
>> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
>>
>>>
>>> Hi ,
>>> I am also following up another thread
>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg09944.html
>>> on the
>>> similar issue (JDBC stored procedure container
>>> using DAS)
>>> Besides the fact that I am actively working on the container work,
>>> I also
>>> have tried to
>>> develop a sample based on the below discussion, following dynamic
>>> approach.
>>>
>>> I am attaching the same here. Please take a look and give your
>>> suggestions.
>>> In this, StoredProcedureService implementation has setConfigInfo (DAS
>>> Config) and
>>> execute(Any SQL). This can be made more complete with executeSQL(),
>>> applyChanges()
>>> etc.
>>>
>>> Can this be added to the existing set of samples?
>>>
>>> Regards,
>>> Amita
>>>
>>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>>> >
>>> > Luciano Resende wrote:
>>> >
>>> > > Kevin, from what I understood from your suggestion, it was
>>> looking to
>>> > me
>>> > > more like exposing DAS as a service :
>>> > >
>>> > >>> public interface RDBDASService
>>> > >>> DataObject execute(String commandName);
>>> > >>> DataObject executeSQL(String abitrarySQL);
>>> > >>> void applyChanges(DataObject graphRoot);
>>> > >>> }
>>> > >>
>>> > Yes, I am talking about exposing a DAS Service configured with a
>>> > specific set of capabilities/commands defined in the DAS config
>>> file.
>>> > So, if the implementation of the service interface above was
>>> configured
>>> > to work with Customers they would use the service like this:
>>> >
>>> > List customers = myRDBDASService.execute("getAllCustomers");
>>> > String name = customers.get(0).getString("name");
>>> >
>>> > This is not much different than the static interface you proposed,
>>> > right?
>>> >
>>> > > And then, when a service developer defines the AccountService,
>>> he will
>>> >
>>> > > have
>>> > > to know about yet another service, about how DAS works, how it is
>>> > > configured, etc, etc... is that right ?
>>> > >
>>> > The abilities of the service are defined by the DAS config file.
>>> So,
>>> > the person or tool that provides the config file must understand
>>> how the
>>> >
>>> > RDB DAS APIs work. There is no getting around this.
>>> >
>>> > > My proposal was going more towards allowing the service
>>> developer to
>>> > > focus
>>> > > on defining the service, and let the "declarative das" to
>>> handle the
>>> > > persistent layer....
>>> > >
>>> > The DAS config file is the declaration of an instance of the
>>> DAS. That
>>> > instance can be exposed as a dynamic or typed service/ interface.
>>> That
>>> > seems to be the main discussion we are having. Although, I may be
>>> > missing something.
>>> >
>>> > > Also, by defining some conventions over configuration and/or using
>>> > > annotations (e.g @Procedure to force mapping to a stored
>>> procedure),
>>> > the
>>> > > service developer could really define a service that interacts
>>> with a
>>> > > RDB,
>>> > > without having to code the service persistence layer.
>>> > >
>>> > There is a lot of potential for the use of annotations.
>>> >
>>> > >
>>> > > - Luciano
>>> > >
>>> > >
>>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
>>> > >
>>> > >>
>>> > >> The real difference between the two approaches is that one is
>>> "Typed"
>>> > or
>>> > >> static and the other is dynamic. I think both are needed but was
>>> > >> suggesting that we start with dynamic since it is the most
>>> flexible
>>> > and
>>> > >> seems to be a reasonable stepping stone towards a static
>>> capability.
>>> > >>
>>> > >> With either, the user does not need to know about traditional
>>> > >> persistence frameworks. With the dynamic approach, however,
>>> the user
>>> > >> does need to know about the dynamic SDO API.
>>> > >>
>>> > >> So, with the static interface the user might write:
>>> > >>
>>> > >> List customers = accountService.getAllCustomers();
>>> > >> String name = ((Customer)customers.get(0)).getName();
>>> > >>
>>> > >> The equivalent dynamic API might be:
>>> > >>
>>> > >> List customers = dasService.execute("getAllCustomers");
>>> > >> String name = ((DataObject)customers.get(0)).getString
>>> ("name");
>>> > >>
>>> > >> The first is probably a little easier for the application
>>> developer
>>> > but
>>> > >> the second is much easier for the service developer. IMO, the
>>> dynamic
>>> > >> case is the best place to start and, again, we definitely will
>>> want
>>> > >> support for both.
>>> > >>
>>> > >> Thanks.
>>> > >> --
>>> > >> Kevin
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >> Jeremy Boynes wrote:
>>> > >>
>>> > >> > I think this would be useful but it seems more like a
>>> traditional
>>> > >> > persistence API than what Luciano was suggesting. With this
>>> one a
>>> > >> > user needs to know about DataObject's, commands, SQL strings
>>> etc.
>>> > >> > just like they would if they were using raw JDBC or JPA.
>>> > >> >
>>> > >> > On the other hand, Luciano's proposal seemed more about
>>> expressing
>>> > >> > high-level CRUD operations as operations on a service
>>> interface:
>>> > >> >
>>> > >> >>> public interface AccountService {
>>> > >> >>>
>>> > >> >>> public List getAllCustomers();
>>> > >> >>> public Object getCustomerAccount(String accountNumber);
>>> > >> >>> }
>>> > >> >>
>>> > >> >
>>> > >> > which is all application level concepts rather than persistence
>>> > level
>>> > >> > concepts. I'd actually go a little further and put that
>>> right into
>>> > >> > the service contract:
>>> > >> >
>>> > >> > public interface AccountService {
>>> > >> > List<Customer> getAllCustomers();
>>> > >> > Account getCustomerAccount(String accountNumber);
>>> > >> > }
>>> > >> >
>>> > >> > In a ideal world, if the user was able to accept standardized
>>> > >> > mappings (a la Rails et al) then no further configuration
>>> would be
>>> > >> > needed except to add this to the logical assembly:
>>> > >> >
>>> > >> > <component name="AccountStore">
>>> > >> > <implementation.das resource="MySQLDatabase"/>
>>> > >> > </component>
>>> > >> >
>>> > >> > With SCA's ability to translate service contracts, this
>>> should be
>>> > >> > callable from and deployable to any SCA runtime regardless of
>>> > whether
>>> > >> > it was being accessed locally, by WS-*, by IIOP or running on a
>>> > Java,
>>> > >> > C++ or PHP platform.
>>> > >> >
>>> > >> > The important thing here is that the client is isolated from
>>> how
>>> > the
>>> > >> > DAS component is provided. We could have multiple declarative
>>> > >> > implementations, say one based on RDB-DAS and one that did
>>> stuff
>>> > with
>>> > >> > XML databases like Xindice; alternatively, /without altering
>>> the
>>> > >> > client at all/ they could switch to a custom coded version
>>> written
>>> > in
>>> > >> > Java, C++ or a store procedure language like PL/SQL.
>>> > >> >
>>> > >> > --
>>> > >> > Jeremy
>>> > >> >
>>> > >> >
>>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>>> > >> >
>>> > >> >> 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 code specific to a new
>>> > >> >> service. Instead, the service will be "instantiated" based
>>> on the
>>> >
>>> > >> >> provided DAS config file. The service interface might look
>>> like
>>> > >> this:
>>> > >> >>
>>> > >> >> public interface RDBDASService
>>> > >> >> DataObject execute(String commandName);
>>> > >> >> DataObject executeSQL(String abitrarySQL);
>>> > >> >> void applyChanges(DataObject graphRoot);
>>> > >> >> }
>>> > >> >>
>>> > >> >> So, depending on the config file used to instantiate the
>>> service,
>>> > >> >> this interface could be used to return Customers/Accounts or
>>> > >> >> Toasters. In fact, a lot could be achieved with no
>>> > configuration at
>>> > >> >> all by restricting use to: DataObject executeSQL(String
>>> > >> abitrarySQL);
>>> > >> >>
>>> > >> >> I expand a bit here: http://mail-archives.apache.org/
>>> mod_mbox/ws-
>>> > >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net %3e
>>> > >> >>
>>> > >> >> Once this was working it should be straightforward to build
>>> more
>>> > >> >> strongly typed services and possible put together some
>>> generation
>>> > >> >> tooling. We could also start looking at support for a more
>>> > RESTFul
>>> > >> >> interface.
>>> > >> >> --
>>> > >> >> Kevin
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> > >> >> Luciano Resende wrote:
>>> > >> >>
>>> > >> >>> Recently, people have been starting to talk about better DAS
>>> > >> >>> integration
>>> > >> >>> with DAS, and below are some threads on the subject :
>>> > >> >>>
>>> > >> >>>
>>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08833.html
>>> > >> >>>
>>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08923.html
>>> > >> >>>
>>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>>> msg09715.html
>>> >
>>> > >> >>>
>>> > >> >>> I'm new on the SCA side, so please help me make sure what I'm
>>> > >> >>> saying is not
>>> > >> >>> yet available on SCA today.
>>> > >> >>>
>>> > >> >>> Today, defining a service to work with a relational
>>> database, you
>>> > >> >>> will need
>>> > >> >>> to code the persistence side of the service where CRUD
>>> operations
>>> > >> >>> to the
>>> > >> >>> database will be done.
>>> > >> >>> I was thinking on a simpler, easier way, where coding the
>>> CRUD
>>> > >> >>> operations on
>>> > >> >>> the persistence layer would be avoided as much as possible.
>>> > >> >>> The idea would be to have a more "declarative DAS" when
>>> defining
>>> > SCA
>>> > >> >>> Services, so you would either use some Annotations or SCDL to
>>> > >> have the
>>> > >> >>> "declarative DAS" configuration inside it.
>>> > >> >>>
>>> > >> >>> I was thinking on something like....
>>> > >> >>>
>>> > >> >>> SCDL Definition would look something like this :
>>> > >> >>>
>>> > >> >>> <component name="AccountDataService">
>>> > >> >>> <interface.java
>>> > >> >>> class="bigbank.account.services.account.AccountService"/>
>>> > >> >>> <implementation.das="dasConfig.properties"
>>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>>> > >> >>> </component>
>>> > >> >>>
>>> > >> >>> The AccountService Interface would look like this (missing
>>> any
>>> > SCA
>>> > >> >>> annotations):
>>> > >> >>>
>>> > >> >>> public interface AccountService {
>>> > >> >>>
>>> > >> >>> public List getAllCustomers();
>>> > >> >>> public Object getCustomerAccount(String accountNumber);
>>> > >> >>> }
>>> > >> >>>
>>> > >> >>> The DAS config would look like this, and would have the
>>> > definition
>>> > >> >>> for the
>>> > >> >>> "all companies" command.
>>> > >> >>>
>>> > >> >>> <Config ...>
>>> > >> >>> ...
>>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/bigbank"/>
>>> > >> >>>
>>> > >> >>> <Command name="getAllCustomers" SQL="select * from
>>> CUSTOMERS"
>>> > >> >>> kind="Select"/>
>>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
>>> accountNumber,
>>> > >> >>> accountType, balance FROM accounts where accountNumber = ?"
>>> > >> >>> kind="Select" />
>>> > >> >>> ...
>>> > >> >>> </Config>
>>> > >> >>>
>>> > >> >>>
>>> > >> >>> Mapping between interface methods and DAS Commands
>>> > >> >>> - If a DAS config file is provided, based on the
>>> > SCDL definition,
>>> > >> we
>>> > >> >>> would look for "DAS command" based on the name of the getter
>>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers command)
>>> > >> >>> - Otherwise, we would try to do a map directly to a
>>> > >> stored procedure
>>> > >> >>> - We could also have a way to force the mapping by using
>>> > >> annotation
>>> > >> >>> (e.g@Procedure on the method level)
>>> > >> >>>
>>> > >> >>> Mapping between method parameter and command parameter
>>> > >> >>> - We would need to define a method for mapping the method
>>> > >> >>> parameters to
>>> > >> >>> the query paramters either based on position ( e.g first
>>> method
>>> > >> >>> parameter
>>> > >> >>> maps to the first command paramter), or we would do some
>>> > mapping by
>>> > >> >>> name
>>> > >> >>> (currently not available in Tuscany DAS)
>>> > >> >>>
>>> > >> >>> Note:
>>> > >> >>> - A SCDL connection information would override the DAS
>>> Config
>>> > file
>>> > >> >>> connection information.
>>> > >> >>>
>>> > >> >>>
>>> > >> >>> Benefits
>>> > >> >>> - It's All about simplicity and easy of use
>>> > >> >>> - This would allow a user to define a service without
>>> having to
>>> >
>>> > >> >>> explicitly having to code any Data Access related code.
>>> > >> >>>
>>> > >> >>>
>>> > >> >>> Implementation approaches
>>> > >> >>> - Utilizing DAS : This approach would start from the
>>> current
>>> > >> >>> Tuscany DAS
>>> > >> >>> implementation, where functionality would be already
>>> > available, but
>>> > >> >>> the
>>> > >> >>> service implementation would be tied to SDO and RDB as this
>>> > is what
>>> > >> >>> DAS
>>> > >> >>> supports today.
>>> > >> >>>
>>> > >> >>> - Start simple and grow : We could start simple, by
>>> having a
>>> > >> simple
>>> > >> >>> implementation based on JDBC and would return some simple
>>> > >> >>> collection as a
>>> > >> >>> return type (e.g List or a even a Recordset), this could
>>> give us
>>> > a
>>> > >> >>> quick
>>> > >> >>> start to flush implementation details and get a proven
>>> design,
>>> > and
>>> > >> >>> this
>>> > >> >>> could get evolved to use a DAS that would support multiple
>>> > backends
>>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as non- SDO
>>> types
>>> > >> as a
>>> > >> >>> command
>>> > >> >>> result.
>>> > >> >>>
>>> > >> >>>
>>> > >> >>> Toughts ?
>>> > >> >>>
>>> > >> >>> - Luciano
>>> > >> >>>
>>> > >> >>>
>>> > >> >>>
>>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
>>> > >> >>>
>>> > >> >>>>
>>> > >> >>>> 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. Another thing we want to eventually
>>> explore is
>>> > >> >>>> exposing
>>> > >> >>>> a DAS as REST-oriented services. As we have seen from the
>>> > parent
>>> > >> >>>> thread
>>> > >> >>>> there are almost too many possible approaches.
>>> > >> >>>>
>>> > >> >>>> My first thought is to model the DAS as a service and
>>> create a
>>> > new
>>> > >> >>>> implementation kind (implementation.rdbdas). The main
>>> reason
>>> > has
>>> > >> >>>> to do
>>> > >> >>>> with the potential declarative aspect of DAS that
>>> > Jeremy mentioned
>>> > >> >>>> which
>>> > >> >>>> is all about creating data access services
>>> declaratively. A new
>>> > >> >>>> component type and a service that we build by hand would be
>>> > a good
>>> > >> >>>> step
>>> > >> >>>> in this direction.
>>> > >> >>>>
>>> > >> >>>> We might want to expose a DAS service with an interface like
>>> > this:
>>> > >> >>>>
>>> > >> >>>> public interface RDBDASService
>>> > >> >>>> void applyChanges(DataObject graphRoot);
>>> > >> >>>> DataObject execute(String commandName);
>>> > >> >>>> DataObject executeSQL(String abitrarySQL);
>>> > >> >>>> }
>>> > >> >>>>
>>> > >> >>>> The service would be initialized with an optional RDB DAS
>>> > >> config file
>>> > >> >>>> that defines connection properties, a set of commands,
>>> etc. So,
>>> > >> >>>> different services implementing the same interface could be
>>> > >> >>>> initialized
>>> > >> >>>> from separate config files.
>>> > >> >>>>
>>> > >> >>>> Eventually, we might want to build services like this:
>>> > >> >>>>
>>> > >> >>>> public interface Customers_RDBDASService
>>> > >> >>>> void applyChanges(DataObject graphRoot);
>>> > >> >>>> DataObject getAllCustomersWithLastName (String
>>> > lastName);
>>> > >> >>>> DataObject getAll CustomersAndOrdersForID (int
>>> > customerId);
>>> > >> >>>> }
>>> > >> >>>>
>>> > >> >>>> But, for this to be very useful would probably require
>>> some code
>>> > >> >>>> generation tooling.
>>> > >> >>>>
>>> > >> >>>> Thoughts?
>>> > >> >>>>
>>> > >> >>>> --Kevin
>>> > >> >>>>
>>> > >> >>>>
>>> > >> >>>> Luciano Resende wrote:
>>> > >> >>>>
>>> > >> >>>> > I'm starting to look in ways we could have a declarative
>>> > DAS and
>>> > >> >>>> will be
>>> > >> >>>> > posting my progress into the list / wiki soon...
>>> > >> >>>> >
>>> > >> >>>> > - Luciano
>>> > >> >>>> >
>>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org > 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 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.
>>> > >> >>>> >>
>>> > >> >>>> >> "Thanks for volunteering" :-)
>>> > >> >>>> >> If someone wants to contribute these, I think we
>>> > should welcome
>>> > >> it
>>> > >> >>>> >> like we would any other contribution.
>>> > >> >>>> >>
>>> > >> >>>> >> >> 3) to access data through an application service with
>>> > >> >>>> declarative
>>> > >> >>>> >> >> implementation by DAS
>>> > >> >>>> >> > Yes, that's the value I see in DAS
>>> > >> >>>> >>
>>> > >> >>>> >> I think this is already on the DAS folks radar.
>>> > >> >>>> >> --
>>> > >> >>>> >> Jeremy
>>> > >> >>>> >>
>>> > >> >>>> >>
>>> > >> >>>>
>>> > >>
>>> --------------------------------------------------------------------
>>> > >> -
>>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
>>> unsubscribe@ws.apache.org
>>> > >> >>>> >> For additional commands, e-mail:
>>> > tuscany-dev-help@ws.apache.org
>>> > >> >>>> >>
>>> > >> >>>> >>
>>> > >> >>>> >
>>> > >> >>>>
>>> > >> >>>>
>>> > >> >>>>
>>> > >> >>>>
>>> > >>
>>> --------------------------------------------------------------------
>>> > >> -
>>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
>>> unsubscribe@ws.apache.org
>>> > >> >>>> For additional commands, e-mail: tuscany-dev-
>>> help@ws.apache.org
>>> > >> >>>>
>>> > >> >>>>
>>> > >> >>>
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> >
>>> ---------------------------------------------------------------------
>>> > >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > >> >> For additional commands, e-mail: tuscany-dev-
>>> help@ws.apache.org
>>> > >> >>
>>> > >> >
>>> > >> >
>>> > >> >
>>> >
>>> ---------------------------------------------------------------------
>>> > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > >> > For additional commands, e-mail: tuscany-dev- help@ws.apache.org
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> ---------------------------------------------------------------------
>>> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> > >>
>>> > >>
>>> > >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Jim Marino <jm...@myromatours.com>.
When I first read the thread on this, I thought the DAS service would
be a component extension type (e.g. analogous to a
implementation.java or implementation.ejb) and not a component
implementation type, which would allow for dynamic and eventually
declarative configuration styles. Either way, though, I am curious as
to why
public DAS configureService(String configFile);
exists as part of the service definition? If the DAS service was a
component extension type, it could be handled as part of the
application bootstrap. If the DAS service was a component
implementation type, the configuration file URI could be passed in as
a property and then processed in an initializer method decorated by
the SCA @Init annotation. In the latter case, if the implementation
of DASService thread-safe (hopefully it is since configuration would
seem to be a heavyweight operation), then I would make the component
module scoped to avoid initialization overhead on every resolution.
In both approaches (extension vs. implementation type), having
configuration exposed to the application doesn't quite feel right,
since that is what DI tries to externalize.
Also, I was thinking that in having this a component extension type,
the service interfaces returned from a resolution could include the
dynamic one described below or static ones people have mentioned. I
guess it is best to start with the easier-to-implement part first and
support the dynamic interface.
FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
understand what DAS provides in relation to other persistence
technologies. Outside of the Java world, Microsoft is promoting LINQ
which is really interesting, and it would be informative to compare
the goals of DAS with that approach (there are obvious differences
such as having the query language a strongly-typed part of the
programming language, e.g. C#, and LINQ's use of closures).
In contrasting DAS to O-R technologies, I see the primary use cases
for the former being a quick way to issue a query that may be
executed against *heterogeneous* data stores and have that data flow
remotely or to a client that is not necessarily Java-based. One key
for me is heterogeneous data since JDBC 4 lets me do this (Hibernate
and JPA are about as easy):
public interface CustomerDao extends BaseQuery {
@Select("select * from customers where city = ?1")
DataSet<Customer> findCustomersFrom(String city);
}
CustomerDao cd = QueryObjectFactory.createQueryObject
(CustomerDao.class, datasource);
DataSet<Customer> r = cd.findCustomersFrom(city);
The other key is remote data and change lists. I think there are
(literally) about a thousand ways that already exist to handle the
"local" data case. For change lists, interop with ADO.NET's change
summary facilities would be interesting.
I'm playing devil's advocate a bit with DAS, but I think it is
important we have a clear statement as to when it is appropriate and
not appropriate to use. One place to start would be to compare it to
JDBC 4 and JPA.
Jim
On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> Hi Amita
>
> I think we were both going on the same way, with the DAS Service
> sample,
> altough i had the interface more like this, to be more flexible :
>
> public interface DASService {
>
> public DAS configureService(String configFile);
> public DataObject executeCommand(String commandName);
> public DataObject execute(String newCommand);
> public void applyChanges(DataObject graphRoot);
> }
>
>
> As for having it as a sample, maybe we could defined the DASService
> as one
> sample itself, and have a second version of companyWeb that would
> consume
> the service, something like :
>
> das\samples\companyWeb
> das\samples\dasService
> das\samples.companyWeb.service
>
> or, more like BigBank
>
> das\samples\companyweb.Service\dasService
> das\samples\companyweb.Service\webClient
>
> Or even in sampleApps...
>
> Toughts ?
>
>
> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
>>
>> Hi ,
>> I am also following up another thread
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> msg09944.html on the
>> similar issue (JDBC stored procedure container
>> using DAS)
>> Besides the fact that I am actively working on the container work,
>> I also
>> have tried to
>> develop a sample based on the below discussion, following dynamic
>> approach.
>>
>> I am attaching the same here. Please take a look and give your
>> suggestions.
>> In this, StoredProcedureService implementation has setConfigInfo (DAS
>> Config) and
>> execute(Any SQL). This can be made more complete with executeSQL(),
>> applyChanges()
>> etc.
>>
>> Can this be added to the existing set of samples?
>>
>> Regards,
>> Amita
>>
>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >
>> > Luciano Resende wrote:
>> >
>> > > Kevin, from what I understood from your suggestion, it was
>> looking to
>> > me
>> > > more like exposing DAS as a service :
>> > >
>> > >>> public interface RDBDASService
>> > >>> DataObject execute(String commandName);
>> > >>> DataObject executeSQL(String abitrarySQL);
>> > >>> void applyChanges(DataObject graphRoot);
>> > >>> }
>> > >>
>> > Yes, I am talking about exposing a DAS Service configured with a
>> > specific set of capabilities/commands defined in the DAS config
>> file.
>> > So, if the implementation of the service interface above was
>> configured
>> > to work with Customers they would use the service like this:
>> >
>> > List customers = myRDBDASService.execute("getAllCustomers");
>> > String name = customers.get(0).getString("name");
>> >
>> > This is not much different than the static interface you proposed,
>> > right?
>> >
>> > > And then, when a service developer defines the AccountService,
>> he will
>> >
>> > > have
>> > > to know about yet another service, about how DAS works, how it is
>> > > configured, etc, etc... is that right ?
>> > >
>> > The abilities of the service are defined by the DAS config
>> file. So,
>> > the person or tool that provides the config file must understand
>> how the
>> >
>> > RDB DAS APIs work. There is no getting around this.
>> >
>> > > My proposal was going more towards allowing the service
>> developer to
>> > > focus
>> > > on defining the service, and let the "declarative das" to
>> handle the
>> > > persistent layer....
>> > >
>> > The DAS config file is the declaration of an instance of the
>> DAS. That
>> > instance can be exposed as a dynamic or typed service/
>> interface. That
>> > seems to be the main discussion we are having. Although, I may be
>> > missing something.
>> >
>> > > Also, by defining some conventions over configuration and/or
>> using
>> > > annotations (e.g @Procedure to force mapping to a stored
>> procedure),
>> > the
>> > > service developer could really define a service that interacts
>> with a
>> > > RDB,
>> > > without having to code the service persistence layer.
>> > >
>> > There is a lot of potential for the use of annotations.
>> >
>> > >
>> > > - Luciano
>> > >
>> > >
>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
>> > >
>> > >>
>> > >> The real difference between the two approaches is that one is
>> "Typed"
>> > or
>> > >> static and the other is dynamic. I think both are needed but
>> was
>> > >> suggesting that we start with dynamic since it is the most
>> flexible
>> > and
>> > >> seems to be a reasonable stepping stone towards a static
>> capability.
>> > >>
>> > >> With either, the user does not need to know about traditional
>> > >> persistence frameworks. With the dynamic approach, however,
>> the user
>> > >> does need to know about the dynamic SDO API.
>> > >>
>> > >> So, with the static interface the user might write:
>> > >>
>> > >> List customers = accountService.getAllCustomers();
>> > >> String name = ((Customer)customers.get(0)).getName();
>> > >>
>> > >> The equivalent dynamic API might be:
>> > >>
>> > >> List customers = dasService.execute("getAllCustomers");
>> > >> String name = ((DataObject)customers.get(0)).getString
>> ("name");
>> > >>
>> > >> The first is probably a little easier for the application
>> developer
>> > but
>> > >> the second is much easier for the service developer. IMO, the
>> dynamic
>> > >> case is the best place to start and, again, we definitely
>> will want
>> > >> support for both.
>> > >>
>> > >> Thanks.
>> > >> --
>> > >> Kevin
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> Jeremy Boynes wrote:
>> > >>
>> > >> > I think this would be useful but it seems more like a
>> traditional
>> > >> > persistence API than what Luciano was suggesting. With this
>> one a
>> > >> > user needs to know about DataObject's, commands, SQL
>> strings etc.
>> > >> > just like they would if they were using raw JDBC or JPA.
>> > >> >
>> > >> > On the other hand, Luciano's proposal seemed more about
>> expressing
>> > >> > high-level CRUD operations as operations on a service
>> interface:
>> > >> >
>> > >> >>> public interface AccountService {
>> > >> >>>
>> > >> >>> public List getAllCustomers();
>> > >> >>> public Object getCustomerAccount(String accountNumber);
>> > >> >>> }
>> > >> >>
>> > >> >
>> > >> > which is all application level concepts rather than
>> persistence
>> > level
>> > >> > concepts. I'd actually go a little further and put that
>> right into
>> > >> > the service contract:
>> > >> >
>> > >> > public interface AccountService {
>> > >> > List<Customer> getAllCustomers();
>> > >> > Account getCustomerAccount(String accountNumber);
>> > >> > }
>> > >> >
>> > >> > In a ideal world, if the user was able to accept standardized
>> > >> > mappings (a la Rails et al) then no further configuration
>> would be
>> > >> > needed except to add this to the logical assembly:
>> > >> >
>> > >> > <component name="AccountStore">
>> > >> > <implementation.das resource="MySQLDatabase"/>
>> > >> > </component>
>> > >> >
>> > >> > With SCA's ability to translate service contracts, this
>> should be
>> > >> > callable from and deployable to any SCA runtime regardless of
>> > whether
>> > >> > it was being accessed locally, by WS-*, by IIOP or running
>> on a
>> > Java,
>> > >> > C++ or PHP platform.
>> > >> >
>> > >> > The important thing here is that the client is isolated
>> from how
>> > the
>> > >> > DAS component is provided. We could have multiple declarative
>> > >> > implementations, say one based on RDB-DAS and one that did
>> stuff
>> > with
>> > >> > XML databases like Xindice; alternatively, /without
>> altering the
>> > >> > client at all/ they could switch to a custom coded version
>> written
>> > in
>> > >> > Java, C++ or a store procedure language like PL/SQL.
>> > >> >
>> > >> > --
>> > >> > Jeremy
>> > >> >
>> > >> >
>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>> > >> >
>> > >> >> 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 code specific to a new
>> > >> >> service. Instead, the service will be "instantiated"
>> based on the
>> >
>> > >> >> provided DAS config file. The service interface might
>> look like
>> > >> this:
>> > >> >>
>> > >> >> public interface RDBDASService
>> > >> >> DataObject execute(String commandName);
>> > >> >> DataObject executeSQL(String abitrarySQL);
>> > >> >> void applyChanges(DataObject graphRoot);
>> > >> >> }
>> > >> >>
>> > >> >> So, depending on the config file used to instantiate the
>> service,
>> > >> >> this interface could be used to return Customers/Accounts or
>> > >> >> Toasters. In fact, a lot could be achieved with no
>> > configuration at
>> > >> >> all by restricting use to: DataObject executeSQL(String
>> > >> abitrarySQL);
>> > >> >>
>> > >> >> I expand a bit here: http://mail-archives.apache.org/
>> mod_mbox/ws-
>> > >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net %3e
>> > >> >>
>> > >> >> Once this was working it should be straightforward to
>> build more
>> > >> >> strongly typed services and possible put together some
>> generation
>> > >> >> tooling. We could also start looking at support for a more
>> > RESTFul
>> > >> >> interface.
>> > >> >> --
>> > >> >> Kevin
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> Luciano Resende wrote:
>> > >> >>
>> > >> >>> Recently, people have been starting to talk about better DAS
>> > >> >>> integration
>> > >> >>> with DAS, and below are some threads on the subject :
>> > >> >>>
>> > >> >>>
>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08833.html
>> > >> >>>
>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08923.html
>> > >> >>>
>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> msg09715.html
>> >
>> > >> >>>
>> > >> >>> I'm new on the SCA side, so please help me make sure what
>> I'm
>> > >> >>> saying is not
>> > >> >>> yet available on SCA today.
>> > >> >>>
>> > >> >>> Today, defining a service to work with a relational
>> database, you
>> > >> >>> will need
>> > >> >>> to code the persistence side of the service where CRUD
>> operations
>> > >> >>> to the
>> > >> >>> database will be done.
>> > >> >>> I was thinking on a simpler, easier way, where coding the
>> CRUD
>> > >> >>> operations on
>> > >> >>> the persistence layer would be avoided as much as possible.
>> > >> >>> The idea would be to have a more "declarative DAS" when
>> defining
>> > SCA
>> > >> >>> Services, so you would either use some Annotations or
>> SCDL to
>> > >> have the
>> > >> >>> "declarative DAS" configuration inside it.
>> > >> >>>
>> > >> >>> I was thinking on something like....
>> > >> >>>
>> > >> >>> SCDL Definition would look something like this :
>> > >> >>>
>> > >> >>> <component name="AccountDataService">
>> > >> >>> <interface.java
>> > >> >>> class="bigbank.account.services.account.AccountService"/>
>> > >> >>> <implementation.das="dasConfig.properties"
>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> > >> >>> </component>
>> > >> >>>
>> > >> >>> The AccountService Interface would look like this
>> (missing any
>> > SCA
>> > >> >>> annotations):
>> > >> >>>
>> > >> >>> public interface AccountService {
>> > >> >>>
>> > >> >>> public List getAllCustomers();
>> > >> >>> public Object getCustomerAccount(String accountNumber);
>> > >> >>> }
>> > >> >>>
>> > >> >>> The DAS config would look like this, and would have the
>> > definition
>> > >> >>> for the
>> > >> >>> "all companies" command.
>> > >> >>>
>> > >> >>> <Config ...>
>> > >> >>> ...
>> > >> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/bigbank"/>
>> > >> >>>
>> > >> >>> <Command name="getAllCustomers" SQL="select * from
>> CUSTOMERS"
>> > >> >>> kind="Select"/>
>> > >> >>> <Command name="getCustomerAccount" SQL="SELECT
>> accountNumber,
>> > >> >>> accountType, balance FROM accounts where accountNumber = ?"
>> > >> >>> kind="Select" />
>> > >> >>> ...
>> > >> >>> </Config>
>> > >> >>>
>> > >> >>>
>> > >> >>> Mapping between interface methods and DAS Commands
>> > >> >>> - If a DAS config file is provided, based on the
>> > SCDL definition,
>> > >> we
>> > >> >>> would look for "DAS command" based on the name of the getter
>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers command)
>> > >> >>> - Otherwise, we would try to do a map directly to a
>> > >> stored procedure
>> > >> >>> - We could also have a way to force the mapping by using
>> > >> annotation
>> > >> >>> (e.g@Procedure on the method level)
>> > >> >>>
>> > >> >>> Mapping between method parameter and command parameter
>> > >> >>> - We would need to define a method for mapping the method
>> > >> >>> parameters to
>> > >> >>> the query paramters either based on position ( e.g first
>> method
>> > >> >>> parameter
>> > >> >>> maps to the first command paramter), or we would do some
>> > mapping by
>> > >> >>> name
>> > >> >>> (currently not available in Tuscany DAS)
>> > >> >>>
>> > >> >>> Note:
>> > >> >>> - A SCDL connection information would override the DAS
>> Config
>> > file
>> > >> >>> connection information.
>> > >> >>>
>> > >> >>>
>> > >> >>> Benefits
>> > >> >>> - It's All about simplicity and easy of use
>> > >> >>> - This would allow a user to define a service without
>> having to
>> >
>> > >> >>> explicitly having to code any Data Access related code.
>> > >> >>>
>> > >> >>>
>> > >> >>> Implementation approaches
>> > >> >>> - Utilizing DAS : This approach would start from the
>> current
>> > >> >>> Tuscany DAS
>> > >> >>> implementation, where functionality would be already
>> > available, but
>> > >> >>> the
>> > >> >>> service implementation would be tied to SDO and RDB as this
>> > is what
>> > >> >>> DAS
>> > >> >>> supports today.
>> > >> >>>
>> > >> >>> - Start simple and grow : We could start simple, by
>> having a
>> > >> simple
>> > >> >>> implementation based on JDBC and would return some simple
>> > >> >>> collection as a
>> > >> >>> return type (e.g List or a even a Recordset), this could
>> give us
>> > a
>> > >> >>> quick
>> > >> >>> start to flush implementation details and get a proven
>> design,
>> > and
>> > >> >>> this
>> > >> >>> could get evolved to use a DAS that would support multiple
>> > backends
>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as non-
>> SDO types
>> > >> as a
>> > >> >>> command
>> > >> >>> result.
>> > >> >>>
>> > >> >>>
>> > >> >>> Toughts ?
>> > >> >>>
>> > >> >>> - Luciano
>> > >> >>>
>> > >> >>>
>> > >> >>>
>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
>> > >> >>>
>> > >> >>>>
>> > >> >>>> 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. Another thing we want to eventually
>> explore is
>> > >> >>>> exposing
>> > >> >>>> a DAS as REST-oriented services. As we have seen from the
>> > parent
>> > >> >>>> thread
>> > >> >>>> there are almost too many possible approaches.
>> > >> >>>>
>> > >> >>>> My first thought is to model the DAS as a service and
>> create a
>> > new
>> > >> >>>> implementation kind (implementation.rdbdas). The main
>> reason
>> > has
>> > >> >>>> to do
>> > >> >>>> with the potential declarative aspect of DAS that
>> > Jeremy mentioned
>> > >> >>>> which
>> > >> >>>> is all about creating data access services
>> declaratively. A new
>> > >> >>>> component type and a service that we build by hand would be
>> > a good
>> > >> >>>> step
>> > >> >>>> in this direction.
>> > >> >>>>
>> > >> >>>> We might want to expose a DAS service with an interface
>> like
>> > this:
>> > >> >>>>
>> > >> >>>> public interface RDBDASService
>> > >> >>>> void applyChanges(DataObject graphRoot);
>> > >> >>>> DataObject execute(String commandName);
>> > >> >>>> DataObject executeSQL(String abitrarySQL);
>> > >> >>>> }
>> > >> >>>>
>> > >> >>>> The service would be initialized with an optional RDB DAS
>> > >> config file
>> > >> >>>> that defines connection properties, a set of commands,
>> etc. So,
>> > >> >>>> different services implementing the same interface could be
>> > >> >>>> initialized
>> > >> >>>> from separate config files.
>> > >> >>>>
>> > >> >>>> Eventually, we might want to build services like this:
>> > >> >>>>
>> > >> >>>> public interface Customers_RDBDASService
>> > >> >>>> void applyChanges(DataObject graphRoot);
>> > >> >>>> DataObject getAllCustomersWithLastName (String
>> > lastName);
>> > >> >>>> DataObject getAll CustomersAndOrdersForID (int
>> > customerId);
>> > >> >>>> }
>> > >> >>>>
>> > >> >>>> But, for this to be very useful would probably require
>> some code
>> > >> >>>> generation tooling.
>> > >> >>>>
>> > >> >>>> Thoughts?
>> > >> >>>>
>> > >> >>>> --Kevin
>> > >> >>>>
>> > >> >>>>
>> > >> >>>> Luciano Resende wrote:
>> > >> >>>>
>> > >> >>>> > I'm starting to look in ways we could have a declarative
>> > DAS and
>> > >> >>>> will be
>> > >> >>>> > posting my progress into the list / wiki soon...
>> > >> >>>> >
>> > >> >>>> > - Luciano
>> > >> >>>> >
>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org > 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 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.
>> > >> >>>> >>
>> > >> >>>> >> "Thanks for volunteering" :-)
>> > >> >>>> >> If someone wants to contribute these, I think we
>> > should welcome
>> > >> it
>> > >> >>>> >> like we would any other contribution.
>> > >> >>>> >>
>> > >> >>>> >> >> 3) to access data through an application service with
>> > >> >>>> declarative
>> > >> >>>> >> >> implementation by DAS
>> > >> >>>> >> > Yes, that's the value I see in DAS
>> > >> >>>> >>
>> > >> >>>> >> I think this is already on the DAS folks radar.
>> > >> >>>> >> --
>> > >> >>>> >> Jeremy
>> > >> >>>> >>
>> > >> >>>> >>
>> > >> >>>>
>> > >>
>> --------------------------------------------------------------------
>> > >> -
>> > >> >>>> >> To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> > >> >>>> >> For additional commands, e-mail:
>> > tuscany-dev-help@ws.apache.org
>> > >> >>>> >>
>> > >> >>>> >>
>> > >> >>>> >
>> > >> >>>>
>> > >> >>>>
>> > >> >>>>
>> > >> >>>>
>> > >>
>> --------------------------------------------------------------------
>> > >> -
>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> > >> >>>> For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> > >> >>>>
>> > >> >>>>
>> > >> >>>
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>
>> >
>> ---------------------------------------------------------------------
>> > >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > >> >> For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> >
>> ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > >> > For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > >>
>> > >>
>> > >
>> >
>> >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Luciano Resende <lu...@gmail.com>.
Kevin, from what I understood from your suggestion, it was looking to me
more like exposing DAS as a service :
>> public interface RDBDASService
>> DataObject execute(String commandName);
>> DataObject executeSQL(String abitrarySQL);
>> void applyChanges(DataObject graphRoot);
>> }
And then, when a service developer defines the AccountService, he will have
to know about yet another service, about how DAS works, how it is
configured, etc, etc... is that right ?
My proposal was going more towards allowing the service developer to focus
on defining the service, and let the "declarative das" to handle the
persistent layer....
Also, by defining some conventions over configuration and/or using
annotations (e.g @Procedure to force mapping to a stored procedure), the
service developer could really define a service that interacts with a RDB,
without having to code the service persistence layer.
- Luciano
On 10/19/06, Kevin Williams <ke...@qwest.net> wrote:
>
> The real difference between the two approaches is that one is "Typed" or
> static and the other is dynamic. I think both are needed but was
> suggesting that we start with dynamic since it is the most flexible and
> seems to be a reasonable stepping stone towards a static capability.
>
> With either, the user does not need to know about traditional
> persistence frameworks. With the dynamic approach, however, the user
> does need to know about the dynamic SDO API.
>
> So, with the static interface the user might write:
>
> List customers = accountService.getAllCustomers();
> String name = ((Customer)customers.get(0)).getName();
>
> The equivalent dynamic API might be:
>
> List customers = dasService.execute("getAllCustomers");
> String name = ((DataObject)customers.get(0)).getString("name");
>
> The first is probably a little easier for the application developer but
> the second is much easier for the service developer. IMO, the dynamic
> case is the best place to start and, again, we definitely will want
> support for both.
>
> Thanks.
> --
> Kevin
>
>
>
>
>
>
> Jeremy Boynes wrote:
>
> > I think this would be useful but it seems more like a traditional
> > persistence API than what Luciano was suggesting. With this one a
> > user needs to know about DataObject's, commands, SQL strings etc.
> > just like they would if they were using raw JDBC or JPA.
> >
> > On the other hand, Luciano's proposal seemed more about expressing
> > high-level CRUD operations as operations on a service interface:
> >
> >>> public interface AccountService {
> >>>
> >>> public List getAllCustomers();
> >>> public Object getCustomerAccount(String accountNumber);
> >>> }
> >>
> >
> > which is all application level concepts rather than persistence level
> > concepts. I'd actually go a little further and put that right into
> > the service contract:
> >
> > public interface AccountService {
> > List<Customer> getAllCustomers();
> > Account getCustomerAccount(String accountNumber);
> > }
> >
> > In a ideal world, if the user was able to accept standardized
> > mappings (a la Rails et al) then no further configuration would be
> > needed except to add this to the logical assembly:
> >
> > <component name="AccountStore">
> > <implementation.das resource="MySQLDatabase"/>
> > </component>
> >
> > With SCA's ability to translate service contracts, this should be
> > callable from and deployable to any SCA runtime regardless of whether
> > it was being accessed locally, by WS-*, by IIOP or running on a Java,
> > C++ or PHP platform.
> >
> > The important thing here is that the client is isolated from how the
> > DAS component is provided. We could have multiple declarative
> > implementations, say one based on RDB-DAS and one that did stuff with
> > XML databases like Xindice; alternatively, /without altering the
> > client at all/ they could switch to a custom coded version written in
> > Java, C++ or a store procedure language like PL/SQL.
> >
> > --
> > Jeremy
> >
> >
> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >
> >> 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 code specific to a new
> >> service. Instead, the service will be "instantiated" based on the
> >> provided DAS config file. The service interface might look like this:
> >>
> >> public interface RDBDASService
> >> DataObject execute(String commandName);
> >> DataObject executeSQL(String abitrarySQL);
> >> void applyChanges(DataObject graphRoot);
> >> }
> >>
> >> So, depending on the config file used to instantiate the service,
> >> this interface could be used to return Customers/Accounts or
> >> Toasters. In fact, a lot could be achieved with no configuration at
> >> all by restricting use to: DataObject executeSQL(String abitrarySQL);
> >>
> >> I expand a bit here: http://mail-archives.apache.org/mod_mbox/ws-
> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >>
> >> Once this was working it should be straightforward to build more
> >> strongly typed services and possible put together some generation
> >> tooling. We could also start looking at support for a more RESTFul
> >> interface.
> >> --
> >> Kevin
> >>
> >>
> >>
> >>
> >> Luciano Resende wrote:
> >>
> >>> Recently, people have been starting to talk about better DAS
> >>> integration
> >>> with DAS, and below are some threads on the subject :
> >>>
> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08833.html
> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08923.html
> >>> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09715.html
> >>>
> >>> I'm new on the SCA side, so please help me make sure what I'm
> >>> saying is not
> >>> yet available on SCA today.
> >>>
> >>> Today, defining a service to work with a relational database, you
> >>> will need
> >>> to code the persistence side of the service where CRUD operations
> >>> to the
> >>> database will be done.
> >>> I was thinking on a simpler, easier way, where coding the CRUD
> >>> operations on
> >>> the persistence layer would be avoided as much as possible.
> >>> The idea would be to have a more "declarative DAS" when defining SCA
> >>> Services, so you would either use some Annotations or SCDL to
> have the
> >>> "declarative DAS" configuration inside it.
> >>>
> >>> I was thinking on something like....
> >>>
> >>> SCDL Definition would look something like this :
> >>>
> >>> <component name="AccountDataService">
> >>> <interface.java
> >>> class="bigbank.account.services.account.AccountService"/>
> >>> <implementation.das="dasConfig.properties"
> >>> connection="java:comp/env/jdbc/bigbank"/>
> >>> </component>
> >>>
> >>> The AccountService Interface would look like this (missing any SCA
> >>> annotations):
> >>>
> >>> public interface AccountService {
> >>>
> >>> public List getAllCustomers();
> >>> public Object getCustomerAccount(String accountNumber);
> >>> }
> >>>
> >>> The DAS config would look like this, and would have the definition
> >>> for the
> >>> "all companies" command.
> >>>
> >>> <Config ...>
> >>> ...
> >>> <ConnectionInfo dataSource="java:comp/env/jdbc/bigbank"/>
> >>>
> >>> <Command name="getAllCustomers" SQL="select * from CUSTOMERS"
> >>> kind="Select"/>
> >>> <Command name="getCustomerAccount" SQL="SELECT accountNumber,
> >>> accountType, balance FROM accounts where accountNumber = ?"
> >>> kind="Select" />
> >>> ...
> >>> </Config>
> >>>
> >>>
> >>> Mapping between interface methods and DAS Commands
> >>> - If a DAS config file is provided, based on the SCDL definition,
> we
> >>> would look for "DAS command" based on the name of the getter
> >>> (e.ggetAllCustomers would map to getAllCustomers command)
> >>> - Otherwise, we would try to do a map directly to a
> stored procedure
> >>> - We could also have a way to force the mapping by using annotation
> >>> (e.g@Procedure on the method level)
> >>>
> >>> Mapping between method parameter and command parameter
> >>> - We would need to define a method for mapping the method
> >>> parameters to
> >>> the query paramters either based on position (e.g first method
> >>> parameter
> >>> maps to the first command paramter), or we would do some mapping by
> >>> name
> >>> (currently not available in Tuscany DAS)
> >>>
> >>> Note:
> >>> - A SCDL connection information would override the DAS Config file
> >>> connection information.
> >>>
> >>>
> >>> Benefits
> >>> - It's All about simplicity and easy of use
> >>> - This would allow a user to define a service without having to
> >>> explicitly having to code any Data Access related code.
> >>>
> >>>
> >>> Implementation approaches
> >>> - Utilizing DAS : This approach would start from the current
> >>> Tuscany DAS
> >>> implementation, where functionality would be already available, but
> >>> the
> >>> service implementation would be tied to SDO and RDB as this is what
> >>> DAS
> >>> supports today.
> >>>
> >>> - Start simple and grow : We could start simple, by having a simple
> >>> implementation based on JDBC and would return some simple
> >>> collection as a
> >>> return type (e.g List or a even a Recordset), this could give us a
> >>> quick
> >>> start to flush implementation details and get a proven design, and
> >>> this
> >>> could get evolved to use a DAS that would support multiple backends
> >>> (e.gRDB, XML, etc) and would create SDO as well as non-SDO types as a
> >>> command
> >>> result.
> >>>
> >>>
> >>> Toughts ?
> >>>
> >>> - Luciano
> >>>
> >>>
> >>>
> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
> >>>
> >>>>
> >>>> 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. Another thing we want to eventually explore is
> >>>> exposing
> >>>> a DAS as REST-oriented services. As we have seen from the parent
> >>>> thread
> >>>> there are almost too many possible approaches.
> >>>>
> >>>> My first thought is to model the DAS as a service and create a new
> >>>> implementation kind (implementation.rdbdas). The main reason has
> >>>> to do
> >>>> with the potential declarative aspect of DAS that Jeremy mentioned
> >>>> which
> >>>> is all about creating data access services declaratively. A new
> >>>> component type and a service that we build by hand would be a good
> >>>> step
> >>>> in this direction.
> >>>>
> >>>> We might want to expose a DAS service with an interface like this:
> >>>>
> >>>> public interface RDBDASService
> >>>> void applyChanges(DataObject graphRoot);
> >>>> DataObject execute(String commandName);
> >>>> DataObject executeSQL(String abitrarySQL);
> >>>> }
> >>>>
> >>>> The service would be initialized with an optional RDB DAS
> config file
> >>>> that defines connection properties, a set of commands, etc. So,
> >>>> different services implementing the same interface could be
> >>>> initialized
> >>>> from separate config files.
> >>>>
> >>>> Eventually, we might want to build services like this:
> >>>>
> >>>> public interface Customers_RDBDASService
> >>>> void applyChanges(DataObject graphRoot);
> >>>> DataObject getAllCustomersWithLastName (String lastName);
> >>>> DataObject getAll CustomersAndOrdersForID (int customerId);
> >>>> }
> >>>>
> >>>> But, for this to be very useful would probably require some code
> >>>> generation tooling.
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> --Kevin
> >>>>
> >>>>
> >>>> Luciano Resende wrote:
> >>>>
> >>>> > I'm starting to look in ways we could have a declarative DAS and
> >>>> will be
> >>>> > posting my progress into the list / wiki soon...
> >>>> >
> >>>> > - Luciano
> >>>> >
> >>>> > On 10/3/06, Jeremy Boynes <jb...@apache.org> 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 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.
> >>>> >>
> >>>> >> "Thanks for volunteering" :-)
> >>>> >> If someone wants to contribute these, I think we should welcome
> it
> >>>> >> like we would any other contribution.
> >>>> >>
> >>>> >> >> 3) to access data through an application service with
> >>>> declarative
> >>>> >> >> implementation by DAS
> >>>> >> > Yes, that's the value I see in DAS
> >>>> >>
> >>>> >> I think this is already on the DAS folks radar.
> >>>> >> --
> >>>> >> Jeremy
> >>>> >>
> >>>> >>
> >>>> --------------------------------------------------------------------
> -
> >>>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>> >>
> >>>> >>
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>> --------------------------------------------------------------------
> -
> >>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Kevin Williams <ke...@qwest.net>.
The real difference between the two approaches is that one is "Typed" or
static and the other is dynamic. I think both are needed but was
suggesting that we start with dynamic since it is the most flexible and
seems to be a reasonable stepping stone towards a static capability.
With either, the user does not need to know about traditional
persistence frameworks. With the dynamic approach, however, the user
does need to know about the dynamic SDO API.
So, with the static interface the user might write:
List customers = accountService.getAllCustomers();
String name = ((Customer)customers.get(0)).getName();
The equivalent dynamic API might be:
List customers = dasService.execute("getAllCustomers");
String name = ((DataObject)customers.get(0)).getString("name");
The first is probably a little easier for the application developer but
the second is much easier for the service developer. IMO, the dynamic
case is the best place to start and, again, we definitely will want
support for both.
Thanks.
--
Kevin
Jeremy Boynes wrote:
> I think this would be useful but it seems more like a traditional
> persistence API than what Luciano was suggesting. With this one a
> user needs to know about DataObject's, commands, SQL strings etc.
> just like they would if they were using raw JDBC or JPA.
>
> On the other hand, Luciano's proposal seemed more about expressing
> high-level CRUD operations as operations on a service interface:
>
>>> public interface AccountService {
>>>
>>> public List getAllCustomers();
>>> public Object getCustomerAccount(String accountNumber);
>>> }
>>
>
> which is all application level concepts rather than persistence level
> concepts. I'd actually go a little further and put that right into
> the service contract:
>
> public interface AccountService {
> List<Customer> getAllCustomers();
> Account getCustomerAccount(String accountNumber);
> }
>
> In a ideal world, if the user was able to accept standardized
> mappings (a la Rails et al) then no further configuration would be
> needed except to add this to the logical assembly:
>
> <component name="AccountStore">
> <implementation.das resource="MySQLDatabase"/>
> </component>
>
> With SCA's ability to translate service contracts, this should be
> callable from and deployable to any SCA runtime regardless of whether
> it was being accessed locally, by WS-*, by IIOP or running on a Java,
> C++ or PHP platform.
>
> The important thing here is that the client is isolated from how the
> DAS component is provided. We could have multiple declarative
> implementations, say one based on RDB-DAS and one that did stuff with
> XML databases like Xindice; alternatively, /without altering the
> client at all/ they could switch to a custom coded version written in
> Java, C++ or a store procedure language like PL/SQL.
>
> --
> Jeremy
>
>
> On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>
>> 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 code specific to a new
>> service. Instead, the service will be "instantiated" based on the
>> provided DAS config file. The service interface might look like this:
>>
>> public interface RDBDASService
>> DataObject execute(String commandName);
>> DataObject executeSQL(String abitrarySQL);
>> void applyChanges(DataObject graphRoot);
>> }
>>
>> So, depending on the config file used to instantiate the service,
>> this interface could be used to return Customers/Accounts or
>> Toasters. In fact, a lot could be achieved with no configuration at
>> all by restricting use to: DataObject executeSQL(String abitrarySQL);
>>
>> I expand a bit here: http://mail-archives.apache.org/mod_mbox/ws-
>> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
>>
>> Once this was working it should be straightforward to build more
>> strongly typed services and possible put together some generation
>> tooling. We could also start looking at support for a more RESTFul
>> interface.
>> --
>> Kevin
>>
>>
>>
>>
>> Luciano Resende wrote:
>>
>>> Recently, people have been starting to talk about better DAS
>>> integration
>>> with DAS, and below are some threads on the subject :
>>>
>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08833.html
>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08923.html
>>> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09715.html
>>>
>>> I'm new on the SCA side, so please help me make sure what I'm
>>> saying is not
>>> yet available on SCA today.
>>>
>>> Today, defining a service to work with a relational database, you
>>> will need
>>> to code the persistence side of the service where CRUD operations
>>> to the
>>> database will be done.
>>> I was thinking on a simpler, easier way, where coding the CRUD
>>> operations on
>>> the persistence layer would be avoided as much as possible.
>>> The idea would be to have a more "declarative DAS" when defining SCA
>>> Services, so you would either use some Annotations or SCDL to have the
>>> "declarative DAS" configuration inside it.
>>>
>>> I was thinking on something like....
>>>
>>> SCDL Definition would look something like this :
>>>
>>> <component name="AccountDataService">
>>> <interface.java
>>> class="bigbank.account.services.account.AccountService"/>
>>> <implementation.das="dasConfig.properties"
>>> connection="java:comp/env/jdbc/bigbank"/>
>>> </component>
>>>
>>> The AccountService Interface would look like this (missing any SCA
>>> annotations):
>>>
>>> public interface AccountService {
>>>
>>> public List getAllCustomers();
>>> public Object getCustomerAccount(String accountNumber);
>>> }
>>>
>>> The DAS config would look like this, and would have the definition
>>> for the
>>> "all companies" command.
>>>
>>> <Config ...>
>>> ...
>>> <ConnectionInfo dataSource="java:comp/env/jdbc/bigbank"/>
>>>
>>> <Command name="getAllCustomers" SQL="select * from CUSTOMERS"
>>> kind="Select"/>
>>> <Command name="getCustomerAccount" SQL="SELECT accountNumber,
>>> accountType, balance FROM accounts where accountNumber = ?"
>>> kind="Select" />
>>> ...
>>> </Config>
>>>
>>>
>>> Mapping between interface methods and DAS Commands
>>> - If a DAS config file is provided, based on the SCDL definition, we
>>> would look for "DAS command" based on the name of the getter
>>> (e.ggetAllCustomers would map to getAllCustomers command)
>>> - Otherwise, we would try to do a map directly to a stored procedure
>>> - We could also have a way to force the mapping by using annotation
>>> (e.g@Procedure on the method level)
>>>
>>> Mapping between method parameter and command parameter
>>> - We would need to define a method for mapping the method
>>> parameters to
>>> the query paramters either based on position (e.g first method
>>> parameter
>>> maps to the first command paramter), or we would do some mapping by
>>> name
>>> (currently not available in Tuscany DAS)
>>>
>>> Note:
>>> - A SCDL connection information would override the DAS Config file
>>> connection information.
>>>
>>>
>>> Benefits
>>> - It's All about simplicity and easy of use
>>> - This would allow a user to define a service without having to
>>> explicitly having to code any Data Access related code.
>>>
>>>
>>> Implementation approaches
>>> - Utilizing DAS : This approach would start from the current
>>> Tuscany DAS
>>> implementation, where functionality would be already available, but
>>> the
>>> service implementation would be tied to SDO and RDB as this is what
>>> DAS
>>> supports today.
>>>
>>> - Start simple and grow : We could start simple, by having a simple
>>> implementation based on JDBC and would return some simple
>>> collection as a
>>> return type (e.g List or a even a Recordset), this could give us a
>>> quick
>>> start to flush implementation details and get a proven design, and
>>> this
>>> could get evolved to use a DAS that would support multiple backends
>>> (e.gRDB, XML, etc) and would create SDO as well as non-SDO types as a
>>> command
>>> result.
>>>
>>>
>>> Toughts ?
>>>
>>> - Luciano
>>>
>>>
>>>
>>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
>>>
>>>>
>>>> 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. Another thing we want to eventually explore is
>>>> exposing
>>>> a DAS as REST-oriented services. As we have seen from the parent
>>>> thread
>>>> there are almost too many possible approaches.
>>>>
>>>> My first thought is to model the DAS as a service and create a new
>>>> implementation kind (implementation.rdbdas). The main reason has
>>>> to do
>>>> with the potential declarative aspect of DAS that Jeremy mentioned
>>>> which
>>>> is all about creating data access services declaratively. A new
>>>> component type and a service that we build by hand would be a good
>>>> step
>>>> in this direction.
>>>>
>>>> We might want to expose a DAS service with an interface like this:
>>>>
>>>> public interface RDBDASService
>>>> void applyChanges(DataObject graphRoot);
>>>> DataObject execute(String commandName);
>>>> DataObject executeSQL(String abitrarySQL);
>>>> }
>>>>
>>>> The service would be initialized with an optional RDB DAS config file
>>>> that defines connection properties, a set of commands, etc. So,
>>>> different services implementing the same interface could be
>>>> initialized
>>>> from separate config files.
>>>>
>>>> Eventually, we might want to build services like this:
>>>>
>>>> public interface Customers_RDBDASService
>>>> void applyChanges(DataObject graphRoot);
>>>> DataObject getAllCustomersWithLastName (String lastName);
>>>> DataObject getAll CustomersAndOrdersForID (int customerId);
>>>> }
>>>>
>>>> But, for this to be very useful would probably require some code
>>>> generation tooling.
>>>>
>>>> Thoughts?
>>>>
>>>> --Kevin
>>>>
>>>>
>>>> Luciano Resende wrote:
>>>>
>>>> > I'm starting to look in ways we could have a declarative DAS and
>>>> will be
>>>> > posting my progress into the list / wiki soon...
>>>> >
>>>> > - Luciano
>>>> >
>>>> > On 10/3/06, Jeremy Boynes <jb...@apache.org> 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 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.
>>>> >>
>>>> >> "Thanks for volunteering" :-)
>>>> >> If someone wants to contribute these, I think we should welcome it
>>>> >> like we would any other contribution.
>>>> >>
>>>> >> >> 3) to access data through an application service with
>>>> declarative
>>>> >> >> implementation by DAS
>>>> >> > Yes, that's the value I see in DAS
>>>> >>
>>>> >> I think this is already on the DAS folks radar.
>>>> >> --
>>>> >> Jeremy
>>>> >>
>>>> >>
>>>> -------------------------------------------------------------------- -
>>>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------- -
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Posted by Jeremy Boynes <jb...@apache.org>.
I think this would be useful but it seems more like a traditional
persistence API than what Luciano was suggesting. With this one a
user needs to know about DataObject's, commands, SQL strings etc.
just like they would if they were using raw JDBC or JPA.
On the other hand, Luciano's proposal seemed more about expressing
high-level CRUD operations as operations on a service interface:
>> public interface AccountService {
>>
>> public List getAllCustomers();
>> public Object getCustomerAccount(String accountNumber);
>> }
which is all application level concepts rather than persistence level
concepts. I'd actually go a little further and put that right into
the service contract:
public interface AccountService {
List<Customer> getAllCustomers();
Account getCustomerAccount(String accountNumber);
}
In a ideal world, if the user was able to accept standardized
mappings (a la Rails et al) then no further configuration would be
needed except to add this to the logical assembly:
<component name="AccountStore">
<implementation.das resource="MySQLDatabase"/>
</component>
With SCA's ability to translate service contracts, this should be
callable from and deployable to any SCA runtime regardless of whether
it was being accessed locally, by WS-*, by IIOP or running on a Java,
C++ or PHP platform.
The important thing here is that the client is isolated from how the
DAS component is provided. We could have multiple declarative
implementations, say one based on RDB-DAS and one that did stuff with
XML databases like Xindice; alternatively, /without altering the
client at all/ they could switch to a custom coded version written in
Java, C++ or a store procedure language like PL/SQL.
--
Jeremy
On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> 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 code specific to a new
> service. Instead, the service will be "instantiated" based on the
> provided DAS config file. The service interface might look like this:
>
> public interface RDBDASService
> DataObject execute(String commandName);
> DataObject executeSQL(String abitrarySQL);
> void applyChanges(DataObject graphRoot);
> }
>
> So, depending on the config file used to instantiate the service,
> this interface could be used to return Customers/Accounts or
> Toasters. In fact, a lot could be achieved with no configuration
> at all by restricting use to: DataObject executeSQL(String
> abitrarySQL);
>
> I expand a bit here: http://mail-archives.apache.org/mod_mbox/ws-
> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
>
> Once this was working it should be straightforward to build more
> strongly typed services and possible put together some generation
> tooling. We could also start looking at support for a more RESTFul
> interface.
> --
> Kevin
>
>
>
>
> Luciano Resende wrote:
>
>> Recently, people have been starting to talk about better DAS
>> integration
>> with DAS, and below are some threads on the subject :
>>
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08833.html
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08923.html
>> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09715.html
>>
>> I'm new on the SCA side, so please help me make sure what I'm
>> saying is not
>> yet available on SCA today.
>>
>> Today, defining a service to work with a relational database, you
>> will need
>> to code the persistence side of the service where CRUD operations
>> to the
>> database will be done.
>> I was thinking on a simpler, easier way, where coding the CRUD
>> operations on
>> the persistence layer would be avoided as much as possible.
>> The idea would be to have a more "declarative DAS" when defining SCA
>> Services, so you would either use some Annotations or SCDL to have
>> the
>> "declarative DAS" configuration inside it.
>>
>> I was thinking on something like....
>>
>> SCDL Definition would look something like this :
>>
>> <component name="AccountDataService">
>> <interface.java
>> class="bigbank.account.services.account.AccountService"/>
>> <implementation.das="dasConfig.properties"
>> connection="java:comp/env/jdbc/bigbank"/>
>> </component>
>>
>> The AccountService Interface would look like this (missing any SCA
>> annotations):
>>
>> public interface AccountService {
>>
>> public List getAllCustomers();
>> public Object getCustomerAccount(String accountNumber);
>> }
>>
>> The DAS config would look like this, and would have the definition
>> for the
>> "all companies" command.
>>
>> <Config ...>
>> ...
>> <ConnectionInfo dataSource="java:comp/env/jdbc/bigbank"/>
>>
>> <Command name="getAllCustomers" SQL="select * from CUSTOMERS"
>> kind="Select"/>
>> <Command name="getCustomerAccount" SQL="SELECT accountNumber,
>> accountType, balance FROM accounts where accountNumber = ?"
>> kind="Select" />
>> ...
>> </Config>
>>
>>
>> Mapping between interface methods and DAS Commands
>> - If a DAS config file is provided, based on the SCDL
>> definition, we
>> would look for "DAS command" based on the name of the getter
>> (e.ggetAllCustomers would map to getAllCustomers command)
>> - Otherwise, we would try to do a map directly to a stored
>> procedure
>> - We could also have a way to force the mapping by using annotation
>> (e.g@Procedure on the method level)
>>
>> Mapping between method parameter and command parameter
>> - We would need to define a method for mapping the method
>> parameters to
>> the query paramters either based on position (e.g first method
>> parameter
>> maps to the first command paramter), or we would do some mapping
>> by name
>> (currently not available in Tuscany DAS)
>>
>> Note:
>> - A SCDL connection information would override the DAS Config file
>> connection information.
>>
>>
>> Benefits
>> - It's All about simplicity and easy of use
>> - This would allow a user to define a service without having to
>> explicitly having to code any Data Access related code.
>>
>>
>> Implementation approaches
>> - Utilizing DAS : This approach would start from the current
>> Tuscany DAS
>> implementation, where functionality would be already available,
>> but the
>> service implementation would be tied to SDO and RDB as this is
>> what DAS
>> supports today.
>>
>> - Start simple and grow : We could start simple, by having a simple
>> implementation based on JDBC and would return some simple
>> collection as a
>> return type (e.g List or a even a Recordset), this could give us a
>> quick
>> start to flush implementation details and get a proven design, and
>> this
>> could get evolved to use a DAS that would support multiple backends
>> (e.gRDB, XML, etc) and would create SDO as well as non-SDO types as a
>> command
>> result.
>>
>>
>> Toughts ?
>>
>> - Luciano
>>
>>
>>
>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
>>
>>>
>>> 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. Another thing we want to eventually explore is
>>> exposing
>>> a DAS as REST-oriented services. As we have seen from the parent
>>> thread
>>> there are almost too many possible approaches.
>>>
>>> My first thought is to model the DAS as a service and create a new
>>> implementation kind (implementation.rdbdas). The main reason has
>>> to do
>>> with the potential declarative aspect of DAS that Jeremy
>>> mentioned which
>>> is all about creating data access services declaratively. A new
>>> component type and a service that we build by hand would be a
>>> good step
>>> in this direction.
>>>
>>> We might want to expose a DAS service with an interface like this:
>>>
>>> public interface RDBDASService
>>> void applyChanges(DataObject graphRoot);
>>> DataObject execute(String commandName);
>>> DataObject executeSQL(String abitrarySQL);
>>> }
>>>
>>> The service would be initialized with an optional RDB DAS config
>>> file
>>> that defines connection properties, a set of commands, etc. So,
>>> different services implementing the same interface could be
>>> initialized
>>> from separate config files.
>>>
>>> Eventually, we might want to build services like this:
>>>
>>> public interface Customers_RDBDASService
>>> void applyChanges(DataObject graphRoot);
>>> DataObject getAllCustomersWithLastName (String lastName);
>>> DataObject getAll CustomersAndOrdersForID (int customerId);
>>> }
>>>
>>> But, for this to be very useful would probably require some code
>>> generation tooling.
>>>
>>> Thoughts?
>>>
>>> --Kevin
>>>
>>>
>>> Luciano Resende wrote:
>>>
>>> > I'm starting to look in ways we could have a declarative DAS
>>> and will be
>>> > posting my progress into the list / wiki soon...
>>> >
>>> > - Luciano
>>> >
>>> > On 10/3/06, Jeremy Boynes <jb...@apache.org> 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 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.
>>> >>
>>> >> "Thanks for volunteering" :-)
>>> >> If someone wants to contribute these, I think we should
>>> welcome it
>>> >> like we would any other contribution.
>>> >>
>>> >> >> 3) to access data through an application service with
>>> declarative
>>> >> >> implementation by DAS
>>> >> > Yes, that's the value I see in DAS
>>> >>
>>> >> I think this is already on the DAS folks radar.
>>> >> --
>>> >> Jeremy
>>> >>
>>> >>
>>> --------------------------------------------------------------------
>>> -
>>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA, was Re:
Modeling persistence services, was Re: EJB3 (JPA) support
Posted by Kevin Williams <ke...@qwest.net>.
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 code specific to a new service. Instead, the service
will be "instantiated" based on the provided DAS config file. The
service interface might look like this:
public interface RDBDASService
DataObject execute(String commandName);
DataObject executeSQL(String abitrarySQL);
void applyChanges(DataObject graphRoot);
}
So, depending on the config file used to instantiate the service, this
interface could be used to return Customers/Accounts or Toasters. In
fact, a lot could be achieved with no configuration at all by
restricting use to: DataObject executeSQL(String abitrarySQL);
I expand a bit here:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
Once this was working it should be straightforward to build more
strongly typed services and possible put together some generation
tooling. We could also start looking at support for a more RESTFul
interface.
--
Kevin
Luciano Resende wrote:
> Recently, people have been starting to talk about better DAS integration
> with DAS, and below are some threads on the subject :
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08833.html
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08923.html
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09715.html
>
> I'm new on the SCA side, so please help me make sure what I'm saying
> is not
> yet available on SCA today.
>
> Today, defining a service to work with a relational database, you will
> need
> to code the persistence side of the service where CRUD operations to the
> database will be done.
> I was thinking on a simpler, easier way, where coding the CRUD
> operations on
> the persistence layer would be avoided as much as possible.
> The idea would be to have a more "declarative DAS" when defining SCA
> Services, so you would either use some Annotations or SCDL to have the
> "declarative DAS" configuration inside it.
>
> I was thinking on something like....
>
> SCDL Definition would look something like this :
>
> <component name="AccountDataService">
> <interface.java
> class="bigbank.account.services.account.AccountService"/>
> <implementation.das="dasConfig.properties"
> connection="java:comp/env/jdbc/bigbank"/>
> </component>
>
> The AccountService Interface would look like this (missing any SCA
> annotations):
>
> public interface AccountService {
>
> public List getAllCustomers();
> public Object getCustomerAccount(String accountNumber);
> }
>
> The DAS config would look like this, and would have the definition for
> the
> "all companies" command.
>
> <Config ...>
> ...
> <ConnectionInfo dataSource="java:comp/env/jdbc/bigbank"/>
>
> <Command name="getAllCustomers" SQL="select * from CUSTOMERS"
> kind="Select"/>
> <Command name="getCustomerAccount" SQL="SELECT accountNumber,
> accountType, balance FROM accounts where accountNumber = ?"
> kind="Select" />
> ...
> </Config>
>
>
> Mapping between interface methods and DAS Commands
> - If a DAS config file is provided, based on the SCDL definition, we
> would look for "DAS command" based on the name of the getter
> (e.ggetAllCustomers would map to getAllCustomers command)
> - Otherwise, we would try to do a map directly to a stored procedure
> - We could also have a way to force the mapping by using annotation
> (e.g@Procedure on the method level)
>
> Mapping between method parameter and command parameter
> - We would need to define a method for mapping the method parameters to
> the query paramters either based on position (e.g first method parameter
> maps to the first command paramter), or we would do some mapping by name
> (currently not available in Tuscany DAS)
>
> Note:
> - A SCDL connection information would override the DAS Config file
> connection information.
>
>
> Benefits
> - It's All about simplicity and easy of use
> - This would allow a user to define a service without having to
> explicitly having to code any Data Access related code.
>
>
> Implementation approaches
> - Utilizing DAS : This approach would start from the current Tuscany
> DAS
> implementation, where functionality would be already available, but the
> service implementation would be tied to SDO and RDB as this is what DAS
> supports today.
>
> - Start simple and grow : We could start simple, by having a simple
> implementation based on JDBC and would return some simple collection as a
> return type (e.g List or a even a Recordset), this could give us a quick
> start to flush implementation details and get a proven design, and this
> could get evolved to use a DAS that would support multiple backends
> (e.gRDB, XML, etc) and would create SDO as well as non-SDO types as a
> command
> result.
>
>
> Toughts ?
>
> - Luciano
>
>
>
> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
>
>>
>> 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. Another thing we want to eventually explore is exposing
>> a DAS as REST-oriented services. As we have seen from the parent thread
>> there are almost too many possible approaches.
>>
>> My first thought is to model the DAS as a service and create a new
>> implementation kind (implementation.rdbdas). The main reason has to do
>> with the potential declarative aspect of DAS that Jeremy mentioned which
>> is all about creating data access services declaratively. A new
>> component type and a service that we build by hand would be a good step
>> in this direction.
>>
>> We might want to expose a DAS service with an interface like this:
>>
>> public interface RDBDASService
>> void applyChanges(DataObject graphRoot);
>> DataObject execute(String commandName);
>> DataObject executeSQL(String abitrarySQL);
>> }
>>
>> The service would be initialized with an optional RDB DAS config file
>> that defines connection properties, a set of commands, etc. So,
>> different services implementing the same interface could be initialized
>> from separate config files.
>>
>> Eventually, we might want to build services like this:
>>
>> public interface Customers_RDBDASService
>> void applyChanges(DataObject graphRoot);
>> DataObject getAllCustomersWithLastName (String lastName);
>> DataObject getAll CustomersAndOrdersForID (int customerId);
>> }
>>
>> But, for this to be very useful would probably require some code
>> generation tooling.
>>
>> Thoughts?
>>
>> --Kevin
>>
>>
>> Luciano Resende wrote:
>>
>> > I'm starting to look in ways we could have a declarative DAS and
>> will be
>> > posting my progress into the list / wiki soon...
>> >
>> > - Luciano
>> >
>> > On 10/3/06, Jeremy Boynes <jb...@apache.org> 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 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.
>> >>
>> >> "Thanks for volunteering" :-)
>> >> If someone wants to contribute these, I think we should welcome it
>> >> like we would any other contribution.
>> >>
>> >> >> 3) to access data through an application service with declarative
>> >> >> implementation by DAS
>> >> > Yes, that's the value I see in DAS
>> >>
>> >> I think this is already on the DAS folks radar.
>> >> --
>> >> Jeremy
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org