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