Assaf Arkin wrote:
On Sun, Jul 13, 2008 at 3:52 AM, Tammo van Lessen <[EMAIL PROTECTED]>
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).
Tammo
