|
We’re hearing a lot about web services these days. With this standardized,
plug-and-play technology come exciting opportunities to enable peer-to-peer
cross-platform collaboration.
SAP systems are among those platforms. The ability to capture credit
check information, for example, could prove invaluable to your organization’s
CRM initiatives. This information may be provided by enterprise-wide,
centralized customer master data systems in combination with external
offerings from specialized companies like Reuters, Dun & Bradstreet,
and others. And on the supply chain side, I see pervasive distributed
services like product availability checks, order status, and transportation
tracking in a standard supply chain process.
Credit and availability checks, of course,
are not new. What is new is how these processes are performed. For many
of you, these processes have always been cumbersome, conducted with lots
of human intervention, via mail, fax, telephone, or — best case —
in some specialized EDI environments. Web services have the capacity to
truly simplify and automate these activities. They provide a new paradigm
for simpler and more unified application integration, across enterprises
as well as within enterprises. For the first time, we have an easy enough
technology to provide broad interoperability between different programming
platforms, like Java and .NET, and applications that sit on different
systems at different locations under different administration.
The implications for SAP landscapes on
an abstract level are easy enough to visualize: As suppliers as well as
consumers, you have CRM, SCM, PLM, and financial applications that plug
into the wellspring of web services, which will continue to pop up across
the Internet within and between business communities. But how does this
capability actually materialize at the technology level? What elements
must be in place to enable applications to actually harness web services
within your SAP landscape?
Well, remember that a web service is an
application that can be discovered, described, and called by another application
over standard web protocols. At the technology level, this means:
 |
There is a shareable description of the
interface (inbound and outbound parameters)
of an application. The concept of web services
is: Take XML as the data format for all
incoming and outgoing information, and
take XML Schema as the language to define
these formats. |
|
There is a way to group information about
the web service’s
operations and interfaces together in a
shareable description. This is done by
the Web Service Description Language (WSDL),
which again is an XML document. More and
more design and development tools can
export or import such WSDL descriptions
for greatly simplified and accelerated
development at both end points — so
for the first time, there is a really
good way for development tools of various
vendors and various platforms to actually
work together in producing interoperable
applications. |
|
There is a place to publish and discover such web service descriptions.
This is where UDDI comes in. It provides universal discovery of web
services via a network of public registries, operated by companies
like Microsoft, IBM, SAP, HP, and perhaps others in the future. In
addition to that, UDDI can also be used for enterprise-level registries
in a more protected environment. |
Your SAP landscapes were actually equipped
to support many of these standards long before “web services”
dominated the IT headlines. Many of you may recall SAP’s Internet-Business
Framework, which became available with the first release of the Business
Connector for HTTP/XML-based interoperability of existing applications.1
Many of you, in fact, currently use the Business Connector to link applications
and systems in supply chain scenarios, to link up order management systems
and warehouse operations,and to get access to electronic marketplaces.
In the ensuing months:
|
SAP has published all interfaces of all
business application solutions in the
online Interface Repository (IFR.SAP.COM)
in a standard XML format, so it is really
easy to use them as web services. |
|
SAP has provided a full web service stack
(HTTP, XML, SOAP) in the SAP Web Application
Server.2 |
|
SAP has added a fully standards-compliant
J2EE engine to its Web Application Server.
SAP has recently shown at JavaOne how easy
it is to provide and use existing business
logic as a web service. |
|
SAP has built the portal infrastructure
and the exchange infrastructure around
the concept of web services and open standards.3 The
SAP exchange infrastructure fully exploits
the Web Services Architecture and provides
added value on top with its advanced mapping
and routing capabilities, especially when
the applications on the requester and server
side need some independence from each
other. |
|
SAP, a founding member of the Web Services Interoperability organization
(WS-I), is contributing significant resources to ensure that web services
can be built and used based on efficient and effective standards,
tools, and guidelines that ensure rapid development and deployment
cycles and interoperability, for example, between Java and .NET applications. |
What does this checklist mean to an SAP
customer who wants to leverage web services? It lends credence to the
claim that SAP already has, by far, the richest set of web service-capable
business functionality in the world today, and with the strengthened focus
on open integration solutions, this will accelerate even further. You
can explore with confidence the realm of web services and how they can
factor into your application plans.
| Web Services - Risks
and Rewards |
| Risks |
|
Whenever you call a service over the web, particularly one that
is critical to your business, you incur risk. Do you position yourself
to become too dependent on a business partner or service provider?
What happens if that service provider’s offering can’t
scale, or if it compromises the security of your landscape? What
if the service provider or business partner introduces incompatible
changes or performs insufficient data validation, thereby compromising
the integrity of the data you’ve become reliant upon? A web
service is only as good as the service provider who stands behind
it.
Performance is another risk. Web
services are by no means immune from the performance penalties that
can result from network latency or protocol overhead.
Security may be the biggest risk
factor of them all. You need to evaluate whether a web service that
you provide or rely on could be sabotaged, hijacked, or simply monitored
by an unintended party, thereby violating the confidentiality you
implicitly associated with that service. All these risks are real.
All can certainly be minimized, if not eliminated — but they
need attention and action.
|
| Rewards |
|
Web services offer business applications a whole new realm of trusted
data. Via a web service, an application not only can use all the
data that is under the control of your IT landscape, but can also
reach out to information that is provided and maintained by any
other company in the world. Web services form a veritable “information
supply chain,” fueled by increasingly specialized information
providers and collaborative applications, from vendors like SAP.
There is no longer any need to replicate
masses of data that could be more effectively maintained by eminently
more qualified business partners, marketplaces, and industry groups.
You even can access the catalogs and price lists of your suppliers
via web services; you can get complex balance sheet information
and financial reports of companies in specific XML formats and standards.
And web services need not necessarily
come from large central server applications. Small and mobile devices
will not only be able to consume web services, but also provide
them in specific settings. Your SAP applications, for example, may
soon be able to glean up-to-the-minute status information about
transported goods (e.g., location and environmental conditions)
continually collected and transmitted by micro devices (like small
radio frequency tags) that actually travel with those goods.
In both the credit check and availability
check scenarios that opened this article, the information is not
collected and maintained by the inquiring party, and it would be
practically impossible to do so. In fact, once we take a closer
look at master data systems in many companies, it becomes clear
that much information about business partners, products, prices,
and the like would be easier to maintain at the point of origin
rather than at the point of use. There may be good practical reasons
(like high-availability and performance) to have a temporary copy
of some of that information available in the local system. But even
this process of copying and caching is best done based on standardized
web service protocols and XML-based data formats.
Finally, from a technology point
of view, web services are the only viable way today to really bridge
the gap between heterogeneous platforms like Java on one side and
Microsoft’s .NET on the other — and that’s a bridge
that is sorely needed, as both platforms are here to stay!
|
1For
more on the Business Connector, see the SAP Insider online Article
Archives
2 Further information
on the SAP Web Application Server is available in the SAP Insider
Article Archives
3 For
details about SAP’s exchange infrastructure,
see the articles from the April-June
2002 SAP Insider (www.SAPinsider.com)
 Franz
J. Fritz has a Ph.D. in mathematics and 30 years of experience in all
areas of IT. Workflow and business process management have been particular
areas of interest for much of his life. He has worked for SAP since 1993
as Program Director and Vice President with responsibility for the Business
Process Technology and Internet-Business Framework departments. Recently,
he took over the responsibility for technology architecture and technology
product management within SAP AG.
|