Some thoughts after discussion with Marcin:
How do you think we should access data from a web service call?
We assumed that this question concerns what
kind of object should be returned by web service.
That would depend on what we want to do with
such returned object. If we want only a way for wrapping some query results -
simple value object would be enough, but if we want a client to use such object
including keeping a track of taken changes - service data object seems like a
good choice.
How should this be integrated into a Context Container?
Not sure of what kind of integration is
mentioned here… but what about treating a Context Container as complex/compound
service data object
Should we make the web service call every time we need the data or once
and then cache data?
That would depend on the kind of exposed web
service. In case of data not being changed often it doesn’t make sense to
have multiple web service calls returning the same data with overhead resulting
from data serialization/soap message creation/data deserialization etc. Such
calls could be trigged by some specific events informing that e.g. new team
member is added – thus update team member repository.
In case of web services returning data frequently
changed/updated e.g. events history – it makes no sense to cache it on
the client side.
How should be store the information for making the web service call?
We are not sure we understood that question –
please explain some more…
Should we treat a web service endpoint like a repository and use a
repository descriptor or is it a different object?
As a repository.
Can we automatically convert the web service call result into a SDO
object or does each web service require additional code to create the SDO
object?
What about creating sdo on the server side
and wrapping data graph by soap message?
Here is some simple example of using sdo
with web services (page 30): http://ftpna2.bea.com/pub/downloads/commonj/Commonj-SDO-Specification-v1.0.pdf
Edyta
These are the questions I was trying to answer with Content Adapters.
Is this a good way to integrate information from web service calls into
Context Container?
I just thought someone other than me might have an idea about how this
should work.
Glenn Everitt
-----Original Message-----
From: corona-dev-bounces@xxxxxxxxxxx
[mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Marcin Okraszewski
Sent: Monday, November 27, 2006 4:43 AM
To: Corona development
Subject: Re: [corona-dev] Content Adapters - first thoughts
Well, isn't it simply a repository which uses a web service call as an
access method? If it uses SDO for transferring objects it is just an
adapter implementation issue. If the service sends objects as SDO
serialized to XML, then it just makes it easier to implement the
adapter, if we are to use SDO interfaces for usage. Am I missing
something?
Marcin
Everitt, Glenn napisał(a):
> Content Adapters - first thoughts please review.
>
> Sometimes you need to look up information remotely through a web
> service. The Context Container can use the Collaboration Server
SOA
> support to access remote information through the use of Content
> Adapters. Content Adapters are similar to RepositoryAdapters.
However,
> Content Adapters typically only access a single object rather than
> allowing access to an entire repository of information.
>
> A Content Adapter acts as a /Data Mediator Service /providing an
SDO
> Data Graph object in response to a webservice call.
>
> Should we persist a Content Adapter as a repository-descriptor?
>
> If we persisted a Content Adapter as a repository-descriptor would
> look like this?
>
> <repository-descriptor
>
content-type="http://www.eclipse.org/corona/contentTypes/webservice"
>
> name="MySampleWebServiceContentAdapter"
>
uri="http://www.eclipse.org/corona/repository/CoronaHomePage">
>
> <description>Web site of Corona project</description>
>
> <repository-configurations default-configuration-name="
> MySampleWebServiceContentAdapterConfiguration">
>
> <repository-configuration name="
> MySampleWebServiceContentAdapterConfiguration ">
>
> <repository-connection-parameters
> access-type="http://www.eclipse.org/corona/accessTypes/webservice"
>
> name=" MySampleWebServiceContentAdapterParameters">
>
> <repository-connection-parameter name="endpoint"
>
value="http://www.eclipse.org/corona/MySampleWebService/getAdapterData"/>
>
> </repository-connection-parameters>
>
> </repository-configuration>
>
> </repository-configurations>
>
> </repository-descriptor>
>
> Content Adapter for Web Service holds:
>
> - Web Service endpoint to be called
>
> - A URI identifier for the SDO object returned
>
> Can we create an automatic mapping from Web Service WSDL
definition to
> SDO Data Graph we want the Content Adapter to return?
>
> - the WSDL describes the response information is this all we need
to
> map to SDO Data Graph
>
> - how should information returned from web service be presented
>
> The contents of this e-mail are intended for the named addressee
only.
> It contains information that may be confidential. Unless you are
the
> named addressee or an authorized designee, you may not copy or use
it,
> or disclose it to anyone else. If you received it in error please
> notify us immediately and then destroy it.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>corona-dev mailing list
>corona-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/corona-dev
>
>
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
_______________________________________________
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
_______________________________________________
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.