tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luciano Resende" <luckbr1...@gmail.com>
Subject Re: [DAS] DAS as web service
Date Thu, 13 Dec 2007 11:48:35 GMT
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://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
View raw message