Web services will likely hold out greatpromise for transactions that are inher-ently independent of platforms andprogramming languages: the ever-elusivecombination of interoperability alongwith greater flexibility and adaptabilityin building, maintaining, and changingthe connection points in your applica-tions. And because Web services areeasily executed over the Internet, theresulting business scenarios have anexpanded user reach. But how do you goabout replacing traditional services —especially the most resource-intensiveones, based on contracts or proprietaryprotocols — with Web services?

This article outlines how in just afew simple steps — and with the helpof tools and wizards built into the design-time environment — developers canquickly and easily adapt current Javaand ABAP applications to a service-based approach. But first, let’s look atthe benefits of a Web services-baseddesign and SAP’s new level of supportfor Web services with SAP NetWeaverand SAP Web Application Server 6.40.

Building Web Services forEnterprise-Scale ApplicationsProtocols for connecting enterpriseapplications have been around for quitesome time, but developers have typicallyencountered obstacles when designingaccording to these models. For example:

■ Proprietary protocols force devel-opers to think in a product-specificway and learn special programmingAPIs in order to achieve interoper-ability.This is the major issue with,for instance, RFC technology. WhileRFC is a proven, robust technologywith an easy-to-use programmingmodel that has been widely used toconnect SAP systems, developershave found it more difficult to inter-operate SAP and non-SAP environ-ments when relying on software devel-opment kits on top of the RFC API.

■ Interface description languagesleverage programming to express thecontract of a business service in alanguage-neutral way. CORBA/DCOMused that approach, but bridging thetwo environments turned out to be amajor undertaking.

Web services promise to overcomethe limitations of these technologies fora number of reasons:

■ Web services are defined independ-ently of programming platforms andlanguages. All major technologyvendors support Web services.

■ Web service definitions are expressedin XML syntax, making it easy todevelop and offer the tools fordefining services based on XML.

■ Web services, as their name suggests,can easily be executed over the

Web Service Technologyfor SAP NetWeaver

Regular Feature

UnderDevelopment

Karl Kessler, SAP AG

Internet, making it possible to estab-lish distributed business scenarios inan ad hoc fashion.

■ Web services can be developed in anyprogramming language, includingJava, ABAP, or C#.

■ Web services can be published in acommon directory based on the UDDI(Universal Description, Discovery, andIntegration) standard.

■ Web services have been standardizedin committees including WS-I andW3C.

Quick adaptation of businessprocesses is crucial for the overallsuccess of a company. Consequently, youneed a highly flexible architecture thatoffers enterprise application content in aservice-oriented fashion and that allowsyou to reconfigure business processes ina model-driven way.

Subscribe today. Visit www.SAPinsider.com.

This article appeared in the Jul ■ Aug ■ Sep 2004 issue of SAP Insider and appears here with

permission from the publisher, Wellesley Information Services (WIS), www.WISpubs.com.

Enterprise Services Architecture(ESA) is SAP’s blueprint for helpingdevelopers design and implement suchservice-oriented business solutions.1 Aservice-oriented approach, as the namesuggests, requires a thorough technicalfoundation to develop, publish, andconsume services — and ideally, willoperate in a platform-neutral and stan-dardized way. SAP NetWeaver, SAPWeb Application Server (SAP Web AS),and more and more new SAP solutionsfollow ESA, so they include tools andcontent that help developers quicklybuild new business scenarios — espe-cially cross-application scenarios(xApps)2 — on top of SAP’s existingenterprise applications.

The advantages of Web services tech-nology are the driving force behindmoving to service-oriented enterpriseapplications and adopting ESA. As aresult, Web services will play the domi-nant role in the implementation layersof various integration scenarios — notjust cross-application frameworks, butA2A (application-to-application) andB2B integration as well.

The Web ServicesProgramming ParadigmWith Web services, the world is dividedinto providers and consumers (seeFigure 1):

