The Next Generation of Web Services

Crystal .NET developers have enjoyed the ability to publish a Crystal Report as a web service for several years. For small deployments of unmanaged reports, tightly integrated into custom .NET applications, this is an appropriate and terrific capability. For larger deployments with a separate business intelligence (BI) infrastructure and managed report repository, this approach is not satisfactory because it is not cross-platform, does not scale, is inherently insecure, and does not expose the full range of BI services.

Prior to acquiring Crystal, Business Objects was a pioneer in BI web services, permitting customers to securely expose the BI catalog and reports themselves as web services in its v.5 product. After acquiring Crystal, Business Objects soon released Unified Web Services (UWS) 1.0, the next-generation web services implementation, with the BusinessObjects Crystal Integration Pack. UWS bridged the Crystal Enterprise 10 and Business Objects 6.5 enterprise infrastructures, providing a single "unified" façade. The integration pack implementation carries forward to XI, with a handful of improvements:

• Session Authenticate, create a session, close a session. XI adds support for LDAP authentication.

• BI Catalog Navigate folders, reports, office documents, program objects, and other repository objects. XI adds support for categories and personal categories.

• ReportEngine Viewing reports interactively, filling prompts and handling drilling. XI adds cluster readiness through optional use of Page Server (versus RAS).

These services follow the WS-Interoperability Basic Profile 1.0.

By the time this book goes to print, the next iteration of UWS will be nearing release. Enhancements will include

• BI Query Provides full access to the BusinessObjects metalayer providing a dynamic, but secure, ad hoc query gateway directly to Enterprise BI datasources.

• Microsoft Office sample applications Extraordinary sample applications for Microsoft Word and Excel have been built using the Microsoft Visual Studio Tools for Office (VSTO). These are designed to be extended by you, the customer and developer.

Consuming Web Services

Before continuing, it is important to mention that over the past year, Business Objects released a powerful XML data driver for Crystal Reports that permits writing reports off local and remote XML files. Likewise, it also parses XML documents from SOAP formatted messages returned by web services. Web service data sources are accessed through a Web Services Description Language (WSDL) endpointthe standard format for describing a web service. After specifying a WSDL, the driver enables you to select which service, port, and method you want to use. The XML web services driver is part of the standard Crystal Reports distribution. Be sure to check for updates on the Business Objects website.

Deciding to Use Web Services

It is perfectly reasonable to question the utility of having a web services API. After all, Business Objects provides full-featured Java and .NET APIs. In short, web service interfaces are different from traditional APIs in the following two ways:

• Non-Proprietary Transport How the application calls travel inside a machine or through the network that connects machines within your local network or wide area network to the public internet. Rather than using a proprietary network protocol and/or high or random port, web services use HTTP/SSL, typically over port 80 or 443 respectively.

• Non-Proprietary Format How the information is encoded so other programs can read it. Rather than using a proprietary, binary data format, web services use SOAP-formatted XML text messages exclusively.

There are several advantages to using web services. First, there are no transport-specific limitations that could prevent API-level access outside the machine, the local network, or the wide area network. The traditional BusinessObjects Enterprise client SDKs communicate with back-end services over IIOP (Corba), using a range of ports. By default, these number some 30 ports (not including Enterprise Performance Management (EPM) services), half of which are random high-ports defined at run-time. The challenge of connecting to the BusinessObjects Enterprise cluster from client SDK applications can be made easier by setting the request and port command switches.

By contrast, any API in the UWS SDK can be accessed over a single configurable port using TCP/IP, like any other website in your company. Often, this port is 80 or 443. With web services, any machine on the World Wide Web internet can invoke this applicationthus the name web service. Additionally, with UWS, there are no programming or platform-specific limitations that restrict the client application platform. Communication is accomplished by passing specially formatted text files back and forth.

Note

Firewall issues are particularly challenging for ubiquitous client applications such as Business Objects Live Office and the Crystal Reports full client report writer. Contact Business Objects technical support for help configuring your environment to support these applications.

On the flip-side, there are a number of disadvantages with using web service SDKs generally. The most commonly cited ones are performance and security.

With web services, performance is a concern because application calls are not just traveling from one CPU register to another, but rather out to the network card, through a network cable, routers, routers, firewalls, routers, firewalls, millions of criss-crossing spam emails, and back through routers and firewalls to the machine on the other end. This is experienced every day when surfing the Web; there is a noticeable lag or latency between requests. What if every time you typed a letter in Microsoft Word, the program locked up, went out to MSN.com, looked up the word you were typing, checked to see whether it was spelled properly, and then returned a yes or no before letting you continue typing? What if it couldn't just exchange with MSN.com a tiny 1 kb binary file containing the letters of the current word and a single method such as "check spelling" represented by a single code such as "CS," but rather had to send a verbose one-page text document with a header, body, and footer, and get one back in return, which it had to open and parse using loops and regular expressions?

Converting native calls to XML documents, sending them through the networking, and deserializing them on the other end takes many CPU cycles and time. Computer people say that this is a very costly or expensive process.

