Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Conclusion
Now that BPEL is growing in importance, users will be less inclined to bend their own business processes to those hard-coded into shrink-wrapped software applications. If you don't like a given feature (such as Word's Save As HTML), it should be possible to locate a suitable web service, integrate it into your BPEL code, and call that service instead.
Naturally, the source of such web services must be both trusted and competent. A key point here is that we already allow software updates to Windows platforms. The paradigm shift for BPEL is accepting software at the level of source code. For programmers, this adjustment might mean more emphasis on producing snazzy little web service business components for incorporation into BPEL environments. That's the supply side. On the demand (customer) side, programmers may increasingly be pressed into service as software integrators. It's too early to say whether this change will produce a market for very focused software business components, or a legion of overly specialized developers.
My own feeling is that much of today's software is too specific to application domain. Thousands of developers are simply writing much the same code (of varying quality) for different companies and products. As more and more such products fall in price or stop getting upgraded, many of the associated programming jobs may move offshore or disappear altogether. So a solid knowledge of BPEL is probably a good investment!