Aspects in BPEL
To continue Jeff's and my musings on Aspects...
I compare BPEL to C. The list of features of the language is rather short. It provides just about the minimal set of features required to string services together. All extensions of are done via other services, not new language constructs (although that's theoretically possible). Unlike C though, BPEL is not a language of the curly-brace family, it's an XML language, i.e. it's even more verbose than VB. Because of all the tags and anglebrackets in a BPEL source, it's pretty hard to comprehend the actual process flow. If you're part of the elite (or rather: insane) club of people who tried to write BPEL using a text editor, you know what I am talking about.
Fortunately, orchestration tools solve the anglebracket-readability problem. They greatly simplify building business processes and other applications by drawing “flow charts“ and only emit BPEL anglebrackets for deployment.
Another analogy between BPEL and C is the lack of support for aspect oriented programming (AOP). AOP is a popular technique to program non-functional requirements without having to mix code for functional and non-functional requirements. Aspects, such as journalling method calls for example, are “applied“ declaratively. .NET allows declaring aspects via attributes and the .NET libraries handle them at runtime. The AspectJ compiler for Java demonstrates another model to handle aspects. It translates the aspects into Java code at compile time and does not require any support from the runtime environment.
BPEL, like C, does not support AOP. I hope once again, the orchestration vendors will come to our rescue. It shouldn't be too hard to copy the AspectJ model and generate BPEL code to address aspects at compile time. This solution would provide fully BPEL standards compliant code, but it could turn aspects, like logging, retrying to call services that didn't respond, etc. into checkbox items in your service designer. As an added benefit, it would help to focus the “flow chart“, i.e. on the business process not on some plumbing code. That's a aspect that's just as important for graphical languages as it is for any text based language.
The future will show if there is another analogy between BPEL and C. After years of success, C eventually evolved into more powerful languages like C++, Java and C# and as Jeff Schneider pointed out, Service Oriented Languages could come with quite a rich feature set.
Of course, orchestration and BPEL are just in their infancy ... and aren't the baby years always something wonderful ;)