On this issue of security, how does one program know that the requestor is who he says he is? Just because anyone can reach a web service does not mean he should be able to reach it. The most common approach to solving this problem is to simply require people seeking access to provide a username/password credential and to encrypt traffic through an SSL tunnel so nobody can "snoop" on it and read that information. This approach is supported by Business Objects UWS. Certificates guarantee the physical address of the receiver and/or the sender. Emerging standards might resolve this quandary issue.

Service-Orientated Architecture Explained

As described above, finely grained calls to remotely hosted programs simply don't work. Microsoft would never dream of hosting the always-on Word spell checker remotely.

In fact, such approaches don't work in most distributed environments. Java programmers will remember what happened when "experts" ported their finely grained JavaBeans to EJB architectures: every getter and setter required a call over the network to the EJB server. No matter how much hardware you threw at these programs, they ran very slowly. Over time, programmers wised-up and built their objects locally before sending them over to the EJB server for processing or manipulation. Moreover, they began to bundle together objects and methods to perform on those objects so fewer network requests would be needed to get the job done. As interfaces became less object specific, they were no longer object oriented; they acted like commands of a prior generation of procedural languages.

The term service oriented was developed to describe this new approach generically. Service orientation is simply the idea that to facilitate efficient interoperability, especially in distributed environments, software applications should expose fewer, more functionally meaningful (but internally opaque) interfaces to other applications. Web services follow this approach and are increasingly synonymous with the service orientated architectures (SOA). Web services make their calls by passing around text messages and are therefore also called message oriented.

Note

A competing BI vendor has attempted to malign Business Objects Enterprise's CORBA-based architecture as compared with its new, web servicebased architecture. Although it is true that Business Objects services deployed through the Central Configuration Manager interact quite differently than do web services, the fact remains that web services are not well suited for the kinds of jobs for which BusinessObjects Enterprise uses CORBA. Although exposing an external web service interface makes sense, there are no compelling reasons to use web services internally. For inter-service communication (within the stack), the main concerns are that the engine performs quickly and reliably, is cross-platform, and scales linearly. Recent performance benchmarking emphatically validates the Business Objects architecture.

Object-Oriented and Message-Oriented APIs Compared

Because web service calls are so inefficient (bloated XML traveling over congested networks), API designers attempt to require a minimum number of them. Pseudo-code Table 32.1 compares (good) web services message-oriented APIs with traditional, locally accessed object-oriented APIs.

Table 32.1. Object Oriented and Web Service Oriented APIs Compared

Object-Oriented		Web Services Message-Oriented
Local:	Create root object.	Local:	Create XML data structure.
Local:	Call function A on root object. Return object 1.	Local:	Load parameter 1 into XML element 1.
Local:	Call function B on object 1. Return object 2.	Local:	Load parameter 2 into XML element 2.
Local:	Call function C on object 2. Return object 2.	Remote:	Submit entire XML data structure in a single WS method call.
	And so on.	Local:	Parse returned XML data structure into local objects and use them.

Adapted from Business Objects, Unified Web Services Developer's Guide, p. 14

Although this approach might seem unnatural to object-oriented programmers, it cuts down the number of remote calls, thereby increasing performance.

SOAP, WSDL, and UDDI

Web service requests are XML text provided in a standard format called Standard Object Access Protocol (SOAP). SOAP is a W3C standard that defines how web service messages are structured. Specifically, SOAP describes the header and footer "envelope" that surrounds the data being exchanged. Web Services Description Language (WSDL), also a W3C standard, refers to the structure of the XML documents that describe web services so applications know what arguments their SOAP requests should contain, what data they should expect in the response, and the network address of the service.

Although showing neither the full WSDL nor SOAP documents, Figure 32.1 shows how WSDL documents describe the data SOAP requests must contain and what they should expect back from the service in return.

Figure 32.1. WSDL-SOAP relationship example highlighting common usage.

To facilitate sharing these interface specifications, WSDLs are often published to a Universal Description, Discovery, and Integration (UDDI) directory service that itself has a well-known interface. Obviously, not every service would be published to the outside world.

These standard-based interfaces facilitate automated discovery and invocation of web services between software applications that know nothing about one another. Web services client applications, such as Cape Clear permit users to browse UDDI directories to identify web services of interest, download their WSDL interface files, and build a simple form through which a user can invoke a web service with the arguments the service expects and see a resulting data grid.

In the current implementation of UWS, it is possible to publish the three BI services to UDDI. Used together in sequencecreate a session, browse the catalog, and retrieve report datathese services do permit full access to assets in the BusinessObjects Enterprise repository. On the other hand, this implementation is like publishing a listing for the White Pages in the Yellow Pages; it's impossible to identify your BI assets from the Directory listing.

Customers might find it more useful to write a wrapper around these services that exposes a single report (including login, prompt, and formatting inputs) as a WSDL in a UDDI directory. Extend this with a publishing wizard for publishing WSDLs for all reports. With tools such as .NET Studio or Weblogic Workshop, this should not be difficult.