Why would you want to use a Web service? They are flexible and supported on a number of platforms and can be implemented by using a number of languages. This chapter from BEA WebLogic Workshop 8.1 (by Albert J. Saganich, Jr., et al., Sams, 2004, ISBN: 0-672-32622-1) covers Web services concepts, SOA, SOAP, WSDL, and security.
Working with Web Services - Web Services Benefits for Service Developers (Page 2 of 9 )
Web services are a boon to service developers as well because they support a wide range of tools. Web services have the following characteristics:
They are supported on a number of application platforms (BEA, IBM, Microsoft, and the like).
They can be developed in many languages, including Java, C, C++, VB, C#, Perl, and others.
They can be run on various hardware platforms (mainframe, server, and handheld).
Functionality: Where Does It Belong? - WebLogic Workshop provides a simple, easy-to-use interface for creating controls, EJBs, and Web services. This ease of use is great for productivity, but is not without its problems.
With WebLogic Workshop, you can quickly write Web services that look exactly like controls, at least to the developer. Typically, a fair amount of business logic ends up in Web service methods. These methods aggregate data and apply business logic to form a result. For a simple bank fund-transferring Web service, for example, an important development point might be whether the code for the actual transfer should be in the developed Web service or perhaps in an EJB that can be accessed by the Web service and directly via a Web application.
Much debate rages about this aggregation. One camp is made up of those who believe that Web applications and Web services are basically the same thing—an interface to a service. Web applications can obviously be considered an interface; after all, people are the primary consumers of Web data today—with the key word being today, as a different use might be appropriate tomorrow. Web services, on the other hand, represent interfaces that are targeted at other computing entities. Although people might use a Web service directly, what's more likely is that another program would use the Web service. Therefore, Web services can be considered interfaces to services for applications, just as Web applications are interfaces to services for people.
If you accept this argument, you must reconsider how you develop Web services. With the arrival of Struts and the Model-View-Controller paradigm, architects have given considerable thought to separation of functionality. If you apply the same considerations to Web services, you must at least consider that they are really business-level application interfaces, much as a JSP is a human-level interface. If you accept this idea, you must consider whether a Web service is the correct place for business-level logic. Should Web services simply be presenters of logic, as JSPs are under the MVC paradigm?
I'm not going to draw any specific conclusions for you on this issue; instead, I'm offering some ideas you might consider as you build Web services:
Is functionality appropriate only for the Web service consumer?
Is functionality a business-level facade to a service that others can use?
Will other consumers use this service in the future?
Will users be located within the same application? Same LAN? Same WAN? Or broadly separated?
Can the functionality be implemented with an EJB or a control and consumed by Web services and Web application consumers?
Remember, Web services are a heavyweight answer to a problem. Before you choose a Web service, make sure the problem justifies the answer.
Figure 9.1 shows a conceptual model of how Web services work inside and outside WebLogic Server. The Web services runtime provides services to WebLogic Workshop applications consuming Web services via controls and makes Web services available to the outside world. Additionally, WebLogic Server 8.1 provides a UDDI server sitting on top of the runtime, supporting all the services of UDDI v2.0. The runtime, as well as traditional Web applications, uses traditional J2EE services as any application would. Other application servers or Web service clients can access Web services by using UDDI and WSDL directly or via controls.
Figure 9.1 -- WebLogic Server Web services model.
There are two ways a client application typically uses a Web service: by searching for it or by static access. In the first method, a client searches for a Web service that fits a particular set of characteristics and then goes through a number of steps to access the service. Figure 9.2 shows all the steps required to search for, find, bind to, and use a Web service. Second (and this method is more typical), a client already knows the location and interfaces to a Web service and can avoid steps 1 to 3 shown in Figure 9.2.
This is the general process after a developer creates a Web service (the numbers correspond to the labels in Figure 9.2):
The created service is published to a UDDI registry, such as the embedded WLS UDDI Server or another one on the Web.
Potential Web service clients contact a repository and use queries to determine what Web services exist.
The repository then returns a response in the form of metadata, including interface definitions and service providers.
The client then binds to the service, effectively registering its interest in using it.
The client begins using the service.
Figure 9.2 -- Web services life cycle overview.
There is nothing stopping WebLogic Workshop clients from accessing Web services exactly as shown in Figure 9.2. However, clients usually know exactly what Web services they want to access and simply access them at runtime via a control wrapper.
This chapter is from BEA WebLogic Workshop 8.1, by Albert J. Saganich, Jr., et al. (Sams, 2004, ISBN: 0-672-32622-1). Check it out at your favorite bookstore today.