Hi ,
I am also following up another thread
http://www.mail-archive.com/[email protected]/
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/[email protected]/msg08833.html
> >> >>>
> http://www.mail-archive.com/[email protected]/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: tuscany-dev-
[EMAIL PROTECTED]
> >> >>>> >> For additional commands, e-mail:
> [EMAIL PROTECTED]
> >> >>>> >>
> >> >>>> >>
> >> >>>> >
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >>
--------------------------------------------------------------------
> >> -
> >> >>>> To unsubscribe, e-mail: tuscany-dev-
[EMAIL PROTECTED]
> >> >>>> For additional commands, e-mail: tuscany-dev-
[EMAIL PROTECTED]
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >>
>
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: tuscany-dev-
[EMAIL PROTECTED]
> >> >>
> >> >
> >> >
> >> >
>
---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: tuscany-dev-
[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]
