[CAnet - news] BPEL: The Next Big Thing in Software?
"Bill St.Arnaud" <[email protected]>
| Newsgroups | gmane.culture.publications.news |
|---|---|
| Message-ID | <01b501c5ee28$a21031c0$dcfeff0a@amarillo> |
For more information on this item please visit the CANARIE CA*net 4 Optical Internet program web site at http://www.canarie.ca/canet4/library/list.html ------------------------------------------- [A good overview article on the potential of BPEL, but too narrowly focused on business processes in my opinion. BPEL has a much wider application with respect to mash-ups and other Internet applications. Some excerpts -- BSA] http://www.informit.com/articles/article.asp?p=426407&seqNum=1 To use business process parlance, most applications of recent years have "hard-coded" the associated business process logic. An example is the Save As feature of Microsoft Word that allows you to save a Word document as HTML-the result is a deluge of nonstandard HTML tags! But some of us need standard HTML for our business processes. Complexities like this have forced enterprise users to bend their processes to match those embedded in shrink-wrapped software, but this situation is about to change in a quiet way with the advent of web services and BPEL-based products. Service-oriented architecture (SOA) has been around for years. Its premise is simple: Software should be built and used as a set of interconnected services-getSharePrice, buyShares, bookPlaneTicket, and so on. The services are available as reusable blocks that you combine as needed into service-oriented applications. The resulting software should facilitate your enterprise business processes. But the lack of a standard flexible business process definition and execution language has hindered the migration from monolithic/custom applications to the more dynamic requirements of our volatile times. This state of affairs may be about to change. A relatively mature standard called Business Process Execution Language (BPEL) may help usher in an era of web services that are tightly and easily integrated with true business process flows and activities. This new era of process-centric web services may well integrate a wide range of existing standards and technologies; underpinning this migration is a set of standards and specifications based on J2EE and application servers-a solid foundation indeed! Web services use XML schemas for data models, SOAP for communication, and WSDL for defining the location and capabilities of services. BPEL combines all of these technologies with the ability to design, code, test, debug, and deploy advanced automated business processes. Surprisingly, BPEL may provide a means for developers to improve their prospects-by changing the basis of their work from pure development (design and cutting code) to either integration or creation of highly focused business components. Integration is usually more difficult and hence has higher value than pure development. The timeline for representing business processes is referred to as a swim lane-this is conceptually similar to the state transition diagrams of UML. 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! ------------------------------------- To SUBSCRIBE: send a blank e-mail message to [email protected] To UNSUBSCRIBE: send a blank email message to [email protected] ------------------------------------- These news items and comments are mine alone and do not necessarily reflect those of the CANARIE board or management. ----------- [email protected] www.canarie.ca/~bstarn skype: pocketpro SkypeIn: +1 614 441-9603 _______________________________________________ news mailing list [email protected] http://lists.canarie.ca/mailman/listinfo/news