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] Issue - 2- requirements for a sub function solution

Ugo Corda wrote:
Ron, you say:
> A standardized modeling vocabulary is very useful; a modeling vocabulary that omits key concepts (for example, sub-processes) has far less value.
We have actually not been talking about omitting the concept of sub-processes, but rather whether this concept could be modeled with existing constructs (possibly with minor modifications to existing syntax).
I think we may be getting to the core of the disagreement here. It is my assertion that BPEL has no vocabulary for expressing subprocesses/subfunctions. Instead, it advocates treating them as services by convention. This is where the rub lies, I suspect.
My tools argument was not about the tools compensating for functionality not existing in the language, but rather about making the issue of how this functionality is actually expressed less relevant.
A fail to see a distinction. Perhaps you can elaborate on this point, please?

Your argument that analysts are uncomfortable with a WS-based approach seems rather weak, given the fact that WS concepts are very aggressively spreading throughout the industry (so that even pointed headed managers are quite comfortable talking about Web services today ;-).
It is true that buzzword compliance dictates a certain familiarity with some WS concepts, especially SOAP.

However, I'm not arguing that analysts are uncomfortable with WS-based approaches; I'd say they are adding SOA concepts to their bag of tricks, but they aren't casting aside other tried-and-true concepts in a rush to treat the universe as nothing but web services. We've all seen far too many over-sold "silver bullets" to now breathlessly cast aside everything for the latest acronym du jour!

What I am trying to say is that analysts today have a rich vocabulary for describing business processes, including ones that are amenable to automation (executable in our parlance). BPEL omits some important elements of that vocabulary. That should be of concern to us.
It would be like saying, 20 years ago, that languages should not have used OO constructs just because programmers were only comfortable with functional programming.
Humm. I not sure I buy the analogy. OO was additive -- it added new concepts and language features to the existing structured programming model. The case we have in hand is subtractive -- it is removing concepts, or in some instances attempting to collapse them. Certainly BPEL is a sparse process language, compared to most others. From the process point-of-view, web services serve mainly to create a simplified model of work performers. Secondarily a process can serve as a service composition mechanism. But I digress: I don't think the analogy with OO adoption is apt.


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