Intitially WebServices were just considered as the other ways to make RPC(Remote Procedure calls),but later it was found that Web Services is far more than that.When interoperability with other platforms is important, it is often better to send encapsulated XML documents, containing all the data necessary to process the request.XML should be considered the platform neutral representation of data.When developing or using Web services, the focus should be on this XML, and not on Java.
Spring Web Services facilitates contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads. Spring-WS provides a powerful message dispatching framework, a WS-Security solution that integrates with your existing application security solution, and a Client-side API that follows the familiar Spring template pattern.
What is Spring Web Services?
Spring-WS is used to create the document driven Web Services.Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.
Advantage of Spring-WS:
Spring Web Services requires a standard Java 1.5 Runtime Environment. Java 1.6 is also supported. Spring-WS also requires Spring 3.0 or higher
Spring-WS requires number of modules.
1)spring-xml-2.1.1.RELEASE.jar:The XML module (spring-xml.jar) contains various XML support classes for Spring Web Services. This module is mainly intended for the Spring-WS framework itself, and not a Web service developers.
2)spring-ws-core-2.1.1.RELEASE.jar:The Core module (spring-ws-core.jar) is the central part of the Spring's Web services functionality. It provides the central WebServiceMessage and SoapMessage interfaces, the server-side framework, with powerful message dispatching, and the various support classes for implementing Web service endpoints; and the client-side WebServiceTemplate.
3)spring-ws-support-2.1.1.RELEASE.jar:The Support module (spring-ws-support.jar) contains additional transports (JMS, Email, and others).
4)spring-ws-security-2.1.1.RELEASE.jar:The Security package (spring-ws-security.jar) provides a WS-Security implementation that integrates with the core Web service package. It allows you to add principal tokens, sign, and decrypt and encrypt SOAP messages. Additionally, it allows you to leverage your existing Spring Security security implementation for authentication and authorization.
The following figure illustrates the Spring-WS modules and the dependencies between them. Arrows
indicate dependencies, i.e. Spring-WS Core depends on Spring-XML and the OXM module found in
Spring 3.
Note:When you download the Spring-WS,spring-ws-2.1.1.RELEASE-full.zip from spring website and extract it.you will see the following jars in the dist\modules folder.
Why Contract First?
When creating Web services, there are two development styles: Contract Last and Contract First
Contract Last:When using a contract-last approach, you start with the Java code, and let the Web service contract (WSDL, see sidebar) be generated from that.
What is WSDL?A WSDL is an XML file which defines WebServices.It specifies the location of the service and the operations (or methods) the service exposes.
Note: Spring-WS only supports Contract First style of developing Web Services.Below are the some reasons why Spring-WS supports only Contract First Approch only.
1) Object/XML Impedance Mismatch:At first glance, the O/X mapping problem appears simple: create an XML element for each Java object, converting all Java properties and fields to sub-elements or attributes. However, things are not as simple as they appear: there is a fundamental difference between hierarchical languages such as XML (and especially XSD) and the graph model of Java..To implement the Contract last we must have the perfect OXM approach.There are several issues in this OXM mapping.
XSD extensions: In Java, the only way to change the behavior of a class is to subclass it, adding the new behavior to that subclass. In XSD, you can extend a data type by restricting it: that is, constraining the valid values for the elements and attributes. For instance, consider the following example:
<simpleType name="AirportCode">
<restriction base="string">
<pattern value="[A-Z][A-Z][A-Z]"/>
</restriction>
</simpleType>
This type restricts a XSD string by ways of a regular expression, allowing only three upper case letters. If this type is converted to Java, we will end up with an ordinary java.lang.String; the regular
expression is lost in the conversion process, because Java does not allow for these sorts of extensions.
So bottom line from the above point is that if we define Webservice with the Contract -Last approch we would not be able to implement the this restriction in our web services.But if we use contract first approch we would be able to define the data restriction in XSD/WSDL.
Unportable types:One of the most important goals of a Web service is to be interoperable: to support multiple platforms such as Java, .NET, Python, etc. Because all of these languages have different class libraries, you must use some common, interlingual format to communicate between them. That format is XML, which is supported by all of these languages.
Because of this conversion, you must make sure that you use portable types in your service implementation.Consider, for example, a service that returns a java.util.TreeMap, like so:
public Map getFlights() {
// use a tree map, to make sure it's sorted
TreeMap map = new TreeMap();
map.put("KL1117", "Stockholm");
...
return map;
}
Undoubtedly, the contents of this map can be converted into some sort of XML, but since there is
no standard way to describe a map in XML, it will be proprietary. Also, even if it can be converted
to XML, many platforms do not have a data structure similar to the TreeMap. So when a .NET client
accesses your Web service, it will probably end up with a System.Collections.Hashtable, which
has different semantics.
Cyclic graphs
Imagine we have the following simple class structure
public class Flight {
private String number;
private List<Passenger> passengers;
// getters and setters omitted
}
public class Passenger {
private String name;
private Flight flight;
// getters and setters omitted
}
If we took a naive approach to converting this to XML,we will end up with something like
<flight number="KL1117">
<passengers>
<passenger>
<name>Arjen Poutsma</name>
<flight number="KL1117">
<passengers>
<passenger>
<name>Arjen Poutsma</name>
<flight number="KL1117">
<passengers>
<passenger>
<name>Arjen Poutsma</name>
...
One way to solve this problem is to use references to objects that were already marshalled, like so
<flight number="KL1117">
<passengers>
<passenger>
<name>Arjen Poutsma</name>
<flight href="KL1117" />
</passenger>
...
</passengers>
</flight>
This solves the recursiveness problem, but introduces new ones. For one, you cannot use an XML
validator to validate this structure. Another issue is that the standard way to use these references in
SOAP (RPC/encoded) has been deprecated in favor of document/literal (see WS-I Basic Profile [http://www.ws-i.org/Profiles/BasicProfile-1.1.html#SOAP_encodingStyle_Attribute]).
Contract-first versus Contract-last
Besides the Object/XML Mapping issues mentioned in the previous section, there are other reasons
for preferring a contract-first development style.
Fragility:
As mentioned earlier, the contract-last development style results in your web service contract (WSDL and your XSD) being generated from your Java contract (usually an interface). If you are using this approach, you will have no guarantee that the contract stays constant over time. Each time you change your Java contract and redeploy it, there might be subsequent changes to the web service contract. Aditionally, not all SOAP stacks generate the same web service contract from a Java contract. This means changing your current SOAP stack for a different one (for whatever reason), might also change your web service contract.
When a web service contract changes, users of the contract will have to be instructed to obtain the new contract and potentially change their code to accommodate for any changes in the contract.
Performance
When Java is automatically transformed into XML, there is no way to be sure as to what is sent across the wire. An object might reference another object, which refers to another, etc. In the end, half of the objects on the heap in your virtual machine might be converted into XML, which will result in slow response times.
Reusability
Defining your schema in a separate file allows you to reuse that file in different scenarios. If you define an AirportCode in a file called airline.xsd, like so:
<simpleType name="AirportCode">
<restriction base="string">
<pattern value="[A-Z][A-Z][A-Z]"/>
</restriction>
</simpleType>
You can reuse this definition in other schemas, or even WSDL files, using an import statement.
Spring Web Services facilitates contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads. Spring-WS provides a powerful message dispatching framework, a WS-Security solution that integrates with your existing application security solution, and a Client-side API that follows the familiar Spring template pattern.
What is Spring Web Services?
Spring-WS is used to create the document driven Web Services.Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.
Advantage of Spring-WS:
- Spring Concepts such as Dependency Injection can be used when we are developing Spring-WS.
- Spring WS makes best practices an easy practices.This includes practices such as the WS-I basic profile, Contract-First development,and having a loose coupling between contract and implementation.
- Powerful mappings. You can distribute incoming XML requests to any object, depending on
message payload, SOAP Action header, or an XPath expression. - XML API support. Incoming XML messages can be handled not only with standard JAXP APIs
such as DOM, SAX, and StAX, but also JDOM, dom4j, XOM, or even marshalling technologies. - Flexible XML Marshalling. The Object/XML Mapping module in the Spring Web Services
distribution supports JAXB 1 and 2, Castor, XMLBeans, JiBX, and XStream. And because it is a separate module, you can use it in non-Web services code as well. - Reuses your Spring expertise. Spring-WS uses Spring application contexts for all configuration,which should help Spring developers get up-to-speed nice and quickly. Also, the architecture of Spring-WS resembles that of Spring-MVC.
- Supports WS-Security. WS-Security allows you to sign SOAP messages, encrypt and decrypt them, or authenticate against them.
- Integrates with Acegi Security. The WS-Security implementation of Spring Web Services
provides integration with Acegi Security [http://acegisecurity.org]. This means you can use your existing Acegi configuration for your SOAP service as well. - Built by Maven. This assists you in effectively reusing the Spring Web Services artifacts in your own Maven-based projects.
- Apache license. You can confidently use Spring-WS in your project.
Spring Web Services requires a standard Java 1.5 Runtime Environment. Java 1.6 is also supported. Spring-WS also requires Spring 3.0 or higher
Spring-WS requires number of modules.
1)spring-xml-2.1.1.RELEASE.jar:The XML module (spring-xml.jar) contains various XML support classes for Spring Web Services. This module is mainly intended for the Spring-WS framework itself, and not a Web service developers.
2)spring-ws-core-2.1.1.RELEASE.jar:The Core module (spring-ws-core.jar) is the central part of the Spring's Web services functionality. It provides the central WebServiceMessage and SoapMessage interfaces, the server-side framework, with powerful message dispatching, and the various support classes for implementing Web service endpoints; and the client-side WebServiceTemplate.
3)spring-ws-support-2.1.1.RELEASE.jar:The Support module (spring-ws-support.jar) contains additional transports (JMS, Email, and others).
4)spring-ws-security-2.1.1.RELEASE.jar:The Security package (spring-ws-security.jar) provides a WS-Security implementation that integrates with the core Web service package. It allows you to add principal tokens, sign, and decrypt and encrypt SOAP messages. Additionally, it allows you to leverage your existing Spring Security security implementation for authentication and authorization.
The following figure illustrates the Spring-WS modules and the dependencies between them. Arrows
indicate dependencies, i.e. Spring-WS Core depends on Spring-XML and the OXM module found in
Spring 3.
Note:When you download the Spring-WS,spring-ws-2.1.1.RELEASE-full.zip from spring website and extract it.you will see the following jars in the dist\modules folder.
Why Contract First?
When creating Web services, there are two development styles: Contract Last and Contract First
Contract Last:When using a contract-last approach, you start with the Java code, and let the Web service contract (WSDL, see sidebar) be generated from that.
What is WSDL?A WSDL is an XML file which defines WebServices.It specifies the location of the service and the operations (or methods) the service exposes.
Note: Spring-WS only supports Contract First style of developing Web Services.Below are the some reasons why Spring-WS supports only Contract First Approch only.
1) Object/XML Impedance Mismatch:At first glance, the O/X mapping problem appears simple: create an XML element for each Java object, converting all Java properties and fields to sub-elements or attributes. However, things are not as simple as they appear: there is a fundamental difference between hierarchical languages such as XML (and especially XSD) and the graph model of Java..To implement the Contract last we must have the perfect OXM approach.There are several issues in this OXM mapping.
XSD extensions: In Java, the only way to change the behavior of a class is to subclass it, adding the new behavior to that subclass. In XSD, you can extend a data type by restricting it: that is, constraining the valid values for the elements and attributes. For instance, consider the following example:
<simpleType name="AirportCode">
<restriction base="string">
<pattern value="[A-Z][A-Z][A-Z]"/>
</restriction>
</simpleType>
This type restricts a XSD string by ways of a regular expression, allowing only three upper case letters. If this type is converted to Java, we will end up with an ordinary java.lang.String; the regular
expression is lost in the conversion process, because Java does not allow for these sorts of extensions.
So bottom line from the above point is that if we define Webservice with the Contract -Last approch we would not be able to implement the this restriction in our web services.But if we use contract first approch we would be able to define the data restriction in XSD/WSDL.
Unportable types:One of the most important goals of a Web service is to be interoperable: to support multiple platforms such as Java, .NET, Python, etc. Because all of these languages have different class libraries, you must use some common, interlingual format to communicate between them. That format is XML, which is supported by all of these languages.
Because of this conversion, you must make sure that you use portable types in your service implementation.Consider, for example, a service that returns a java.util.TreeMap, like so:
public Map getFlights() {
// use a tree map, to make sure it's sorted
TreeMap map = new TreeMap();
map.put("KL1117", "Stockholm");
...
return map;
}
Undoubtedly, the contents of this map can be converted into some sort of XML, but since there is
no standard way to describe a map in XML, it will be proprietary. Also, even if it can be converted
to XML, many platforms do not have a data structure similar to the TreeMap. So when a .NET client
accesses your Web service, it will probably end up with a System.Collections.Hashtable, which
has different semantics.
Cyclic graphs
Imagine we have the following simple class structure
public class Flight {
private String number;
private List<Passenger> passengers;
// getters and setters omitted
}
public class Passenger {
private String name;
private Flight flight;
// getters and setters omitted
}
If we took a naive approach to converting this to XML,we will end up with something like
<flight number="KL1117">
<passengers>
<passenger>
<name>Arjen Poutsma</name>
<flight number="KL1117">
<passengers>
<passenger>
<name>Arjen Poutsma</name>
<flight number="KL1117">
<passengers>
<passenger>
<name>Arjen Poutsma</name>
...
One way to solve this problem is to use references to objects that were already marshalled, like so
<flight number="KL1117">
<passengers>
<passenger>
<name>Arjen Poutsma</name>
<flight href="KL1117" />
</passenger>
...
</passengers>
</flight>
This solves the recursiveness problem, but introduces new ones. For one, you cannot use an XML
validator to validate this structure. Another issue is that the standard way to use these references in
SOAP (RPC/encoded) has been deprecated in favor of document/literal (see WS-I Basic Profile [http://www.ws-i.org/Profiles/BasicProfile-1.1.html#SOAP_encodingStyle_Attribute]).
Contract-first versus Contract-last
Besides the Object/XML Mapping issues mentioned in the previous section, there are other reasons
for preferring a contract-first development style.
Fragility:
As mentioned earlier, the contract-last development style results in your web service contract (WSDL and your XSD) being generated from your Java contract (usually an interface). If you are using this approach, you will have no guarantee that the contract stays constant over time. Each time you change your Java contract and redeploy it, there might be subsequent changes to the web service contract. Aditionally, not all SOAP stacks generate the same web service contract from a Java contract. This means changing your current SOAP stack for a different one (for whatever reason), might also change your web service contract.
When a web service contract changes, users of the contract will have to be instructed to obtain the new contract and potentially change their code to accommodate for any changes in the contract.
Performance
When Java is automatically transformed into XML, there is no way to be sure as to what is sent across the wire. An object might reference another object, which refers to another, etc. In the end, half of the objects on the heap in your virtual machine might be converted into XML, which will result in slow response times.
Reusability
Defining your schema in a separate file allows you to reuse that file in different scenarios. If you define an AirportCode in a file called airline.xsd, like so:
<simpleType name="AirportCode">
<restriction base="string">
<pattern value="[A-Z][A-Z][A-Z]"/>
</restriction>
</simpleType>
You can reuse this definition in other schemas, or even WSDL files, using an import statement.
No comments:
Post a Comment