Thanks Luciano, I will give a try to implementation-data-sdo. -Amita On Dec 13, 2007 5:18 PM, Luciano Resende <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > wrote: > > > > > There is an old thread - > > > http://www.mail-archive.com/[EMAIL PROTECTED]/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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
