Web services in harmony
The XML Web Services One conference in San Jose provided an excellent
opportunity to see the burgeoning growth of Web services, which is still in its
early days. Discussions focused on helping developers to understand the concepts
and low-level technical details of the technology, as well as how Web services
will affect them. Savvy developers focused on finding the best ways to exploit
Web services and bring value to the business.
But how will developers deliver new applications rapidly? Through the use of
composite applications and orchestrations. A composite application is ''a
configurable, user-centric business process fused from multiple applications
that make their capability available as services.'' From a technology
perspective, ''multiple applications'' and other selected capabilities are made
available as Web services. A composite application defines a process that weaves
together a set of the available services to create a new capability. A process
engine then executes this newly defined process. The value of a composite app is
that it allows you to quickly define and deploy new processes to the business.
It also allows you to exploit existing capability without redeveloping it. The
scope of a composite application is typically within the bounds of a single
company, though it can span the world for that company.
As an example of a composite application, let's look at the new product
introduction process for a manufacturer. The process typically starts as part of
a demand planning process where there is an evaluation of market requirements
and product life cycles. This activity will, in turn, drive R&D and product
prototyping. If the prototype is successful and the decision is made to produce
the product, that will drive product engineering, product demand planning and a
host of supply-chain activities. At the same time, new marketing and sales
campaigns must be readied and sales forecasts estimated.
As you can see, the process of introducing a new product crosses many
different functional areas of the business, each with its own set of supporting
systems. A composite application weaves these disparate systems together to
create a seamless application to support the introduction of new products.
Imagine the value a business would see if that process could be improved.
Furthermore, using a composite application gives the business more flexibility
to quickly change the process as needed. No wonder developers, keen on
delivering business value, see composite applications as a golden opportunity to
help their companies.
An orchestration is similar to a composite application, except its scope is
between different enterprises. An orchestration is a configurable process
composed of capabilities from two or more companies. These capabilities are also
made available as Web services. Different parts of the process will run within
each company's environment. The bridging of boundaries between companies adds
some requirements that are not typical of composite applications. For example,
in interactions between businesses, transactions may be very long-lived. What
happens when it takes weeks to complete a process? There are other differences
as well. For example, where do you draw the boundary about what an orchestration
needs to know about a company's processes vs. what it does not need to know?
Typically, orchestrations do not need to know a business's internal processes.
It needs to understand the interaction processes. It also needs a clear
definition of the semantics of the interactions and the touch points to the
internal processes. As such, orchestrations are typically system- rather than
Is there an example of an orchestration? Let me give you a good candidate. A
recent Wall Street Journal article described the approach Circuit City
is using to sell CDs on the Web. It wanted to expand its Web site to sell a
variety of CDs, but did not want to bear the cost of stocking a large inventory.
Rather than carry the inventory itself, the company went to an Internet
''category manager'' -- Alliance Entertainment. Now when a customer on the
Circuit City Web site wants to buy a CD, they are routed to a Circuit City
branded site that is run by Alliance Entertainment, which ships the CD from its
inventory. If a customer wants to return a CD, they can take it to their local
Circuit City store rather than ship it back. A flexible approach to automating
these processes would help minimize costs and allow for rapid adaptation to
changing market conditions.
Pipe dream or reality?
We are certainly in the early
days of making all this happen. As such, there are plenty of potholes to hit on
the road to implementation. Yet the demand is there and vendors are working to
fill the gaps. So what do you need to develop your own composite applications
and orchestrations? Start with what you have. Can you identify the legacy
systems, components or other capabilities you wish to integrate? How will you
know which ones to make available as Web services? The best candidates for a
composite application typically cross business functions. Each business function
will usually have its own supporting systems. Composite applications are most
valuable when they integrate disparate systems. If the need falls solely within
a single business function, it is usually not a good candidate for a composite
application. Use an enterprise architecture to help you identify the relevant
business functions and their service relationships.
Orchestrations, by default, integrate multiple systems. The issue for
orchestrations is their amenability to automation. Some types of transactions
are best done face-to-face. Others are more amenable to system-to-system
communication. Currently, the best orchestration candidates will be those where
you can clearly define the semantics of the interaction. Security is also an
issue. Web service security is still evolving. SSL is available, but may be
inadequate for the level of authentication needed. Proposed standards include
XML Signature, which could be used in conjunction with XML Key Management
Specification (XKMS) to ensure a communication is authentic and has not been
tampered with. Other evolving trends include Security Assertion Markup Language
(SAML) and numerous products from third parties. You can also use dedicated
networks to increase security.
Once you've selected an appropriate candidate, how do you know which
capabilities to make available as Web services? Again, enterprise architecture
can help you identify which systems support the relevant business functions,
what information flows are needed between the systems, and the relevant
processes that need to be integrated. In dealing with existing systems, you'll
find that work you've done in the area of EAI will pay off. The challenge in
finding proper integration points is the same: Good interfaces for EAI are
likely to be good for Web services. Use enterprise architecture to uncover the
needed service and information flows. You may discover additional integration
points for your legacy systems.
The technology needed for these applications centers around Web services. As
you would expect, SOAP and WSDL will be essential technology components. A
private UDDI is also useful, so the location of services can be changed as
needed and the application will still find them. Another essential component is
a process engine. Web service tool vendors are moving quickly into this area.
One challenge in selecting a vendor is trying to pick one that supports industry
standards. There are only proposals in this area, no real standards. Microsoft
has XLANG. IBM has WSFL. A consortium proposed BPML, but it seems to be dying.
The best bet right now is to look for future synergy between XLANG and WSFL.
These languages are appropriate for composite applications, but may be
problematic for orchestrations. You may want to look at support for ebXML as a
way to support the semantics of inter-business interaction. Rather than try to
piece the technology together yourself, a number of vendors have packages that
cover most of what is needed to implement composite applications and
orchestrations. These packages can be expensive, but they can cut down
significantly on integration and development time.
John D. Williams is a contributor to Application Development Trends. He is president of Blue Mountain Commerce, a Cary, N.C.-based consulting firm specializing in enterprise, domain and application architectures. He can be reached via e-mail at firstname.lastname@example.org.