Media Engine Interface

Introduction

After a meeting on the subject we've decided on some funcionality the media engine interface should provide to the SRW. We've thought about exposing this functionality with some sort of web service interface as to allow the media engine to be used by any web service savvy applications. Kinda sparse and vuage at the moment but at this stage of the project that shouldnt be too much of a shock ;)

Key Methods

query(content, algorithm, [imageset])

A query passed to the media engine will comprise of content to search against, an algorithm id for the FVS and an optional image set. The content is an array of images to allow for algorithms that require multiple inputs, for most algorithms this would be a single image. Images passed as content can either be an ID of an image already inside the system or a URL to an image. The image set is optional but most likely provided every time as otherwise the entire systems image set will have to be searched which could be wasteful.

query(query, weight)

This form of query allows for the media engine support for sets of queries applied in combination. The query field will be a tree of queries. This tree (similar to the query tree idea found in sculpteur) will provide support for "AND" and "OR" query combinations. This bit we're still working on i think becuase the "weight" field seems a bit out of place here?

list_algorithms()

This will provide a list of algorithms available for use in queries

upload_content(content)

Upload large images and query content via a web service. Provide a URL ready for use in a query

generate_thumbnail()

Possibly under a set of general utility functions the webserivce will provide?

Web Service Use

The idea behind the web service is that the SRW will have an access point to the system, but to make this useful it might be prudent to make this webservice the entry point for the administration portion of the media engine. This will guarantee consistancy of system access and addition

I've spent a bit slapping together a few web service, just to get to grips with how they work. I thought i'd post my progress so you guys can see what i had to do to get them working in a way which could resemble our final interface.

webservice flavours

Right, firstly the 2 flavours. Webservices with axis can be RPC or document style. The "behind the scenes" difference illudes me by Adrian insists that document style is shibby cus its datastructures are defined by XSD documents which any platform can deal with however they want, where as RPC releis on same objects either side attaching the service to java....whatever :)....they are however ubstantially different in the way you force axis to use them

RPC style

The guide[1] i used to get axis working RPC style . Pretty simple process, basically copy your java files into axis and it does the work for you. Thing with doing it this way is that apparently its less portable to other languages, poor object description or something which is provided by document style.

Document style

the guide[2] i used for document style is pretty thurough. It skips some general XSD[3] and WSDL[4] technique but that wasnt hard to learn from the W3C[5]. This method basically involves getting access to work useing castor. Castor using for serialising and deserialising java objects into and out of XML documents. Castor can also be used to generate java classes directly from a well defined XSD document. The first step in document style is subsequently to define your XSD document. After some fiddleing i figured out how to write these properly but they are a bit strange. You just have to be careful as to which variables you define as elements and which you define as complex-types, unfortunetly the difference still eludes me but it wont work if you get it wrong ;)

The next step is to write a WSDL file for the classes you defined in your XSD. The major parts of the WSDL file are : - Telling the webservice about the XSD file generating your classes - Telling the webservice a little bit about the methods its gonna expose (its inputs and outputs as defined in the xsd) - Finally exposing the service itself in ports.

I'd get a load of examples off the tutorial and w3 to make one properly as WSDL is a bit cryptic

WSDL2java should then be used to generate axis stubs to the castor classes defined by the XSD file. When this is done you have to actually generate java classes from the XSD, this is done with castor's SourceGenerator. The process generates basically goes along the lines of "Expose a bunch of classes with WSDL2Java which were created using a comon XSD by castor"....logical but tricky, you have to go through the main generated stubs (XXXXSOAPBindingStub) as well as deploy.wsdd to a) make sure everything is using castor and b) everything agrees on the name of variables (for some reason castor adds the odd _ when they arent needed)

the guide defines some things to look out for but it isnt exhaustive, this bit is quite fiddly basically ;)

When you've got this far, and everything compiles, and deploys you should be ready to use your webservice, and after goin through all this hassle its a service which is apparently portable...woo :)

but yeh its a right bitch to get it workin like this, i recommend we just do some RMI and get it out the way :D