OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]