Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tuscany-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of amita.vadhavkar@gmail.com
 designates 72.14.202.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=oS3mHpRrbTtReknJkmJkSY7Z4FZcrECUuXCj4vEcCzH48N94dF6v2HfbwsfYZQbV6II32n20gIBp9PckSlTiBPClSQO7jV613qChzN1YZFJskYwYqrmHwoH9PiWlJpDxLJRoN+pbawNyDjfgzcxHhl9EiqqkzrZYi0RN7kxmlew=
Message-ID: <62dd6b650712140452h3d4c02f4v3664e21746283fa8@mail.gmail.com>
Date: Fri, 14 Dec 2007 18:22:06 +0530
From: "Amita Vadhavkar" <amita.vadhavkar@gmail.com>
To: tuscany-dev@ws.apache.org
Subject: Re: [DAS] DAS as web service
In-Reply-To: <5a75db780712130348l653dc843j783c11ebdeea9c37@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_780_1835701.1197636727018"
References: <62dd6b650711140504u5f273461k47adba43f42b8f6b@mail.gmail.com>
	 <62dd6b650712122358i58769535y5deeb62b9e447d3a@mail.gmail.com>
	 <5a75db780712130348l653dc843j783c11ebdeea9c37@mail.gmail.com>

------=_Part_780_1835701.1197636727018
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks Luciano, I will give a try to implementation-data-sdo.
-Amita

On Dec 13, 2007 5:18 PM, Luciano Resende <luckbr1975@gmail.com> wrote:

> Looks like you are starting to face some of the same issues I had in
> the past... I can see two issues here : Passing Data Graphs and Change
> Summary, and ensuring the client (e.g a web 2.0 application) would be
> SDO Enabled to handle this data representation and maintain it.
>
> Maybe a better alternative would be to leverage SCA to expose Data
> Service CRUD + Query interface utilizing SCA bindigns. We could
> leverage some of the work we have been doing on implementation.data
> for this and define a interface for SDO or for regular Pojos and use
> that interface as the main interface for the Data components.This
> would also give us some more flexibility in terms of what
> communication protocols would be supported (e.g ws, rmi, jsonrpc, etc)
>
> Well, these are only some initial thoughts, and I'd appreciate input
> from others on the community.
>
>
> On Dec 12, 2007 11:58 PM, Amita Vadhavkar <amita.vadhavkar@gmail.com>
> wrote:
> > I could see that static and dynamic DOs (using xsd:anyType) can be
> passed
> > using web service, but when it comes to DataGraph containing
> ChangeSummary
> > is there a way to pass it as parameter?
> >
> > -Amita
> >
> >
> > On Nov 14, 2007 6:34 PM, Amita Vadhavkar <amita.vadhavkar@gmail.com>
> wrote:
> >
> > > There is an old thread -
> > > http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01951.html
> > > I am just trying to continue the discussion here to come up with
> > > requirement, use cases and a basic implementation.
> > >
> > > Standalone DAS can be used by client by having the required jar in
> > > classpath. By exposing DAS as WebService
> > > it will be able to
> > > - have remote multiple clients using same DAS Web Service.
> > >
> > > As first attempt - can try to have a basic cycle -
> > >  ...1) initDAS (), 2) create Command, 3) exec Command(), 4) let
> > > client modify DO, 5) applyChange
> > > with having the DAS web service tied to one database access.
> > >
> > > Later based on use cases, requirements, can make things more flexible.
> > >
> > > It may be needed to have session/conversation management - as the
> > > above steps make meaning in the same session
> > >
> > > For this implementation.das type component can have a wsdl binding.
> > > das config.xsd as well as other static model xsds (like company.xsd..)
> > > can be refed in the wsdl.
> > >
> > > 1> initDAS - based on impl.das component's <ConnectionInfo> can help
> > > in getting the DB Connection to DAS runtime.
> > > Also, static model xsds can be made known to DAS at this time.
> > >
> > > 2> as <Command> structure is known in config.xsd - it can be used as
> > > return type of response of createCommand()
> > >
> > > 3> command.executeQuery() in DAS returns a DO. It may need to be a
> > > particular DO Type array like Company[].
> > >
> > > 4> There can be problems in Dynamic DAS approach(i.e. DAS without
> > > model xsds), as the model is not know before runtime,
> > > wsdl can not know the complex type to expect as return of
> > > executeCommand(). There can be workarounds like form model
> > > based on DB SChema beforehand and use it. But what is the usability of
> > > this? i.e. Dynamic DAS as Web Service?
> > >
> > > 5> like in executeQuery() return type is a known type DO, in
> > > applyChanges(DO) a known type can be passed to DAS for persisting in
> > > DB.
> > >
> > > All the above will need some wrapping around the existing APIs to
> > > support specific model types passing back and forth.
> > >
> > > Please share your thoughts.
> > >
> > > Regards,
> > > Amita
> > >
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

------=_Part_780_1835701.1197636727018--