On Wed, Oct 15, 2008 at 8:26 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> Hi Matthieu,
>
> How will you determine from a business process what the URIs, HTTP methods
> and representations for resources of that process are?
>
The URIs and methods for the processes are predefined so even if I don't
know about the process yet, I know what the URL and methods are going to be
like once I see the process (basically from its name and starting activity).
Depending on the process implementation, new resources can then be created
at runtime and their URIs, methods, ..., are defined by the process itself,
depending on the process constructs used.
>
> 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? On thing I forgot to mention is that sub-resources would
need to be removable as processes can get undeployed. Also would you have an
example of reloading a root resource class?
Thanks!
Matthieu
>
> Paul.
>
>
> On Oct 15, 2008, at 5:13 PM, Matthieu Riou wrote:
>
> Hi,
>>
>> I have a need to create resources dynamically instead of having predefined
>> static classes. The use case is I'm implementing a server where users can
>> deploy business processes. Those should be exposed using a RESTful web
>> service. But of course I don't know beforehand the resource address or even
>> how many resources I'm going to have.
>>
>> Is there an API in Jersey that I could use to handle this use case?
>>
>> Thanks,
>> Matthieu
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>