Luciano Resende wrote:
> Comments in-line...
>
> On 10/25/06, Jim Marino <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>>
>> >> >>> 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]
>> >> >>> > >> >>
>> >> >>> > >> >> 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.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 <[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: tuscany-dev-
>> >> [EMAIL PROTECTED]
>> >> >>> > >> >> For additional commands, e-mail: tuscany-dev-
>> >> >>> [EMAIL PROTECTED]
>> >> >>> > >> >>
>> >> >>> > >> >
>> >> >>> > >> >
>> >> >>> > >> >
>> >> >>> >
>> >> >>>
>> >>
---------------------------------------------------------------------
>> >> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
>> >> [EMAIL PROTECTED]
>> >> >>> > >> > For additional commands, e-mail: tuscany-dev-
>> >> [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:
[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]
