On Oct 16, 2008, at 4:59 PM, Matthieu Riou wrote:
>
>
>>
>> One way this can be done is for the business processes to provide
>> resource classes themselves are returned by a sub-resource locator
>> of a root resource (such classes are analyzed at runtime). It is
>> also possible to dynamically reload root resource classes.
>>
>> If there is a common pattern to all business process you can write
>> general resource classes with careful use of URI templates e.g.
>> @Path("{id}"}
>>
>> I think I can work with the assumption of having a process engine
>> level root resource, processes being sub-resources and process
>> execution related resource being sub-sub-resources. Only the second
>> and third level resources would need to be dynamic (we don't
>> instantiate several engines). Does that sound possible?
>
> I think something is possible here, for example the sub-resource
> locator of the engine could do:
>
> @Path("{process}")
> public Object getProcess(@PathParam("process") String process) {
> Object o = ProcessEngine.lookup(process);
> if (o == null) throw NotFoundException();
> return o;
> }
>
> Yep, that works. I got a small prototype working yesterday.
>
Great.
>
>
>> On thing I forgot to mention is that sub-resources would need to be
>> removable as processes can get undeployed.
>
> This is an area that requires some work. There needs to be a way to
> say "please remove all information about and references to these
> components that you may know about)". I can add support for that.
> But it may work for sub-resources since it is the application that
> decides, the issue is Jersey will retain references to the sub-
> resource classes, which may not be good.
>
> At least in my case I would only need to remove sub-resources and I
> would know which ones to remove. So I wouldn't use something like
> sub-resource automatic deletion or anything fancy.
>
OK. For now the brute force reload should work for you (for removal,
addition will work automatically if using sub resources), but you and
Guilhem really require something better, so i will look at what can be
done next week to improve the notification.
>
> Are the class definitions and/or implementations for processes
> likely to change over redeployment?
>
> The class definitions shouldn't, They'll have to be dynamic enough
> to handle changes in the process. But the resources under which
> those classes are published are going to change. New ones could be
> created, old ones removed.
>
OK.
> By the way just to clarify, what I'm working on is RESTful support
> for BPEL processes in Apache ODE (http://ode.apache.org). We have a
> small spec to extend BPEL with REST primitives (http://ode.apache.org/restful-bpel-part-ii.html
> ), replacing the dependencies to WSDL and adding some REST-specific
> semantics
>
Interesting.
Paul.