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: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution]

Hello Satish:

> I believe your example falls into the (intended)
> "external behavior description" profile which forbids
> executable completions that add interactions along the
> partnerlinks in the abstract process since the intent of
> such an abstract process is to fully specify externally
> visible behavior.

This is true. However I think of the aforementioned
scenario as a process template. I envision the BPEL
abstract process being translated into an abstract
class in some language, the implementor overriding
methods that customise behaviour (this is the template
design pattern).

And here lies the problem. Different names for similar
activities are going to result in a proliferation of
profiles and tool sets. Also how do I communicate, preferably
in a machine processable form, the description you or I,
just provided?

I think it is just easier to agree on an abstract
process's behaviour.....

An analogy. Most object-oriented languages have some
notion of an abstract class, its behaviour supported
to different extents by the language. Most educated
programmers understand abstract classes. And scores of
design patterns (read use cases) use abstract classes.
However I don't see Java, C#, C++, using profiles to
describe how the abstract class should be used.


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