That's an interesting one. I've had this idea of a web service based
on DataMap for some time, but I didn't want to develop it in the
vacuum, so I waited till I have some real use cases for it. Now I do
have a few, so I posted the original raw idea on Wiki. I still have a
few concerns though, related to the overall design and specifically
Cayenne implementation:
* Limits of XML format customization. We can customize tags and
attributes to a point, but the structure and data of the resulting XML
should still somewhat match a mapped object graph. If the requirement
is to generate some predefined XML format (e.g. RSS, etc), it will
still be much easier to use some template-based web technology with a
Java class between the template and the object graph (ala Tapestry/
WebObjects or even JSP). The template will ensure the right XML
structure, and a Java class would calculate the derived values...
I.e. this web service will be an overkill for any format that is not a
1..1 mapping to the graph structure.
* Too big of a rewrite for the existing XMLEncoder. For one thing, it
is DOM based, so it can't be used in a high-volume environment. Also
it should provide facilities for easy manual XML construction. So I
guess I'll be looking to do something of a cross-over between Cayenne
XMLEncoder and XStream...
Considering the above, I am still uncommitted about the
implementation, but I thought it will be good to document the idea.
Now regarding your other ideas...
I was viewing this service as the opposite to ROP. ROP is a protocol
to access 100% of a Cayenne DataChannel functionality, with support
for explicit queries, relationship faulting, paginated lists, multi-
object updates, etc. For all its power it has two major limitations:
(1) you need a special client to work with it (maybe we should revisit
2006 ROP WSDL project, that was intended to help arbitrary clients to
make sense of an ROP server); (2) there is no built-in access control.
The new web service was intended to be easily accessible (hence
RESTful), and very restrictive by default (hence the idea to limit it
to read-only operations, and only to the named, i.e. explicitly
mapped, queries). I like the entity access/update/insert ideas, as
they still keep it on the RESTful side. Still if we go this way, we
need to think through the security part. Maybe take DWR lib approach
to declarative security:
http://getahead.org/dwr/server/dwrxml
(i.e. things are disabled by default, and you need to allow them
explicitly).
Andrus
On Apr 16, 2008, at 11:09 PM, Tore Halset wrote:
> Hello.
>
> Interesting subject. I am working on GIS services, and there have
> been some good discussion lately around RESTful feature services.
>
> Some ideas:
> * Fetching a single entity could be done without query parameters.
> Ala. http://localhost/myapp/cayennexml/entity/Person/1 for person
> with id 1.
> * Updating a person object could be done by POST to the same url.
> * Creating a person object could be done by PUT to something like http://localhost/myapp/cayennexml/entity/Person/
> * Perhaps query for a single entity could be done in the entities
> namespace? ala http://localhost/myapp/cayennexml/entity/Person?q=mypersonquery&name=Tore
>
> Hope I am not disturbing.
>
> Regards,
> - Tore.
>
> On Apr 15, 2008, at 18:31, confluenc..pache.org wrote:
>> Page Edited : CAY : RESTful Cayenne XML Service
>> RESTful Cayenne XML Service has been edited by Andrus Adamchik (Apr
>> 15, 2008).
>>
>> (View changes)
>>
>> Content:
>> The idea is to build a service that generates XML for persistent
>> data based on some criteria, passed as a URL with parameters. The
>> service would use Cayenne to run the queries and XML generation
>> process would leverage DataMap information as much as possible. The
>> service should allow arbitrary customization of the generated XML
>> format. The service should allow to run user code at all points of
>> the request lifecycle, e.g. to implement security, filter the
>> results, customize XML, etc. At the same time, the service should
>> be usable out of the box with no other configuration except for the
>> "cayenne.xml" and friends.
>>
>> Addressing The Queries
>> The service is RESTful in that each request is uniquely identified
>> by the URL parameters. E.g.:
>>
>> http://localhost/myapp/cayennexml?q=myquery&p1=a&p2=b
>>
>> "q" is a reserved parameter corresponding to the mapped query name.
>> Other parameters are treated as named parameters that should be
>> passed to the query. (TODO: type conversion)
>>
>> XML Serialization
>> Default XML format will be auto-generated from Cayenne mapping and
>> can be overridden by the user (e.g. certain tags can be renamed,
>> excluded, etc.). Cayenne DataObject-to-XML generator will be used,
>> and users would optionally specify a config file overriding the
>> defaults for XML generation.
>>
>> Including Relationships in XML
>> Service callers can not specify which relationships to include, as
>> this would result in a security hole. Instead the default behavior
>> is to look at the query prefetches to see what parts of object
>> graph should be included in the output XML. (TODO: in the future we
>> may allow specifying included relationships separately from the
>> query prefetches).
>>
>> Interceptors
>> The service would allow registering a chain of interceptors that
>> would allow implementing custom processing logic at all points of
>> the invocation lifecycle. E.g.:
>>
>> public interface XMLServiceInterceptor {
>>
>> void onRequest(XMLServiceChain chain, XMLEncoder out,
>> ObjectContext context, String queryName, Map<String, String>
>> parameters);
>> }
>> Other Features
>> • Pagination. I.e. the ability to encode page size and page # in
>> the URL
>>
>>
>> Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07,
>> 2006) - Bug/feature request
>>
>> Unsubscribe or edit your notifications preferences
>
>
This archive was generated by hypermail 2.0.0 : Thu Apr 17 2008 - 07:06:39 EDT