Re: [CONF] Apache Cayenne: RESTful Cayenne XML Service (page edited)

[Tore Halset <ha...@pvv.ntnu.no>]

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, confluence@apache.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

Re: [CONF] Apache Cayenne: RESTful Cayenne XML Service (page edited)

[Andrus Adamchik <an...@objectstyle.org>]

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, confluence@apache.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
>
>