[Top] [All Lists]

Re: OPES support for serv(e)lets?

2001-09-28 02:59:31

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.



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.


Andrew Walker
Thundercrack Ltd.
17 Rathbone Street
London, W1T 1ND
Phone:  +44 020 7631 1000
EMail:   andrew(_dot_)walker(_at_)thundercrack(_dot_)com

<Prev in Thread] Current Thread [Next in Thread>