[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [corona-dev] Content Adapters - first thoughts
|
From my perspective then it is simply "yet another repository" :) I
believe you cannot do it in any generic way unless you use semantic web
services, but it wouldn't be easy to implement any way.
Lets get to customers example. The content-type for this repository
would be "customers". Then, within the repository definition, you would
have to have a connection configuration with access-type something like
"customers web-service, format of CMS from company X". The connection
parameters wouldn't be anything generic, but rather one that is exactly
defined for this particular access-type. Then, how it is stored,
invoked, etc, is up to repository adapter. I think we can't do a generic
WS repository adapter, because even though you have the WSDL, the
adapter wouldn't understand semantic of operation, parameters, etc. I
think you have to make a different repository adapter for each
particular format of WS call. The same way as you have with team member
XML - if you want to change the format of XML, you need to have
different access-type for this and different adapter.
But of course all repository adapters for a given content-type,
"customers" in this case, would need to return objects that implement
the same interface. I believe this is our base assumption here. The
interface might be SDO as well.
Then, when you have a common interface for all objects of a given
content-type ("customers"), then you can have a single viewer,
regardless it comes from WS call in format A, or in format B, or from
JDBC or XML file. Obviously you might have a specialized viewer for "WS
call in format A", because you know it provides some extra information,
which you want to show. You can do it then in two ways - either the
"generic" viewer checks if returned objects are of some extended type,
or you provide your own viewer that not only matches the content-type,
but also the access-type for this particular WS format.
So, from my perspective, how the WS endpoint is described it is up to
repository adapter. If responses should be cached - it is up to
repository adapter. If it uses SDO to transfer objects - it is up to
repository adapter. Of course if we use SDO in Corona, then it is easier
to write adapter which uses SDO to transfer objects.
Marcin
Everitt, Glenn napisał(a):
No, I want a way to define a web service endpoint that workgroup users can cause to be called on demand to provide information to them.
I'm thinking about the case there is an existing web service that returns information about something like a customer. I need a place to save the web service endpoint definition. I need a way to pass parameters into the web service call. I need a place to keep the web service call results. Finally, I need a way to pass this customer information back to workgroup users.
My next thought was if the information was put into and SDO graph then we could use a generic SDO graph viewer to see the information.
I talked with Joel about this and pointed out that the SDO view probably would not present the data in a very useful way. He suggested it would probably make more sense to support using an update site to add a plugin to make the web service call and do the rendering of returned data. So, maybe the ContentAdapter is the plugin downloaded from the update site. The ContentAdapter plugin calls the web service and renders the results into a view.
Glenn
-----Original Message-----
From: corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Marcin Okraszewski
Sent: Tuesday, November 28, 2006 5:18 AM
To: Corona development
Subject: Re: [corona-dev] Content Adapters - first thoughts
So, do you think to automatically expose WS for each repository? Then
each repository would always had a corresponding web service? And do it
in generic way?
Marcin
Everitt, Glenn napisał(a):
How do you think we should access data from a web service call? How should this be integrated into a Context Container? Should we make the web service call every time we need the data or once and then cache data? How should be store the information for making the web service call? Should we treat a web service endpoint like a repository and use a repository descriptor or is it a different object? 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?
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.
_______________________________________________
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.
