The vast majority of software producers focus exclusively on
domain-specific solutions. In this way, software is becoming more
customized and, correspondingly, less generic. While some end users
(particularly large corporate customers) may be able to request
features that closely fit their business processes, it's likely that
most of us end up with a poor fit between our deployed software and
our business process needs. The end result is massive cross-vendor
duplication of software development that tries to implement code as
well as business process logic. An interesting separation of concerns
is becoming possible by the use of BPEL (Business Process Execution
Language), which allows for business process logic to be expressed in
a specific language and to be tied into external software. This reduces
(and potentially eliminates) the need to code business process logic
in a traditional programming language (such as Java or C++/C). In
turn, this provides a clear separation between software features and
business processes. By taking the business process logic (e.g.,
workflow management) out of the application code, the latter becomes
simpler and more focused. In this article, I'll review the idea and
merits of separating software features from business processes in the
context of BPEL. Along the way, we'll see how this leads neatly to
the need for highly generic software. The latter is (in my opinion)
a pressing concern for all software developers... I think that IT should
endeavor to become as streamlined as possible and BPEL/web services
suggests itself as a possible path to take. By removing business
process logic from code, we would see the potential emergence of
generic software for web services use. Business process logic would
then reside in a BPEL layer that would orchestrate the required
service calls. This would help to reduce the growing complexity of
software and systems.
No comments:
Post a Comment