On Tuesday 25 September 2001 4:38 pm, Menon, Rama R wrote:
Hi Patrik,
I believe "OPES box" should support a flexible set of APIs to allow the
kind of thing that you suggested - running 3rd part applications/services
on a common platform. That in fact is the strength of the open platform -
to allow a variety of services to be run locally or remotely.
- Rama
I agree that a flexible set of APIs should be made available. The mechanism
of communication between the OPES server and the service is dictated by the
action URI scheme. Current suggestions are icap, soap, and proxylet. This
could be extended to include servlet fairly easily.
As it stands at the moment if you want to use an unsupported API you would
have to use a vectoring protocol (ICAP/SOAP) to reach your service, then
write the mapping between messages and API yourself.
I've a simple server application executing on a web server. The application
delivers images to consumers over HTTP. The images are water marked by the
application before delivered to the consumer. The application performs the
water marking (generation of code and marking) process per request.
Thanx,
/Patrik
This should be easily possible, however you would probably have to modify the
code to the servlet slightly to change the way it accesses the original
images. If you wanted to supply the application as a cross network service
you couldnt supply the images as resources within the deployable
application. There would need to be an authenticated path to expose the
images to the service.
The assumption with the proxylet API that I provided was that the images
would be available over HTTP within the content network with access
restricted to authenticated OPES nodes. If you were in your own server
cluster you would probably be using a filesystem or a database connection to
access your images.
In terms of the specific API that is exposed, it should be possible to define
a meta data bound service API. We already need to define attributes of the
messages that IRML can inspect and precisely what data the attributes relate
to, so it should be fairly straight forward to reuse this work as part of a
definition language for a generic service entry point.
--
Regards,
Andrew Walker
Thundercrack Ltd.
17 Rathbone Street
London, W1T 1ND
UK
Phone: +44 020 7631 1000
EMail: andrew(_dot_)walker(_at_)thundercrack(_dot_)com
URI: http://www.thundercrack.com