110 Chapter 5 Applications are not as flexibly
110 Chapter 5 Applications are not as flexibly extensible as we would like. With IIOP-based request messages, all parties must have complete type information because they are not able to demarshal messages otherwise. There is no skipping of unknown parts of a message in IIOP. These restrictions do not exist with interfaces written in XML and with XML messages. XML also enables you to write extensible specifications (after all, that s the X in XML): data types in interface definitions can contain extensibility points from the outset. These extensibility points make use of a wildcard any type and, optional elements in sequences, and so on. Future versions of a service, while still servicing the clients written to the original interface, may fill in complex data records in these places for the benefit of more current client applications. If your end of the application does not rely on it, you don t need to care. To summarize this approach more generally, you could say that Web Services leave many details open for mutual agreement between the parties that will be actually involved whereas other middleware systems, such as CORBA, have sought to define stricter, inherent semantics as part of their models. This means that to use Web Services successfully in practice, you have to fill in these details. It also means that there is more room for refinement and thus wider applicability. Implementing a Web Service The J2EE model for Web Services provides a seamless Java perspective on Web Services, both for the service implementations and its clients. The model is relatively simple to use and allows you to deal with SOAP in the same way you deal with RMI or RMI/IIOP, which is to entrust all the details to the lower transport layers and happily ignore them for your business logic. The first thing to note is that your Web Services, like your beans, are managed for you completely by the container. The JSR 921 specification Implementing Enterprise Web Services defines the programming model for Web Services. This specification uses the term port component for the server-side view of a Web Service. A port component is a portable Java implementation of a service interface (a port) and comprises a Java mapping of the service interface and an implementation bean. Port components are deployed into and live in containers. Writing a Web Service using EJB requires creating one or more port components as stateless session beans. This involves writing (and generating) some more XML descriptors. A big advantage of the way the Web Services programming model is defined is that you can also expose existing session beans as Web Services. This is what we will do in the remainder of this chapter. To leverage the large investments that we made in Chapter 3, we will take our HelloWorld session bean and make it available as a Web Service at no extra cost.
Please check our cheap domain web hosting services, our secret is fast and stable servers, dedicated 24/7 customer support, and many useful FREE bonuses.