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 Thu, 13 Dec 2007 07:58:25 GMT
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?


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

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