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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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/[EMAIL PROTECTED] %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
> >> >>> ([EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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: [EMAIL PROTECTED]
> >> >>>> >> For additional commands, e-mail:
> [EMAIL PROTECTED]
> >> >>>> >>
> >> >>>> >>
> >> >>>> >
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> --------------------------------------------------------------------
> >> -
> >> >>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >>
> >> >
> >> >
> >> >
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
