My Code Snapshots

Web Services Concepts

WSDL Ports

nThe <portType> element is the most important WSDL element.

nIt describes a web service, the operations that can be performed, and the messages that are involved.

nThe <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language

One-way operation type

• The SOAP WS supports both remote procedure call (i.e. RPC) and message oriented middle-ware (MOM) integration styles. The Restful Web Service supports only RPC integration style.

• The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S),  Messaging, TCP, UDP SMTP, etc. The REST is transport protocol specific. Supports only HTTP or HTTPS protocols.

• The SOAP WS permits only XML data format.You define operations, which tunnels through the POST. The focus is on accessing the named operations and exposing the application logic as a service. The REST permits multiple data formats like XML, JSON data, text, HTML, etc. Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE Web operations. The focus is on accessing the named resources and exposing the data as a service. REST has AJAX support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations.
  
           GET - read()
           POST - create()
           PUT - update()
           DELETE - delete() 

• SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales better.

• SOAP WS supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc. The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.

• The SOAP has comprehensive support for both ACID based  transaction management  for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources. The REST supports transactions, but it  is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.

• The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries. REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.

• Does the service expose data or business logic? (REST is a better choice for exposing data, SOAP WS might be a better choice for logic).Do the consumers and the service providers require a formal contract? (SOAP has a formal contract via WSDL)
• Do we need to support multiple data formats?
• Do we need to make AJAX calls? (REST can use the XMLHttpRequest)
• Is the call synchronous or  asynchronous?
• Is the call stateful or stateless? (REST is suited for statless CRUD operations)
• What level of security is required? (SOAP WS has better support for security)
• What level of transaction support is required? (SOAP WS has better support for transaction management)
• Do we have limited band width? (SOAP is more verbose)
• What’s best for the developers who will build clients for the service? (REST is easier to implement, test, and maintain)

• The contract-first approach, where you define the contract first with XSD and WSDL and the generate the Java classes from the contract.
• The contract-last approach where you  define the Java classes first and then generate the contract, which is the  WSDL file from the Java classes.

• Clients are decoupled from the server, hence the implementation logic can be revised on the server without affecting the clients.
• Developers can work simultaneously on client and server side based on the contract both agreed on.
• You have full control over how the request and response messages are constructed -- for example, should "status" go as an element or as an attribute? The contract clearly defines it. You can change OXM (i.e. Object to XML Mapping) libraries without having to worry if the "status" would be generated as "attribute" instead of an element. Potentially, even Web service frameworks and tool kits can be changed as well from say Apache Axis to Apache CXF, etc

• More upfront work is involved in setting up the XSDs and WSDLs. There are tools like XML Spy, Oxygen XML, etc to make things easier. The object models need to be written as well.
   
• Developers need to learn XSDs and WSDLs in addition to just knowing Java.

• Developers don't have to learn anything related to XSDs, WSDLs, and SOAP. The services are created quickly by exposing the existing service logic with frameworks/tool sets. For example, via IDE based wizards, etc.
    
• The learning curve and development time can be smaller compared to the Contract-first Web service.

•  The development time can be shorter to initially develop it, but what about the on going maintenance and extension time if the contract changes or new elements need to be added? In this approach, since the clients and servers are more tightly coupled, the future changes may break the client contract and affect all clients or require the services to be properly versioned and managed.
•  In this approach, The XML payloads cannot be controlled. This means changing your OXM libraries could cause something that used to be an element to become an attribute with the change of the OXM.