Requires Free Membership to View
 |
||||
|
|
|||
|
||||
BPEL, by its nature, requires participation from not only IT,
but business analysts. What kind of challenges does that pose?
BPEL
is a complex specification. To do it with the right amount of rigor to be a foundation for
industry, takes a lot of deep thinking to get into bowels of how it should work with XPath (XML
Path Language), WSDL
(Web Services Description Language) and XML, for example, and how it should be used by business
analysts.
It's exactly true that one of interesting things is scope of participation. Companies and
individuals interested in the Web services aspect of BPEL get into the XML and WSDL discussions,
and companies predominantly concentrating around business process management and workflow are
equally interested from different perspective. A challenge as one of the chairs is to bridge that
gap and make sure all of us use the same terminology. BPEL does have some wide applicability. The
technical committee is scheduled to meet next week [Tuesday-Thursday]. What's on the agenda?
The agenda is set based on proposals members bring forward and issues they identify. We'll be
talking about a few clarifications on how to use XPath, a higher level discussion around whether
there should be consideration for sub-processes
in BPEL. There will also be a lot of discussion of applications of abstract processes, how they
should be used and support that needs to be in the specification.
|
 |
||||||||||||||||
|
|||||||||||||||||
How is public feedback incorporated into what the TC does?
We don't get a lot of public comment. OASIS is a large organization, and we are one of the larger
technical committees. We've got 45 active working members who attend that represent 35 to 40
companies, and that includes all of the big middleware vendors. Many of those companies are
implementing BPEL runtime engines [in their products] and many are working at the tooling level and
how to provide graphical interfaces that will support BPEL. On the other hand, a number of
individuals are in the business analyst role. Can you talk about BPEL's importance among the vast
array of Web services specifications already approved or under construction?
Speaking as an IBM representative for a second, the origins of BPEL come from work done at IBM and
Microsoft on WSSL (Web Services Security Language) and XLANG (the XML business process language
used in Microsoft's BizTalk Server). With the marriage of those two technologies, BPEL has taken a
giant leap forward.
It provided BPEL
with the critical capabilities that allow Web services applications to go up a notch in terms of
their business value. Basic Web services are a great concept, but a stateless one-on-one
interaction. With BPEL, you take activities as part of a business process, express them as a Web
service, then orchestrate Web services so you have control over the full process. It's compelling
from a business process point of view and from a process management point of view. What is driving
all the interest in BPEL? Is it IT's growing interest in service orientation?
Sure, that's part of it. The timing of BPEL is well suited. It's gotten to the point where the
foundation of Web services is understood and adopted. Companies have gotten through the
investigative and proof-of-concept phases and are thinking about integrating the technology into
real work and how to use Web services.
If you take the classic example of booking a business trip online, you're communicating from a client company through a travel agent to an airline, hotel or car rental agency. You need to be able to orchestrate those steps and determine relationships between them.
From a standardization perspective, the beauty of BPEL, once you work through the details, is
that it has the potential to offer a degree of interoperability at the process level, describe
process and use it in different runtime infrastructures. It opens the possibility for standardizing
processes as a deliverable expressed in BPEL. As the TC deliberates, any surprises or sticking
points you can share?
What we're working on with BPEL is the core foundation for processes and process management, and
taking into consideration any ideas for extensions [to the specification], most of which we are
deferring. We are deferring because there is a great deal of work to be done to get standardized.
Any interesting ideas, we are logging for future consideration.
The sticking points revolve mainly around how it has taken members some time to fully appreciate the aspects of the spec and the relationships between the components of BPEL.
FEEDBACK: Where do you rank BPEL among the Web services standards?
Send your feedback to the SearchWebServices.com news
team.
The technical committee is chartered to complete three deliverables: specify the core elements
and functionality of BPEL; an extension specification for business protocol description; and an
extension specification for executable process description. Can you tell me which, if any, have
been completed and provide a progress report on those that remaining?
The original charter was written with the input document in mind. It has three sections and these
were referenced as three deliverables but there hasn't been a plan to actually split them into
different documents. We've been working on all three sections in parallel and the final
specification will include all the content. There's been a suggestion to rework the spec for
readability which might result in a different structure where there wouldn't even be three parts.
That will come up for consideration during the final editing once we've dealt with the technical
issues and clarifications.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation