[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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.