Contents:
Next, the Order Items are forwarded to the Inventory Management System to determine whether they are in stock and what the likely delivery dates are. This information—the Item Availability—is returned. Processing: Determine whether the Purchase Order covers the items being ordered and what payment terms are required.
It is responsible for providing the following service: Inventory Management Service Input Message: A list of the items being ordered. Processing: Determines whether the items are in stock and when they will be available to ship. Output Message: A list of the items and their estimated ship dates— referred to as Item Availability. As indicated in Figure 2—1, the Inventory Management Service is implemented using. The Order Management System, pictured in the center of Figure 2—1, is described as an SOA composite application because it is a composite of the underlying services provided by the Purchase Order Service and the Inventory Management Service.
Notice that this Order Management System itself can be considered a service. In fact, to the sender of the Customer Order, it is treated exactly as any other service. Hence, using SOA, services can be composed of underlying services. For example, for the Order Management System to request authorization and payment terms from the Purchase Order System, it must know exactly what form that request should take.
It must also know how to encapsulate that request in a message with a format that can be received and understood by the Purchase Order Service. Although not required for SOA, Web Services provide a set of interface and messaging standards that facilitate building SOA applications in a platform-neutral manner. However, since both Java EE 5 and. NET support Web Services, it is possible to construct the Order Management by invoking those underlying applications using their Web Services interfaces.
Hence, each of the services pictured in Figure 2—1 is illustrated as being associated with a WSDL document. The input parameters are delivered to a Web service using a messaging structure. Likewise, the output parameters are received in a message.
SOA Using Java Web Services [Mark D. Hansen] on giuliettasprint.konfer.eu *FREE* shipping on qualifying offers. Expert Solutions and State-of-the-Art Code Examples. Mar 2, SOA Using Java Web Services / Mark D. Hansen. p. cm. Includes bibliographical references and index. ISBN (pbk.
SOAP messages can be exchanged over a variety of transports e. This is just a quick overview. That is how a basic Web Services framework i. To explain the roles of these various JSRs on the server side, the deployment and invocation of a service is traced using the numerical labels in Figure 2—2. This discussion now becomes much more detail-oriented, dropping down from the 10,foot SOA level to the foot level where the JWS standards start to be discussed in depth.
The shaded bars in Figure 2—2 illustrate which JSRs correspond to the various stages of the Web service deployment and invocation. A Port component can be packaged 3.
In subsequent chapters, the discussion drops down to the foot level and examines detailed coding examples. XML Parameters Chapter 8 provides an in-depth discussion of deployment. Moving to the top of Figure 2—2, this description now traces the invocation of the Web service deployed by the Port component described in step 1.
This mapping is described in detail in Chapter 6. This process is described in detail in Chapter 8. Setting up the endpoint is a function of the deployment subsystem in the WSPA. That is because in practice, there are a number of ways the client can get a WSDL description. It is a fairly nontrivial transformation that is discussed in detail in Chapter 4.
Next, the XML parameters are deserialized into Java parameters. This deserialization is handled by the JAXB runtime. Deserialization is controlled i. JAXB serialization and annotations are described in Chapter 5. This step maps to the serialization subsystem in the WSPA.
In the WSPA, this is a responsibility of the invocation subsystem. That is because annotations from each of these JSRs are used in these classes. The class that is invoked called the service implementation bean must be marked by a WS-Metadata annotation e.
The classes representing the parameter and return types most likely have many JAXB annotations. After the invocation, the steps in this process run in reverse. This serialization like the deserialization described in step 6 is controlled by the annotations on the Java return class. Some steps have been left out of this description e. However, it provides more than enough detail to convey an idea of what is going on inside the Java EE 5 container when a Web service 34 An Overview of Java Web Services is deployed and invoked.
As in the server-side description, the roles of these various JSRs are explained by tracing through the process of reading a WSDL and invoking a service following the numerical labels provided in Figure 2—3. The overlapping shaded areas in Figure 2—3 show where the various JSRs come into play on the client side.
Client-Side Invocation of a Web Service 1. Service class is used to provide the client view of the Web service to be invoked.
One of the Service. The run-time instance is implemented using Java proxy technology and is represented in Figure 2—3 as Proxy Instance. See Chapter 1, Section 1. Service getPort The parameters passed to the SEI method are instances of classes that are generated during creation of the SEI step 1. The SOAP response is processed in the reverse order. First, the handlers are applied. Lastly, the proxy instance returns a JAXB instance as the return value.
As you can see, the client-side process is a bit simpler than the serverside deployment and invocation. Chapter 6 focuses on the client-side details and goes through many programming examples showing how to invoke a Web service. However, this ease of use is paid for with functionality trade-offs. A good trade-off provides lots of ease of use with few limitations. For example, JSP 2. So, if you need to use SAX, you still can. A primary design goal of a Web Services platform should be to hide this complexity—particularly the deployment complexity—from the developer.
A tried-and-true approach to reducing that complexity is to simplify the problem by restricting its generality. JWS has several mechanisms that attempt to reduce complexity by imposing constraints on how Web Services are created and deployed. For example, in many cases using WS-Metadata annotations allows one to bypass the complex deployment descriptors required for deploying JAXRPC services, and instead simply annotate the class being deployed to describe how it should map to a Web service.
Using this approach, the JWS deployment subsystem generates the descriptors required by the container and Web Services platform. And if you want to publish SOA-style Web Services interfaces for existing Java classes using this approach, you are going to have to either create wrapper classes with the necessary annotations or add annotations to the existing classes.