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, [EMAIL PROTECTED] 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
