Re: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications (withOUT change log)]

[<andrew.francis@mail.mcgill.ca>]

Hello Yaron:

> Then sentence "The semantics of an abstract process
> are therefore derived from those of the executable
> processes to which it would be mapped." confused me as
> it would imply  that all abstract processes MUST be mapped
> to an executable process.

Actually shouldn't this be the other way around: "The
semantics of the executable process are therefore derived
from those of the abstract process to which it would be
mapped"? I would think that what the passage really wants
to do is establish how an abstract process's semantics
are governed by the WS-BPEL language, not executable
instances.

Also, most books tend to use terms like "subclasses"
derived from abstract classes."

I believe abstract processes are easier to understand
if one equates an abstract process with an abstract
class in an OOP. If I were to create a profile, this
would be its starting point. I like this comparision
because an abstract class both defines type and
behaviourial (semantics) information.

>But  I was unaware of us ever wishing to imply that?
>Is the only possible use of an abstract process to create an
>executable process?

There are probably other uses (i.e., deriving additional
abstract classes, depending if a particular profile
permits this) but deriving concrete instances from abstract
processes is far and away the most useful. And the more
machine processable the abstract process is, the better.
I think that profiles that stray away from these traits
will have very limited utility.

Cheers,
Andrew