■ The Web service provider develops aWeb service in a certain programminglanguage and deploys it to its ownserver runtime environment.Theservice is described in the WebServices Description Language(WSDL) using special XML tags.Theservice description is published in acommon service directory (see inFigure 1). Web services directories

are generally organized following theUDDI specification. Major softwarevendors such as SAP, Microsoft, andIBM operate their own public UDDIdirectories. You’ll find SAP’s direc-tory at http://uddi.sap.com.

■ A developer on the Web serviceconsumer (client) side can browsethe UDDI directory and look forapplicable services (see in Figure1).The consumer may then downloadthe WSDL of a selected Web serviceand trigger the execution of the Webservice over the communication linkthat is established between theconsumer and the provider. Webservice invocations are standardizedusing SOAP, while a SOAP requestcontains the name of the Web serviceplus its actual parameters. A SOAPresponse contains the result parame-ters based on the signature that isexposed in the WSDL. Note that in aWeb service scenario, the use of thedirectory is optional; if you knowwhere a Web service runs and youobtain the description directly fromthe Web service provider, you caninvoke the Web service without usingthe directory.

Figure 1 The Basic Steps for Creating and Executing Web Services in an Application

Web Service Provider

Figure 2 shows the Web serviceprovider environment in more detail.SAP Web AS 6.40 offers a develop-ment and runtime environment for theprovision of Web services.The develop-ment environment supports the imple-mentation and configuration (securitysettings, etc.) of Web services, alongwith WSDL generation and the service’spublication in UDDI.

The runtime environment offers aSOAP engine capable of executingrequests and producing responses undera given Web service configuration thatcontrols security settings and thebehavior of different features.

Although you can develop Web serv-ices from scratch, there are also acouple of good starting points in yourcurrent applications — traditional serv-ices that can be transformed into Webservices.These include:

Existing RFC-enabled functionmodules and BAPIs on the WebApplication Server’s ABAP stack

On the Java stack, session beans orordinary Java classes

✔

✔1 See www.sap.com/esa.

2 Cross applications (xApps) are composite applica-tions that can span departments and organizations,using solutions from SAP and certified SAP part-ners. For more information see www.sap.com/solutions/xapps/index.asp.

Subscribe today. Visit www.SAPinsider.com.

These services will need some refine-ment in a specific Web service’s design-time environment before they can beexposed directly to the Web servicelayer.This environment is now builtdirectly into the ABAP Workbench andthe SAP NetWeaver Developer Studio.

Web Service Consumer

Figure 3 shows the Web serviceconsumer environment in more detail.From the development environment, the

client-side developer is able to locateexisting Web services in UDDI directo-ries.The WSDL of a given Web serviceis then used to generate suitable proxyclasses for either the Java or ABAPenvironment.The Web service proxyconfiguration is distinct from the actualcode, so you can reconfigure the Webservice without actually changing thecode.

At runtime, the call to the proxyclass triggers the SOAP runtime on the

client side to issue a SOAP request andtranslate its response in the formatexpected by the proxy classes.

As on the server side, the Workbenchand the Developer Studio help imple-ment the client-side logic of a Webservice scenario.

A Quick Walk Through theSAP Web Services Tools forJava and ABAPThe support for Web services in theDeveloper Studio is a real highlight ofthe SAP NetWeaver 2004 release.Without any detailed knowledge ofWSDL, SOAP, or UDDI, developers —whether they are working with Java orABAP — can develop a Web service andimmediately test drive it. Here’s how:

Developing a Web Service in Java

Rather than start from scratch, youcan derive your Web services fromexisting code. For Java, session beansoffer a good starting point. Since theyare responsible for performing session-level functions and services and servethe UI layer (Web Dynpro, JSP, etc.) onthe server side, session beans are thenatural entry points to business logic.They expose an interface with businessmethods that you can use to define theoperations of the Web service, and arederived from the underlying sessionbean types.

