How create and test Web services using SOAPUI

how to generate web services.xml and test web service visual studio and how to automate web services using soapui how to consume web service with java
Prof.SteveBarros Profile Pic
Prof.SteveBarros,United Kingdom,Teacher
Published Date:28-07-2017
Your Website URL(Optional)
Web Services Essentials Part I: Introduction to Web Services Chapter 1 - Introduction 5Web Services Essentials Chapter 1. Introduction Today, the principal use of the World Wide Web is for interactive access to documents and applications. In almost all cases, such access is by human users, typically working through Web browsers, audio players, or other interactive front-end systems. The Web can grow significantly in power and scope if it is extended to support communication between applications,from one program to another. - From the W3C XML ProtocolWorking Group Charter Welcome to the world of web services. This chapter will ground you in the basics of web service terminology and architecture. It does so by answering the most common questions, including: • What exactly is a web service? • What is the web service protocol stack? • What is XML messaging? Service description? Service discovery? • What are XML-RPC, SOAP, WSDL, and UDDI? How do these technologies complement each other and work together? • What security issues are unique to web services? • What standards currently exist? 1.1 Introduction to Web Services A web service is any service that is available over the Internet, uses a standardized XML messaging system, and is not tied to any one operating system or programming language. (See Figure 1-1 .) Figure 1-1. A basic web service There are several alternatives for XML messaging. For example, you could use XML Remote Procedure Calls (XML-RPC) or SOAP, both of which are described later in this chapter. Alternatively, you could just use HTTP GET/POST and pass arbitrary XML documents. Any of these options can work. (See Figure 1-2.) 6Web Services Essentials Figure 1-2. XML messaging for web services Although they are not required, a web service may also have two additional (and desirable) properties: • A web service should be self-describing. If you publish a new web service, you should also publish a public interface to the service. At a minimum, your service should include human-readable documentation so that other developers can more easily integrate your service. If you have created a SOAP service, you should also ideally include a public interface written in a common XML grammar. The XML grammar can be used to identify all public methods, method arguments, and return values. • A web service should be discoverable. If you create a web service, there should be a relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism whereby interested parties can find the service and locate its public interface. The exact mechanism could be via a completely decentralized system or a more logically centralized registry system. To summarize, a complete web service is, therefore, any service that: • Is available over the Internet or private (intranet) networks • Uses a standardized XML messaging system • Is not tied to any one operating system or programming language • Is self-describing via a common XML grammar • Is discoverable via a simple find mechanism 1.1.1 The Web Today: The Human-Centric Web To make web services more concrete, consider basic e-commerce functionality. For example, Widgets, Inc. sells parts through its web site, enabling customers to submit purchase orders and check on order status. To check on the order status, a customer logs into the company web site via a web browser and receives the results as an HTML page. (See Figure 1-3.) 7Web Services Essentials Figure 1-3. The human-centric Web This basic model illustrates a human-centric Web, where humans are the primary actors initiating most web requests. It also represents the primary model on which most of the Web operates today. 1.1.2 Web Services: The Application-Centric Web With web services, we move from a human-centric Web to an application-centric Web. This does not mean that humans are entirely out the picture It just means that conversations can take place directly between applications as easily as between web browsers and servers. For example, we can turn the order status application into a web service. Applications and agents can then connect to the service and utilize its functionality directly. For example, an inventory application can query Widgets, Inc. on the status of all orders. The inventory system can then process the data, manipulate it, and integrate it into its overall supply chain management software. (See Figure 1-4.) Figure 1-4. The application-centric Web There are numerous areas where an application-centric Web could prove extremely helpful. Examples include credit card verification, package tracking, portfolio tracking, shopping bots, currency conversion, and language translation. Other options include centralized repositories for personal information, such as Microsoft's proposed .NET MyServices project. .NET MyServices aims to centralize calendar, email, and credit card information and to provide web services for sharing that data. 8Web Services Essentials Web Services and the Semantic Web Tim Berners-Lee, the original inventor of the Web, has recently argued for a "Semantic Web." The Semantic Web vision is application-centric, and shares many of the same ideas as web services. In fact, at the first W3C conference on web services, Berners-Lee stated that web services are an actualization of the Semantic Web vision. For an overview of the Semantic Web, see Berners-Lee's article in Scientific American: 1.1.3 The Web Services Vision: The Automated Web An application-centric Web is not a new notion. For years, developers have created CGI programs and Java servlets designed primarily for use by other applications. For example, companies have developed credit card services, search systems, and news retrieval systems. The crucial difference is that most of these systems consisted of ad hoc solutions. With web services, we have the promise of some standardization, which should hopefully lower the barrier to application integration. The web service architecture provides an interesting alternative for drastically decoupling presentation from content. For example, a site could consist of nothing but container pages that pass parameters to the real logic via SOAP or XML-RPC. This makes it easy to change presentation and also lets humans and computers "share" a single web service. In the long term, web services also offer the promise of the automated Web. If services are easily discoverable, self-describing, and stick to common standards, it is possible to automate application integration. Some in the industry have referred to this as "just-in- time" application integration. For example, consider the case of MegaElectric (ME). ME wants to buy parts from Widgets, Inc. and also wants to seamlessly integrate order status into a unified inventory system. At some point in the future, ME will be able to buy software that automates this entire process. Here's how it might work (refer to Figure 1-5): 1. The inventory application wakes up and connects to a centralized directory of web services: "Does Widgets, Inc. provide an order status service?" The directory returns information on Widgets, Inc.'s service and includes a pointer to the service description. 2. The inventory application connects to Widgets, Inc. and retrieves the service description. 3. The service description file includes complete details about how to connect to the specified service. The inventory application can therefore automatically invoke the order status service. 9Web Services Essentials Figure 1-5. The automated Web Is it possible to automate this process using existing web services technology? Not quite: only parts of the process can currently be automated. For example, as we will see in Chapter 9, it is possible to create Java programs that query service registries. Understanding the results and choosing which service to actually use, however, still requires some human intervention. It is also possible to automatically invoke a service, based on a service description. For example, as we will see in Chapter 6, many automatic invocation tools already exist and work extremely well. Even if all these steps could be automated, there is currently no mechanism for automating business relationships. For example, current service descriptions do not cover guarantees on pricing, delivery schedules, or legal ramifications if deliveries are not made. Given a service description, you also cannot assume that the service is bug-free or that the service is available 100 percent of the time. These types of issues are not easily solved and are not easily automated. Completely automated web services and "just-in-time" application integration may therefore never be realized. Nonetheless, current web service technology does take us one step closer, and does enable us to automate portions of the process. 1.1.4 The Industry Landscape There are currently many competing frameworks and proposals for web services. The three main contenders are Microsoft's .NET, IBM Web Services, and Sun Open Net Environment (ONE). While each of these frameworks has its own particular niche and spin, they all share the basic web service definition and vision put forth here. Furthermore, all of the frameworks share a common set of technologies, mainly SOAP, WSDL, and UDDI. Rather than focusing on one particular implementation or framework, this book focuses on common definitions and technologies. Hopefully, this will better equip you to cut through the marketing hype and understand and evaluate the current contenders. 1.2 Web Service Architecture There are two ways to view the web service architecture. The first is to examine the individual roles of each web service actor; the second is to examine the emerging web service protocol stack. 10Web Services Essentials 1.2.1 Web Service Roles There are three major roles within the web service architecture: Service provider This is the provider of the web service. The service provider implements the service and makes it available on the Internet. Service requestor This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request. Service registry This is a logically centralized directory of services. The registry provides a central place where developers can publish new services or find existing ones. It therefore serves as a centralized clearinghouse for companies and their services. Figure 1-6 shows the major web service roles and how they interact with each other. Figure 1-6. Web service roles 1.2.2 Web Service Protocol Stack A second option for viewing the web service architecture is to examine the emerging web service protocol stack. The stack is still evolving, but currently has four main layers. Following is a brief description of each layer. Service transport This layer is responsible for transporting messages between applications. Currently, this layer includes hypertext transfer protocol (HTTP), Simple Mail Transfer Protocol (SMTP), file transfer protocol (FTP), and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP). 11Web Services Essentials XML messaging This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this layer includes XML-RPC and SOAP. Service description This layer is responsible for describing the public interface to a specific web service. Currently, service description is handled via the Web Service Description Language (WSDL). Service discovery This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via Universal Description, Discovery, and Integration (UDDI). As web services evolve, additional layers may be added, and additional technologies may be added to each layer. Figure 1-7 summarizes the current web service protocol stack. Each layer is described in detail later in this book. Figure 1-7. Web service protocol stack 1.2.3 Architectural Snapshot: The IBM Web Services Browser To gain a high-level understanding of how the protocol stack actually works, try out the IBM Web Services Browser. The browser enables you to search for existing services, view their service descriptions, and automatically invoke those services. This lets you see each layer within the protocol stack without actually writing any code. To get started, open a browser and go to You should see the screen depicted in Figure 1-8. In the righthand pane, you can search a centralized registry for existing web services. (The registry actually uses UDDI, but don't get too caught up in the details just yet.) Within the Search box, type "IBM Web Services" and click Search. IBM will search the centralized directory for you and display all matching results in the left pane. Select the last folder, entitled IBM Web Services TestArea, and you will see a list of available web services. (See Figure 1-9.) 12Web Services Essentials Figure 1-8. The IBM Web Services browser Figure 1-9. Results of web service search Figure 1-10. Details of the IBM weather service 13Web Services Essentials Click on GetWeatherService, and the right pane will display specific details about the service. (See Figure 1-10.) The data includes binding points, which indicate URLs for actually connecting to the service, and service description files that explain how to interface with the service. (These are WSDL files, but again, don't get too caught up in the details just yet.) Click the View Page link in the left pane. The right pane will now show a simple user interface for the weather service. Select a city and state, and IBM will automatically invoke the service and display the current weather conditions. (See Figure 1-11.) Figure 1-11. Invoking the IBM weather service If you pick another service, the service is added to the bottom of the right pane. For example, Figure 1-12 shows the stock quote service and the weather service bundled together. Figure 1-12. Multiple web services on a single page 14Web Services Essentials The IBM browser does a good job of illustrating web services in action and highlighting the main layers within the protocol stack. It also does a good job of illustrating the potential of "just-in-time" application integration. Each service basically acts as an individual building block, and you can continue stacking more and more services to the same page. Best of all, you can do so without writing a single line of code 1.3 XML Messaging XML has exploded onto the computing scene in recent years. It has gained rapid acceptance because it enables diverse computer systems to share data more easily, regardless of operating system or programming language. There are dozens of XML tools, including parsers and editors that are available for nearly every operating system and every programming language, including Java, Perl, Python, C, C, C++, and Ruby. When developers decided to build a web service messaging system, XML was therefore a natural choice. There are two main contenders for XML messaging: XML-RPC and SOAP. The following sections provide descriptions of both protocols. 1.3.1 XML-RPC XML-RPC is a simple protocol that uses XML messages to perform RPCs. Requests are encoded in XML and sent via HTTP POST. XML responses are embedded in the body of the HTTP response. Because XML-RPC is platform-independent, it allows diverse applications to communicate. For example, a Java client can speak XML-RPC to a Perl server. To gain a high-level understanding of XML-RPC, consider a simple weather service. The service expects a zip code and returns the current temperature for the area. Here is a sample XML-RPC request to the weather service (HTTP headers omitted): ?xml version="1.0" encoding="ISO-8859-1"? methodCall methodNameweather.getWeather/methodName params paramvalue10016/value/param /params /methodCall The request consists of a simple methodCall element that specifies the method name and any method parameters. Here is a sample XML-RPC response from the weather service: ?xml version="1.0" encoding="ISO-8859-1"? methodResponse params param valueint65/int/value /param /params /methodResponse The response consists of a single methodResponse element that specifies the return value. In this case, the return value is specified as an integer. 15Web Services Essentials XML-RPC is the easiest way to get started with web services. In many ways, it is simpler than SOAP and easier to adopt. However, unlike SOAP, XML-RPC has no corresponding service description grammar. This prevents automatic invocation of XML-RPC services - a key ingredient for enabling just-in-time application integration. More details of XML- RPC are covered in Chapter 2. 1.3.2 SOAP SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems, and can be delivered via a variety of transport protocols, the main focus of SOAP is RPCs transported via HTTP. Like XML-RPC, SOAP is platform-independent and therefore enables diverse applications to communicate. To gain a high-level understanding of SOAP, let's revisit our simple weather service. Here is a sample SOAP request (HTTP headers omitted): ?xml version='1.0' encoding='UTF-8'? SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:xsi="" xmlns:xsd="" SOAP-ENV:Body ns1:getWeather xmlns:ns1="urn:examples:weatherservice" SOAP-ENV:encodingStyle="" zipcode xsi:type="xsd:string"10016/zipcode /ns1:getWeather /SOAP-ENV:Body /SOAP-ENV:Envelope As you can see, the SOAP request is slightly more complicated than the XML-RPC request. It makes use of both XML namespaces and XML Schemas. As in XML-RPC, however, the body of the SOAP request specifies both a method name and a list of parameters. Here is a sample SOAP response from the weather service: ?xml version='1.0' encoding='UTF-8'? SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:xsi="" xmlns:xsd="" SOAP-ENV:Body ns1:getWeatherResponse xmlns:ns1="urn:examples:weatherservice" SOAP-ENV:encodingStyle="" return xsi:type="xsd:int"65/return /ns1:getWeatherResponse /SOAP-ENV:Body /SOAP-ENV:Envelope The response indicates a single integer return value. Full details of SOAP are discussed in Chapter 3. 16Web Services Essentials 1.4 Service Description: WSDL WSDL currently represents the service description layer within the web service protocol stack. In a nutshell, WSDL is an XML grammar for specifying a public interface for a web service. This public interface can include information on all publicly available functions, data type information for all XML messages, binding information about the specific transport protocol to be used, and address information for locating the specified service. WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services. Example 1-1 provides a sample WSDL file. This file describes the public interface for the weather service we examined previously. Obviously, there are many details to consider when looking at the example. For now, just focus on two points. First, the message elements specify the individual XML messages that are transferred between computers. In this case, we have a getWeatherRequest and a getWeatherResponse. Second, the service element specifies that the service is available via SOAP at http://localhost:8080/soap/servlet/rpcrouter. Example 1-1. WeatherService.wsdl ?xml version="1.0" encoding="UTF-8"? definitions name="WeatherService" targetNamespace="" xmlns="" xmlns:soap="" xmlns:tns="" xmlns:xsd="" message name="getWeatherRequest" part name="zipcode" type="xsd:string"/ /message message name="getWeatherResponse" part name="temperature" type="xsd:int"/ /message portType name="Weather_PortType" operation name="getWeather" input message="tns:getWeatherRequest"/ output message="tns:getWeatherResponse"/ /operation /portType binding name="Weather_Binding" type="tns:Weather_PortType" soap:binding style="rpc" transport=""/ operation name="getWeather" soap:operation soapAction=""/ input soap:body encodingStyle="" namespace="urn:examples:weatherservice" use="encoded"/ /input output soap:body encodingStyle="" namespace="urn:examples:weatherservice" use="encoded"/ /output /operation /binding 17Web Services Essentials service name="Weather_Service" documentationWSDL File for Weather Service/documentation port binding="tns:Weather_Binding" name="Weather_Port" soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/ /port /service /definitions Using WSDL, a client can locate a web service and invoke any of the publicly available functions. With WSDL-aware tools, this process can be entirely automated, enabling applications to easily integrate new services with little or no manual code. For example, IBM has recently released the IBM Web Services Invocation Framework (WSIF). Using WSIF, you can specify the WeatherService.wsdl file and automatically invoke the service described. For example, the following command line: java clients.DynamicInvoker http://localhost:8080/wsdl/WeatherService.wsdl getWeather 10016 generates the following output: Reading WSDL document from 'http://localhost:8080/wsdl/WeatherService.wsdl' Preparing WSIF dynamic invocation Executing operation getWeather Result: temperature=65 Done WSDL and WSDL invocation tools are covered in Chapter 6. 1.5 Service Discovery: UDDI UDDI currently represents the discovery layer within the web service protocol stack. UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical specification for publishing and finding businesses and web services. At its core, UDDI consists of two parts. First, UDDI is a technical specification for building a distributed directory of businesses and web services. Data is stored within a specific XML format. The UDDI specification includes API details for searching existing data and publishing new data. Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. Launched in May 2001 by Microsoft and IBM, the UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register itself and its services. The data captured within UDDI is divided into three main categories: White pages This category includes general information about a specific company; for example, business name, business description, and address. 18Web Services Essentials Yellow pages This category includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies. Green pages This category includes technical information about a web service (a pointer to an external specification and an address for invoking the web service). Figure 1-13 shows a sample screenshot of the Microsoft UDDI site. From this site, you can easily publish your own services or search for existing ones. Figure 1-13. The Microsoft UDDI site: searching for XMethods, Inc. Full details on UDDI are available in Chapter 7. 1.6 Service Transport The bottom of the web service protocol stack is service transport. This layer is responsible for actually transporting XML messages between two computers. 1.6.1 HTTP Currently, HTTP is the most popular option for service transport. HTTP is simple, stable, and widely deployed. Furthermore, most firewalls allow HTTP traffic. This allows XML- RPC or SOAP messages to masquerade as HTTP messages. This is good if you want to easily integrate remote applications, but it does raise a number of security concerns. (See Section 1.7 later in this chapter.) 19Web Services Essentials While HTTP does get the job done, a number of critics have argued that HTTP is not ideal for web services. In particular, HTTP was originally designed for remote document retrieval, and is now being reworked to support RPCs. RPCs demand greater efficiency and reliability than document retrieval does. There are some developers who argue that HTTP is enough of a foundation for messaging and that the layers above HTTP are as much a problem as a solution. For some of this perspective, called Representational State Transfer, or REST, see 1.6.2 BEEP One promising alternative to HTTP is the Blocks Extensible Exchange Protocol (BEEP). BEEP is a new IETF framework of best practices for building new protocols. In particular, BEEP is layered directly on TCP and includes a number of built-in features, including an initial handshake protocol, authentication, security, and error handling. Using BEEP, one can create new protocols for a variety of applications, including instant messaging, file transfer, content syndication, and network management. SOAP is not tied to any specific transport protocol. In fact, you can use SOAP via HTTP, SMTP, or FTP. One promising idea is therefore to use SOAP over BEEP. Doing so provides several performance advantages over HTTP. Specifically, BEEP does require an initial handshake, but after the handshake, the protocol requires only 30 bytes of overhead 1 for each message, making it much more efficient than HTTP. Furthermore, BEEP supports multiple channels of data over the same connection, providing extra efficiency over HTTP. 1 The overhead for each HTTP message is dependent on numerous factors, including the requested URL, the type of client used, and the type of server information returned within the HTTP response. Overhead for typical browser and SOAP requests can therefore vary from approximately 100 to 300 bytes for each message. A recent proposal for using SOAP over BEEP is available at: Another promising alternative to HTTP is Reliable HTTP (HTTP-R). HTTP-R is being developed by IBM, which plans to submit its proposal to the Internet Engineering Task Force (IETF). HTTP-R enhances HTTP to ensure message reliability. For example, HTTP-R ensures that a message gets delivered only once or gets reported as undeliverable. This is particularly critical for e-commerce services, such as electronic ordering systems and inventory management. A primer on HTTP-R is available from IBM at http://www- 20Web Services Essentials 1.7 Security Considerations Security is critical to web services. However, neither the XML-RPC nor SOAP specifications make any explicit security or authentication requirements. Furthermore, the web services community has proposed numerous security frameworks and protocols, but has yet to reach consensus on a comprehensive security package. Very broadly, there are three specific security issues: confidentiality, authentication, and network security. 1.7.1 Confidentiality If a client sends an XML request to a server, can we ensure that the communication remains confidential? Fortunately, both XML-RPC and SOAP run primarily on top of HTTP, and XML communications can therefore be encrypted via the Secure Sockets Layer (SSL). SSL is a proven technology, is widely deployed, and is therefore a very viable option for encrypting messages. However, a key element of web services is that a single web service may consist of a chain of applications. For example, one large service might tie together the services of three other applications. In this case, SSL is not adequate; the messages need to be encrypted at each node along the service path, and each node represents a potential weak link in the chain. Currently, there is no agreed-upon solution to this issue, but one promising solution is the W3C XML Encryption Standard. This standard provides a framework for encrypting and decrypting entire XML documents or just portions of an XML document, and it is likely to receive widespread industry support. Information on the XML Encryption Standard is available at 1.7.2 Authentication If a client connects to a web service, how do we identify the user? And is the user authorized to use the service? One solution is to leverage HTTP authentication. HTTP includes built-in support for Basic and Digest authentication, and services can therefore be protected in much the same manner as HTML documents are currently protected. Most security experts, however, agree that HTTP authentication is a relatively weak option. As with encryption, there is no clear consensus on a strong authentication scheme, but there are several frameworks under consideration. The first is SOAP Security Extensions: Digital Signature (SOAP-DSIG). DSIG leverages public key cryptography to digitally sign SOAP messages. This enables the client or server to validate the identity of the other party. DSIG has been submitted to the W3C and is available at 21Web Services Essentials Second, the Organization for the Advancement of Structured Information Standards (OASIS) is working on the Security Assertion Markup Language (SAML). SAML is designed to facilitate the exchange of authentication and authorization information between business partners. Information is available online at http://www.oasis- In a related effort, several companies have put forth the XML Key Management Services (XKMS). XKMS defines a series of services for distributing and managing public keys and certificates. The protocol itself is built on SOAP and WSDL, and it is therefore an excellent example of a web service. The specification is available online at 1.7.3 Network Security In June 2000, Bruce Schneier, a noted computer expert, flatly stated that "SOAP is going 2 to open up a whole new avenue for security vulnerabilities." Schneier's basic argument is that HTTP was made for document retrieval. Extending HTTP via SOAP enables remote clients to invoke commands and procedures, something that firewalls are explicitly designed to prevent. 2 Crypto-Gram Newsletter, June 15, 2000 ( You could argue that CGI applications and servlets present the same security vulnerabilities. After all, these programs also enable remote applications to invoke commands and procedures. As SOAP becomes more widely deployed, however, Schneier's argument becomes more compelling. There is currently no easy answer to this problem, and it has been the subject of much debate. For now, if you are truly intent on filtering out SOAP or XML-RPC messages, one possibility is to filter out all HTTP POST requests that set their content type to text/xml (a requirement of both specifications). Another alternative is to filter for the SOAPAction HTTP header attribute (see Chapter 3 for details). Firewall vendors are also currently developing tools explicitly designed to filter web service traffic. 1.8 All Together Now Once you understand each layer in the web service protocol stack, the next important step is to understand how all the pieces fit together. There are two ways of approaching the issue, either from the service requestor perspective or the service provider perspective. In this section, we examine both perspectives and look at a typical development plan for each. 22Web Services Essentials 1.8.1 Service Request Perspective The service requestor is any consumer of web services. Here is a typical development plan for a service requestor: 1. First, you must identify and discover those services that are relevant to your application. This first step therefore usually involves searching the UDDI Business Directory for partners and services. 2. Once you have identified the service you want, the next step is to locate a service description. If this is a SOAP service, you are likely to find a WSDL document. If this is an XML-RPC service, you are likely to find some human-readable instructions for integration. 3. Third, you must create a client application. For example, you may create an XML- RPC or SOAP client in the language of your choice. If the service has a WSDL file, you also have the option of automatically creating client code via a WSDL invocation tool. 4. Finally, run your client application to actually invoke the web service. A snapshot of the service requestor perspective is provided in Figure 1-14. Figure 1-14. Developing web services: the service requestor perspective 1.8.2 Service Provider Perspective The service provider is any provider of one or more web services. Here is a typical development plan for a service provider: 1. First, you must develop the core functionality of your service. This is usually the hardest part, as your application may connect to databases, Enterprise JavaBeans™ (EJBs), COM objects, or legacy applications. 2. Second, you must develop a service wrapper to your core functionality. This could be an XML-RPC or a SOAP service wrapper. This is usually a relatively simple step, as you are merely wrapping existing functionality into a larger framework. 3. Next, you should provide a service description. If you are creating a SOAP application, you should create a WSDL file. If you are creating an XML-RPC service, you should consider creating some human-readable instructions. 4. Fourth, you need to deploy the service. Depending on your needs, this could mean installing and running a standalone server or integrating with an existing web server. 5. Fifth, you need to publish the existence and specifications of your new service. This usually means publishing data to a global UDDI directory or perhaps a private UDDI directory specific to your company. 23

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.