Sure, maybe a good first step would be to agree on a "data" interface to be used.
On Dec 14, 2007 4:52 AM, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > 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] > > > > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]