To create a Web service from asession bean, SAP provides a WebServices Creation wizard. Simply go tothe Developer Studio.There, when youopen any J2EE program, you will see itseparated into three different projects:

■ The Enterprise Application project,which contains items such as thedeployable enterprise archive(FlightApp.ear).

■ The EJB project, which containsEnterprise Java Beans and theircorresponding deployment

Figure 2 Providing Web Services Based on Open Standards

Figure 3 Consuming Web Services Based on Open Standards

Subscribe today. Visit www.SAPinsider.com.

descriptors. A session bean(FlightBookingProcessorBean)is selected in Figure 4.

■ A Web project, which containsthings such as JSP, servlets, stylesheets, and other Web content thatis not relevant from a Web servicesperspective.

In Figure 4, you’ll see that by right-clicking on the FlightBookingProcessorsession bean, you can open a contextmenu. Start the Web Services CreationWizard by selecting New → WebService. Based on the properties ofthe session bean, a popup then appears(see Figure 5).The only thing you haveto do is to specify a Web service name(WSFlightBooking in our example).

Next, you select the businessmethods you would like to expose asWeb service operations.There is noneed to expose the full interface of anexisting session bean; you simply exposethe methods that are required for yourbusiness scenario. In our example,the Web service will include two busi-ness methods, getConnections andsave_booking (see Figure 6). Foreach selected method you can renameparameters for better readability, hideparameters, change their types, orprovide default values.

Finally, you build and deploy yourenterprise application project to publishthe Web service onto the J2EE engineas you would do with any other J2EEproject.

That’s it. You’re done. Easy, isn’t it?

All that’s left is to check and testthe Web service. You can inspect theWSDL file that was generated automat-ically for you, however, I personallyprefer to test-drive a Web service imme-diately after deployment.The DeveloperStudio provides a Web service view thatyou can open from the Windows →Show View menu. Here, the Web ServicesNavigator lists all services currentlyavailable (see Figure 7).

Figure 4 J2EE Elements of the Flight Booking Program

Enterprise

Application

Project

EJB Project

Web Project

Accessing the

Web Service

Creation

Wizard

Figure 5 Web Service Wizard in SAP NetWeaver Developer Studio

Figure 6 Selecting Methods for Your Virtual Interface

Subscribe today. Visit www.SAPinsider.com.

✔ Note!No matter what language youdevelop your Web service in (i.e.,ABAP or Java), it always hasthree parts:

■ A virtual interface, the selectedbusiness methods and potentialparameter adjustments

■ The Web service definition,which enumerates selectedfeatures such as authenticationor session settings

■ The Web service configuration,which indicates, for example, thecorrect transport protocol to use

As you can see, Web services arehighly modular — one of the benefits that ESA builds on.Changing the configuration of anexisting Web service does notinvolve digging into any code.

If you double-click a displayed servicein the Web Service Navigator (bottomright in Figure 7), the home page for thatWeb service is created automatically.From the home page, you can also selectthe Test tab, which will display the fields

for every input parameter for a partic-ular method — in this case, thegetConnections method (see Figure 8).Fill in these fields, hit the Send button,and a page containing the output param-eters is shown, similar to the input form.

Figure 7 Viewing Detailed Information About the Flight Booking Web Service

Web Service

Home Page

Test Tab

Web Service

Navigator

Figure 8 Testing a Method in a Web Service Using the Developer Studio

Subscribe today. Visit www.SAPinsider.com.

Web Services Support in theABAP WorkbenchWeb services development in the ABAPWorkbench — with its own version ofthe Web Services Creation Wizard —is also quite easy. From the ObjectNavigator (transaction SE80), selectEnterprise Services → Web ServicesLibrary and right-click for the drop-down menu (see Figure 9). In thiswizard, the individual steps are nicelydocumented, which will be helpful if youwant to make changes to your Webservice in the future.

You must first specify a name forthe virtual interface and select a givenendpoint — an ABAP developmentobject that you can derive a Web servicefrom. In our example, we use functionmodules (see Figure 10).

