tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amita Vadhavkar" <amita.vadhav...@gmail.com>
Subject Re: [DAS] DAS as web service
Date Fri, 14 Dec 2007 12:52:06 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message