- Designing Interoperability
- Publishing Enduring Web Services Contracts
- Effectively Using Business-Tier Systems
- Planning a Robust Production Environment
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning a Robust Production Environment
Enterprise-class web services require application servers to provide clustering, caching, transaction coordination, messaging, high-performance XML processing, database connection pooling, and other features that have made J2EE the de facto standard for enterprise computing. WebLogic Workshop is built on top of WebLogic Server. As a developer, you can automatically leverage much of the robustness of the WebLogic Server platform (see Figure 5.6).
In addition to leveraging the robust foundation provided by WebLogic server, you need to pay particular attention to security, scalability, peformance, and manageability to ensure a robust production environment.
Security
Securing the web services that you build is an important aspect of building enterprise-class web services. You can use traditional techniques such as two-way SSL. However, there is performance degradation using two-way SSL because the whole message will be encrypted even though only parts of it might need to be encrypted. For example, you might want to encrypt just the customer name, address, and credit-card information in a purchase order, not the purchase order items and their descriptions.
)
Figure
5.6 WebLogic Server
WS-Security secures the SOAP message. The OASIS Technical Committee has ratified a specification with a standard set of SOAP extensions that can be used when building secure web services to implement message content integrity and confidentiality.
WS-Security is controlled using policy files. One part of a WS-Security policy determines the security requirements for SOAP messages coming into a web service or web service control. This part of the policy determines the security mechanisms for an inbound SOAP message to pass the security gate. The other part of a WS-Security policy determines the security enhancements to be added to outgoing SOAP messages before they are sent out to the client. This part of the policy file determines the kinds of security mechanisms that a web service or a web service control adds to SOAP messages.
In WebLogic Workshop, WS-Security policies are configured in WSSE files, an XML file with the .wsse extension. The <wsSecurityIn> element describes the security requirements for incoming SOAP messages; the <wsSecurityOut> element describes the security enhancements added to outgoing SOAP messages.
To apply a WS-Security policy to a web service, add the annotations @jws:ws-security-service and @jws:ws-security-callback to the web service file. If the web service communicates synchronously with its clients, you need to use only the @jws:ws-security-service annotation. If the web service sends callbacks to its clients, you must use both annotations. The Web Service CallBack Protocol (WS-CallBack) specification consists of the CallBack SOAP header and an associated WSDL definition. WS-CallBack is used to dynamically specify where to send asynchronous responses to a SOAP request:
/** * @jws:ws-security-service file="MyWebServicePolicy.wsse" * @jws:ws-security-callback file="MyWebServicePolicy.wsse" */ public class MyWebService implements com.bea.jws.WebService
Scalability and Performance
Enterprise-class web services need to be scalable and to perform at an optimum level. WebLogic Server provides clustering, caching, transaction coordination, messaging, high-performance XML processing, and database connection pooling, which makes the web services running on it highly scalable. You can improve your performance by tuning the WebLogic Server and by using JRockit instead of Sun JVM as your JVM (covered in detail in Chapter 12, "Enhancing Performance of Web Services").
Manageability
Management of web services is extremely important in an enterprise-class implementation. You need to establish the way you want to manage your web services while designing your web services. This is crucial to the success of business operations. Applications today are increasingly distributed, complex, and integral to the enterprise. For example, fault analysis now often involves gathering and reporting information across many applications, services, and platforms. As applications have grown more complex, so have their manageability needs.
BEA WebLogic with HP's OpenView uses Java/J2EE management via JMX. To manage the web services, WebLogic Server leverages Java Management Extensions (JMX). JMX defines a standard for developing managed beans (MBeans). The first step is to develop the MBeans as a wrapper to your Java web service that you want to manage and monitor. Then you need to register this MBean in the WebLogic JMX Server. JMX Server is responsible for decoupling management applications from the managed resources. It is important to note that MBeans are always accessed via the methods of the MBeanServer interface.
HP enhances the WebLogic Server management world by providing a WebLogic Server–specific Smart Plug-In (SPI) module that integrates the management of the WebLogic Server and any associated applications that depend on it. This SPI integrates several sources of information into one screen. Simultaneously, it gathers data from any supplied MBeans, performs calculations on that data to be more meaningful to the end operator, and brings filtered application logging messages to bear on the management task
This provides highly desirable management integration. Many IT operations departments want to monitor the health of their computers, networks, application servers and any applications that depend on them from the same console and using the same familiar tools.
Web services manageability goes beyond Java/J2EE management via JMX. In practice, this means that IT operations can deploy and configure your application, monitor its health and performance, predict and reduce failure, and analyze, correct, and report failures. At the business level, this means that your enterprise users can do more than just monitor: They can control and adapt your web service based on management data received.
The importance of a standardized management model for web services has driven industry leaders in web services and management technologies and applications to form a technical committee in OASIS called the Web Services Distributed Management (WSDM) Technical Committee.
Web services manageability is defined by this committee as a set of capabilities for discovering the existence, availability, health, performance, and usage (as well as the control and configuration) of a web service within the web services architecture. This implies that web services can be managed using web services technologies.
Web Services Networking
Functions such as load balancing, failover, routing, and monitoring and access control can also be done by an intermediary (see Figure 5.7). This unburdens each producing and consuming entity of the web service. This intermediary can also do the function of translation, as with messaging protocols, formats of XML messages, and security standards. They can also manage versioning of web services by directing consumers of the web service to different versions. All web service messages are routed first to the intermediary, where network policy is enforced. This class of solutions is called web services networking. Blue Titan and Grand Central are two vendors that offer such a capability. We cover web services manageability in detail in Chapter 14, "Managing Web Services."
){kind=small}
Figure
5.7 Web services networks