You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Amita Vadhavkar <am...@gmail.com> on 2007/11/14 14:04:13 UTC
[DAS] DAS as web service
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] DAS as web service
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Amita Vadhavkar wrote:
> I am checking impl-data-pojo from the sandbox and also can see the generic
> org.apache.tuscany.sca.implementation.data.collection.Collection from
> impl-data-api.
> I guess this interface is generic and can be used as the starting point for
> any sample
> implementations like what is there in impl-data-pojo. Just one question, why
> do we need
> to copy Collection interface in
> org.apache.tuscany.sca.implementation.openjpa.collection?
>
+1 to use the Collection interface from implementation-data-api, hoping
that we keep it as slim as it currently is.
[snip]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] DAS as web service
Posted by Amita Vadhavkar <am...@gmail.com>.
I am checking impl-data-pojo from the sandbox and also can see the generic
org.apache.tuscany.sca.implementation.data.collection.Collection from
impl-data-api.
I guess this interface is generic and can be used as the starting point for
any sample
implementations like what is there in impl-data-pojo. Just one question, why
do we need
to copy Collection interface in
org.apache.tuscany.sca.implementation.openjpa.collection?
>From the below from Collection interface -
Map<K, D> getAll();
Map<K, D> query(String queryString);
K post(D item);
D get(K key) throws NotFoundException;
void put(K key, D item) throws NotFoundException;
void delete(K key) throws NotFoundException;
getAll(), query(), get(), delete() will have a straight implementation using
sdo+das.
For post() - it can be forming complete INSERT using the input D - i.e.
property->column mapping
and grabbing all values from D.
For put(i.e. update), is a place in DAS, where it uses Change Summary
effectively. Here D will
have the changes on the top of the result obtained by some get(), so will be
DataGraph having ChangeSummary.
I am right now trying to get the get() working and will put the working code
in my sandbox.
Please give suggestions, comments on this initial approach and anything
else.
Regards,
Amita
On Dec 14, 2007 7:01 PM, Luciano Resende <lu...@gmail.com> wrote:
> 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 <am...@gmail.com>
> wrote:
> > Thanks Luciano, I will give a try to implementation-data-sdo.
> > -Amita
> >
> >
> > On Dec 13, 2007 5:18 PM, Luciano Resende <lu...@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 <am...@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 <am...@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://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
> > >
> > >
> >
>
>
>
> --
> 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
>
>
Re: [DAS] DAS as web service
Posted by Luciano Resende <lu...@gmail.com>.
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 <am...@gmail.com> wrote:
> Thanks Luciano, I will give a try to implementation-data-sdo.
> -Amita
>
>
> On Dec 13, 2007 5:18 PM, Luciano Resende <lu...@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 <am...@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 <am...@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
> >
> >
>
--
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
Re: [DAS] DAS as web service
Posted by Amita Vadhavkar <am...@gmail.com>.
Thanks Luciano, I will give a try to implementation-data-sdo.
-Amita
On Dec 13, 2007 5:18 PM, Luciano Resende <lu...@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 <am...@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 <am...@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
>
>
Re: [DAS] DAS as web service
Posted by Luciano Resende <lu...@gmail.com>.
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 <am...@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 <am...@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
Re: [DAS] DAS as web service
Posted by Amita Vadhavkar <am...@gmail.com>.
Further down the road, I tried to insource datagraph.xsd in my .wsdl
definition
like - have xmlns:sdo="commonj.sdo" in the definition and import as below -
<xsd:import namespace="commonj.sdo" schemaLocation="datagraph.xsd"/>
and the out param of my web service as -
<element name="executeQueryResponse">
<complexType>
<sequence>
<element name="executeQueryReturn" type="sdo:datagraph" />
</sequence>
</complexType>
</element>
and have web service like -
public commonj.sdo.DataGraph executeQuery(DASWrapperImpl dasRef, String
commandName);
But got -
Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException:
org.apache.tuscany.sca.databinding.TransformationException:
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2 counts of
IllegalAnnotationExceptions
commonj.sdo.DataGraph is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataGraph
commonj.sdo.DataGraph does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataGraph
------------------------------------------------------------------------------------
With same wsdl (i.e. import datagraph.xsd) and return type as sdo:datagraph
, but changing web service method to return
public org.apache.tuscany.sdo.impl.DataGraphImpl executeQuery(DASWrapperImpl
dasRef, String commandName);
With this I get -
Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException:
org.apache.tuscany.sca.databinding.TransformationException:
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 12 counts of
IllegalAnnotationExceptions
commonj.sdo.ChangeSummary is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.ChangeSummary
at public commonj.sdo.ChangeSummary
org.apache.tuscany.sdo.impl.DataGraphImpl.getEChangeSummary()
at org.apache.tuscany.sdo.impl.DataGraphImpl
commonj.sdo.ChangeSummary does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.ChangeSummary
at public commonj.sdo.ChangeSummary
org.apache.tuscany.sdo.impl.DataGraphImpl.getEChangeSummary()
at org.apache.tuscany.sdo.impl.DataGraphImpl
org.eclipse.emf.ecore.EObject is an interface, and JAXB can't handle
interfaces.
So basically WebService is now happy about DataGraphImpl, but complains for
next place where it sees DataGraphImpl is returning
an interface viz. ChangeSummary.
------------------------------------------------------------------------------------
Is there any way of somehow custom binding DataGraph having ChangeSummary in
WebService to effectively use it
as a out param of a web service? Appreciate any suggestions.
Regards,
Amita
On Dec 13, 2007 1:28 PM, Amita Vadhavkar <am...@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 <am...@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
> >
>
>
Re: [DAS] DAS as web service
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <am...@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
>