After specifying a function modulename, the system will generate asuggested name for the underlying Webservice definition (see Figure 11).

Then, as shown in Figure 12,pressing Complete releases the Webservice, which means that the servicecan be executed.

To test your Web service, from theSAP GUI OKCode field, start transac-tion WSADMIN, which provides anoverview of the available Web services.From there you can start the Webservice’s home page, provide inputparameters, and execute the Web servicejust as you would in the Java scenario.The result will look exactly like the viewback in Figure 8. Once again you see thepower of Web services: you develop aservice in one environment (say, ABAP)and easily invoke its functionality inanother environment (Java, in our case).

As you can see in this example, arunning J2EE engine is necessary toexecute the Web service, since the homepage functionality was implemented as aJava servlet. However, this function isable to connect to any Web serviceruntime environment.

Figure 9 Starting the Web Services Creation Wizard from the ABAP Workbench

Figure 10 Defining the Virtual Interface

Figure 11 Creating the Web Service Definition

Subscribe today. Visit www.SAPinsider.com.

Advanced Web ServiceFeaturesWith SAP Web AS 6.40, a couple oftools and wizards are available toinvestigate the client side of the Webservices programming paradigm: webservice client proxy generation andtools for creating and accessing UDDIdirectories.

Creating Proxies for Web Services

Developer Studio includes a projectwizard that lets you create a deploy-able or standalone proxy for a givenWeb service (see Figure 13). First,specify a name for the proxy and aJava package name to store the gener-ated proxy classes.Then, select a Webservice by specifying its WSDL orURL, or by picking one from the WebService Navigator. Finally, deploy theproxy to the J2EE engine in an enter-prise archive.

Later you can develop a J2EEproject and let it reference the Webservices client API that was generatedin the Web service proxy creationprocess.The online documentation athttp://help.sap.com provides detailedsteps for how to work this out.

Setting Up Your Own UDDI Clientand Server

Major software vendors currentlyoperate their own public UDDIs, butany SAP Web Application Server canbe configured to offer UDDI clientand server capabilities.The VisualAdministrator in SAP Web AS providesthe means to set up the UDDI clientand UDDI server:

■ The UDDI client in the SAP Web ASis a Web application. You will find itsmain screen on the SAP Web AShomepage after installation. It letsyou browse existing UDDI registriesand add new Web service entities.

■ The UDDI server capabilities maintain UDDI definitions in the

underlying SAP Web AS database.See http://help.sap.com for details.

ConclusionWeb services offer an easy yetpowerful way to transform your busi-ness software into service-orientedapplications, and will form the founda-tion for semantic interoperability thatsupports enterprise-scale applications.SAP Web Application Server 6.40 nowoffers a rich set of tools and wizardsto explore the potential of Web serv-ices from a development perspective tobuild new applications on top of SAPNetWeaver’s Web services portfolio.Not only do these tools reflect anEnterprise Services Architectureframework, but they also allow devel-opers to more easily design custom

applications built with a standardizedWeb services-oriented approach.

For details and documentation onbuilding Web services in the SAPNetWeaver Developer Studio, visitthe online documentation inside theDeveloper Studio, or at SAP’s DeveloperNetwork (http://sdn.sap.com). Formore information on Web services in theABAP stack, visit http://help.sap.com.And for an overview of ESA, please seewww.sap.com/esa.

Karl Kessler joined SAP in 1992. He is the

Product Manager of the SAP NetWeaver foun-

dation including SAP Web Application Server,

Web Dynpro, ABAP Workbench, and SAP

NetWeaver Developer Studio, and is responsible

for all rollout activities. You can reach him via

email at karl.kessler@sap.com.

Figure 12 Releasing the Web Service

Figure 13 Project Wizard in the SAP NetWeaver Developer Studio

Subscribe today. Visit www.SAPinsider.com.