ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tammo van Lessen <tvanles...@gmail.com>
Subject Re: Adding more functionality to Management API
Date Mon, 14 Jul 2008 08:54:10 GMT
Assaf Arkin wrote:
> On Sun, Jul 13, 2008 at 3:52 AM, Tammo van Lessen <tvanlessen@gmail.com>
> wrote:
>> +1 for both approaches. I think in the medium-term we need an
>> authorization model for management purposes, so we could let
>> administrators decide who should be able to retrieve the full bpel and
>> who is restricted to view only abstract processes. The problem with
>> abstract processes is that someone has to define them in addition to
>> the executable model... Not really an Ode problem but a tooling
>> problem...
> There are two distinct use cases here.
> One use case is accessing public metadata about the service. ?wsdl emerged
> as a convention for that, and we can imagine additional conventions along
> the same lines: ?bpel (for the abstract), ?policy, ?english. (Or starting
> all over and picking a RESTful model that's easier to use and navigate)
> Second use case is management. Given that I can access running instances and
> see their data, I should also be able to get the process definition,
> deployment descriptor, JBI zips, and whatever else I'm managing.
> Those are two separate use cases. And we're not going to run into a URL
> shortage any time soon, so there's no point in trying to shoehorn both use
> cases into a limited set of URLs.
> Management tools should access the WSDL/BPEL from their API, which is access
> controlled. Other tools should access the public metadata, which is stripped
> down to "that which is publicly viewable".

I never said that this is one use case nor that both artifacts should be 
available via the same URI. I'm just saying that abstract definitions of 
BPEL processes cannot be derived fully automatically which means that 
people have to model the abstract metadata (i.e. the behavioral 
interface) in addition to the executable model. And this is currently 
not supported by any BPEL modelling tool I know (except for our own 
research stuff, but thats modelling BPEL light and is not ready yet). In 
general I believe that there can be multiple abstract variants for the 
same executable process model, i.e. one for the buyer, hiding the 
information about the seller's interface and one for the seller, hiding 
the behaviour of the buyer. An Ode-wide authorization model can help 
support such scenarios (devlivering public abstract bpels, restricted 
abstract bpels as well as the executable, no matter which API tries to 
access them).


View raw message