ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Adding more functionality to Management API
Date Mon, 14 Jul 2008 15:32:30 GMT
On Mon, Jul 14, 2008 at 1:54 AM, Tammo van Lessen <tvanlessen@gmail.com>

> 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).

Sorry, then. I didn't understand what you were referring to.

There could be multiple abstracts, and so each endpoint would return a
different one, specific to that partner. If I'm getting the ?bpel for the
buyer, it would contain the abstract visible to the buyer, much like the
?wsdl would only contain the operations visible to the buyer. These are
modeled as different port types and partner types for a reason.

So what's available to retrieval is decided by context. You can further
restrict it with access control, but there's no compelling reason for the
buyer's abstract to be publicized on the seller's endpoint. Following the
convention for its intended use cases would make it easier on the partners
to extract their relevant abstract.

It would also make the ?bpel a bad alternative to a management API that
provides straight access to the relevant artifacts. Which is where all of
this started. Two different use cases, two different semantics, and
therefore two different APIs.


> Tammo

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message