Where WS Fits in Your Application
Figure 16-6 shows the place where the web service layer actually fits into your application. The web service layer provides a compatibility layer that understands XML and provides a bridge between the XML-based consumers to the actual object oriented based service layer in your application.
Figure 16-6. Web service layer in your application
Spring Web Service (Spring WS)
The topics in this section will examine how Spring Framework comes into the picture in the world of web services.
Why Spring WS
Spring Web Services is a product from Spring community to develop the web services in easy and maintainable fashion. Some of the pressing reasons which based on which Spring WS should be the right choice of web service solution in your application is as summarized below:
- Spring covers almost all areas of Web Service specifications. Spring’s power of integrating and utilizing existing popular libraries where they are strong makes it adaptable and its ability to take in the advantage leveraging these libraries. Due to this plugging in capability it allows to plug in existing libraries according to requirement of your application.
- Capability to support wide range of XML API’s for handling XML messages by mere plugging onto the Spring Framework makes it very strong in various situations. Support ranging from JAXP API’s such as DOM (Document Object Model), SAX (Simple API for XML) and StAX (Streaming API for XML) along with other open-source libraries like JDOM, dom4j, XOM (XML Object Model). Support for XML marshaling technologies like JiBX, JAXB (Java Architecture for XML Binding), Castor, XMLBeans and XStream is also a big plus while using Spring WS.
- Spring WS provides security to web services in a highly configurable fashion. It allows you to sign SOAP messages, encrypt and decrypt them, or authenticate against them. Primarily WSS4J is used for this but we can also leverage Spring Security as well.
- When using Spring WS, you tend to do things in the Spring style of application development. Having come all the way up to Chapter 16, you would now have a clear picture of the various advantages which Spring Framework provides. Some features are summarized below:
- Main client-side class, WebServiceTemplate offers an API similar to JdbcTemplate.
- XML marshaling support is completely independent of Web services.
- JMS support uses Spring’s Message Driven POJOs.
JAXP (Java API for XML Processing) is Java’s XML programming APIs. It provides the capability of parsing and validating XML documents. There are three basic parsing interfaces available:
DOM (Document Object Model)
SAX (Simple API for XML)
StAX (Streaming API for XML)
Web services can be developed following two main approaches:
- Contract Last – Using this approach, you first write the Java code and using this web service contract (WSDL) is generated for you by the framework.
- Contract First – Using this approach, you start with the web services contract (XML files) and using this Java implements the web service contract.
Spring Web Services supports only contract-first message oriented approach to create web services. The underlying complexities are completely abstracted away from developers but these details if required can be completely controlled by the developer in a configurable manner starting from the contract to the marshaling/un-marshaling details to the endpoint handling of the web service request. The following section gives more idea of this style of approach before delving deep into Spring WS as a whole.
Why Contract-first
So, why do Spring WS takes the contract-first approach for web service development? This section compares the two approaches and gives the various advantages which contract-first brings in table using which Spring leverages it web service development capability. They are summarized as below:
- Avoiding Object/XML (O/X) mapping issues – To derive a comparison it is believed that there are more problems converting Java objects to XML rather than from XML to Java Objects (Yes, I could be biased). This is mainly because there are fundamental differences between hierarchical languages like XML and XSD as compared to the graph model of Java. There are various Object-XML mapping issues which could arise and tacking all of it would be very difficult. For more detail read the official SpringSource Web Service documentation at http://static.springsource.org/spring-ws/sites/2.0/reference/html/why-contract-first.html
- Avoiding instability – In contract-last development style your web service contract (WSDL and your XSD) is generated from your Java contract (usually an interface). Each time you change your Java contract and redeploy it, there might be subsequent changes to the web service contract due to which you will have no guarantee that the contract stays constant for a period of time which is crucial for any enterprise making money by exposing services as web services. Not only that if due to any reason you would like to change the SOAP stack, you will have to generate the web service contract again from the Java contract as not all SOAP stacks generate the contracts in the same manner. Since these web service contract are used by you consumers every change in contract needs to be communicated and appropriate changes incorporates which can be potentially time consuming and expensive in nature. Any exposed web services success is attributed to the minimal number of changes in its contract over a period of time, which results in consumer confidence as well as less time and effort spend to maintenance of these web services.
- Improve performance – There is less guarantee when converting Java objects to XML as to what is the final contract generated and sent over the wire. Due to the dependency nature of Java, it could be that more objects are loaded onto the Java heap and converted into XML for generating the web service contract. These can result in high memory usage resulting in slow response, which can be devastating for a web service consumer. Using contract-first you avoid these unexpected operations as you create the exact XML which you would like to send it through the wire.
- XML Reusability – From the XML standpoint, writing your XML first can result in making use of good features provided by XML (like importing common definitions in other schemas and WSDL files), making sure that more reuse can be brought in reducing maintenance cost of these XML over a period of time.
- Versioning – Down the lane if you do have changes in contract of your web services, you can make the changes in the contract and can still allow the implementation part written in Java to support multiple versions of implementations as in contract-first there is loose coupling between the contract and the implementation.
Page Visitors: 11145
Tomcy John
Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023