GRC
HR
SCM
CRM
BI


Article

 

Web Services — Risks, Rewards, and Realities

by Dr. Franz-Josef Fritz | SAPinsider

July 1, 2002

by Dr. Franz-Josef Fritz, SAP AG SAPinsider - 2002 (Volume 3), July (Issue 3)
 

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.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