Platform-Independent, Standards-Based Information Sharing

What are Web services?
What are Web services?

Web services provide a standardized, platform-independent way for applications and organizations to share information and functionality. What’s more, Web services can lower the costs of maintaining and integrating processes that span various platforms and solutions, including those of partners and customers. So, how to use Web services to get more out of IT investments?
SAP NetWeaver Developer Studio is SAP’s integrated development environment. It not only supports Java, J2EE, and Web Dynpro development, but it also provides the tools and wizards for easily creating, reusing, and modifying Web services – sometimes in just a few mouse clicks. SAP offers a flexible, extensible Web Services Framework as part of its standard development processes, to ensure that Web services can be implemented with the same mechanisms and tools and that they use the same services – for example transport landscape or Java Development Infrastructure – as other SAP applications.
Once the business process and appropriate interfaces to expose as Web services are selected, tools will be found to be guided through the basic steps within SAP NetWeaver Developer Studio. This also holds for client-side support to help to incorporate new cross-platform functionality into a current business process.

Providing valuable (Web) services to the world – the server side

Web service standards
Web service standards

Any Web service starts with the business process itself and identified, standard implementations of business functionality. These can range from credit-card checks and currency-exchange computations to payroll functions. Based on the standard interfaces of a business application, any self-contained, modularized functionality that is implemented either as an Enterprise JavaBean (session bean) or as a Java class lends itself to deployment as a Web service. This functionality could be provided by SAP as part of a mySAP solution or could be developed by SAP users, their customers, or their partners. This section takes a look at how a Web service is created and registered on the server side.
SAP NetWeaver Developer Studio offers two options for building a Web service: one is a quick wizard-based approach; the other is more involved, but provides the flexibility for custom-designing more complex Web services. These two approaches aren’t necessarily mutually exclusive. It is possible to quickly create the Web service with the wizard and return later to manually fine-tune the default settings using the second, more advanced approach.

Creating a Web service in less than a minute

Web services creation wizard
Web services creation wizard

Once a process and an interface which should be made available are identified, the easiest way to start is with SAP NetWeaver Developer Studio and the Web services creation wizard. With this wizard, configuring a Web service is a highly automated process based on predefined configuration profiles developed by SAP that bundle settings used in typical Web services scenarios.

Who creates the Web service?
Who creates the Web service?

The configuration profile, Simple SOAP, for example, is set for stateless Web service calls over an intranet, where no additional security is required. In Figure 1, this profile includes no authentication or authorization functions and specifies the use of SOAP over HTTP for transport. Additional profiles combine other settings, including basic authentication, strong security or authorization.

Who implements the Web service?
Who implements the Web service?

With these wizards, even a Java developer who is less experienced with detailed technical aspects of Web services can still create one simply by clicking through the three steps of the wizard. In the background, all the required objects are generated to the appropriate projects.

Step-by-step approach

Five steps
Five steps

Sometimes ease and speed of development will take a back seat to more advanced processes in order to meet special requirements. In this case a five-step process for exposing a business application as a Web service without the help of the creation wizard is the right path to follow.

1. Implementing the business logic.
Whoever is able to implement a Java class or enterprise session bean, can also implement the business logic for a Web service. It doesn’t involve anything specific to Web services – simply the implementation of a Java class or to follow the enterprise session bean model. Both approaches can be used for building Web services and are supported from either the Java or J2EE perspectives in SAP NetWeaver Developer Studio.

2. Defining the virtual interface.
The virtual interface (VI) is the interface that the Web service will expose to clients (i.e., consumers). As its name suggests, the virtual interface is abstracted from the “actual,” original, business application interface.
The default for the VI is a 1:1 mapping between the original, implemented interface and the interface exposed to the client. The user is then free to tailor this default interface, using a VI editor provided by the NetWeaver Developer Studio, to:

  • Rename methods and parameters
  • Hide methods or parameters
  • Provide default values for parameters
  • Decide whether parameters are treated as attributes or elements in the SOAP message
  • Change namespaces
  • Map basic data types according to Java standards

This means to be able to easily define any number of views on top of the original, implemented interface, in order to deliver specially tailored, platform-independent interfaces to Web services consumers.

3. Creating the Web service definition.
Based on the virtual interface, the developer creates a Web services definition using a wizard. This step defines the Web service’s behavior on a general level. Supported by an editor tool, session handling, authentication, authorization, and transport guarantees are all defined in this step.

4. Setting up the Web service configuration.
In a system landscape, different application servers may have different technical capabilities. In this step, the general features defined in 3. are mapped to the actual technical capabilities of the server. So if the developer indicated that this Web service requires stateful communication in 3., the IT team can determine at this stage whether this should be realized using HTTP cookies or URL extensions.

5. Deploying the Web service.
Java developers will be pleased to learn that deployment involves no special Web services-specific tasks. Deployment processes are fully integrated into the Developer Studio, and the entire configuration for deployment is handled transparently in the background.

Testing capabilities – quick turnaround times in development

Testing Web services
Testing Web services

To test a new Web service after creating it, for every deployed Web service, a Web service homepage is automatically created and deployed. Using a browser-based interface, the homepage bundles the complete documentation, shows the associated WSDL files, allows to generate client proxies, and offers testing capabilities. That allows to check every Web service without any additional coding to implement a test client. A full status overview completes the homepage, showing selected features including the status of UDDI publishing.

Adding Web services to the business processes – the client side

The SAP Web Application Server (SAP WAS) not only supports the creation of Web services on the server side; calling Web services as a Web service client (or consumer) is the second role the SAP Web Application Server can play. And just as on the server side, the developer will find plenty of support from SAP NetWeaver Developer Studio on the client side. There are four basic steps for running a Web service application from the client side:

  • Retrieving the Web service description: A standards-compliant Web service description is the starting point for implementing a client application. To find a suitable Web service, either browsing the UDDI with the integrated Web services browsing tool or adding the own WSDL description manually is necessary.
  • Generating a Web service proxy: Using a valid WSDL file as input, a Web services client proxy is generated. The proxy allows the application developer to focus on business functionality, while technical aspects like creating a valid SOAP message are automatically done by the proxy implementation.
  • Implementing the client application: Different types of implementations can use the generated Web service proxy. Depending on the needs of the project, one might choose Enterprise JavaBeans, Java classes, or Java Server Pages. Whichever is used, the implementation of the client functionality follows the standardized and commonly accepted Web service programming model.
  • Deploying the application: Last but not least, the deployment needs to be executed. As on the server side, deployment is based on integration with standard SAP Web AS processes, so no Web services-specific actions are required.

With SAP Web Application Server 6.30, SAP offers an easy, convenient way to build Web services. Anticipating the proliferation of comprehensive business processes based on Web services, SAP has introduced the Enterprise Service Architecture (ESA), a newly developed approach for building services-oriented business applications. ESA offers a blueprint for creating new, flexible, modular applications that support communication in heterogeneous environments. SAP NetWeaver and its application platform, SAP Web Application Server, are the foundation for all mySAP solutions, and the Web services capabilities of SAP Web AS are a vital part of the ESA strategy.
As Web services continue to evolve, new standards will further enhance security, support more complex messaging among multiple Web services, and lead to even greater standardization of business documents and processes. This encourages a wide adoption of Web services and ensures the continued evolution of supporting technologies.
More information

Source: SAP Insider

Martin Huvar
Martin Huvar