Parse WSDL effectively

As a WSDL’s constituents are well-defined already, it is feasible to use a parser that can get the elements of the WSDL using APIs that are already defined. This will minimize complexity in the code and will help in achieving better performance.

 

Oracle WSDL parser is one such option.

 

It is only needed to import the necessary classes as the APIs are already defined and packaged with wsdl.jar.

 

//importing the necessary classes from library

import oracle.wsdl.WSDLDocument;

import oracle.wsdl.internal.Binding;

import oracle.wsdl.internal.Definitions;

import oracle.wsdl.internal.Documentation;

import oracle.wsdl.internal.Import;

import oracle.wsdl.internal.Message;

import oracle.wsdl.internal.PortType;

…….

 

 

WSDLDocument wsdldoc = new WSDLDocument(wsdl_url);

//getting definition element

Definitions definition = wsdldoc.getDefinitions();

//getting service element

Map servicesMap = definition.getServices();

//getting binding element

Map bindingsMap = definition.getBindings();

//getting PortType element

Map ptypesMap = definition.getPortTypes();

//getting message element

Map messagesMap = definition.getMessages();

//getting import details

Map importsMap = definition.getImports();

//getting documentation details

Documentation docs = definition.getDocumentation();

 

 

As there can be multiple elements, an “iterator” can be used to parse an individual element.

For Example:

 

Iterator iterator = servicesMap.entrySet().iterator();

        while (iterator.hasNext()) {

            Map.Entry me = (Map.Entry) iterator.next();

            …….

        }

 

The above code fragments keep things fairly simple while processing a WSDL.

 

Apache Woden

 

Woden provides Java class library for reading, manipulating, creating and writing WSDL documents.

 

Woden’s DOM-based XML parsing depends on Apache Xerces 2.7.1. Its XML Schema support it depends on the schema parser and object model implemented by the Apache Web Services Commons (ws-commons) XmlSchema project.

 

//importing necessary classes from woden jars

import org.apache.woden.WSDLException;

import org.apache.woden.WSDLFactory;

import org.apache.woden.WSDLReader;

import org.apache.woden.wsdl20.Binding;

import org.apache.woden.wsdl20.Description;

import org.apache.woden.wsdl20.Interface;

import org.apache.woden.wsdl20.Service;

….

 

  

 

WSDLFactory factory = WSDLFactory.newInstance();

WSDLReader reader = factory.newWSDLReader();

reader.setFeature(WSDLReader.FEATURE_VALIDATION, true);

String wsdlurl = “C://axis2-1.4.1//newwsdl.wsdl”;

 

//reading the WSDL Document

DescriptionElement descElem = (DescriptionElement) reader.readWSDL(wsdlurl);

Description descComp = descElem.toComponent();

 

//getting Interface, Binding and Service elements

InterfaceElement[] interfaces = descElem.getInterfaceElements();

BindingElement[] bindings = descElem.getBindingElements();

ServiceElement[] services = descElem.getServiceElements();

  

 

Complete details about usage and extensibility of woden are available at:

 

http://ws.apache.org/woden/userguide.html

 

JWSDL:

 

 

JWSDL is another option that is intended for use by developers of Web services tools and others who need to utilize WSDL documents in Java.

JWSDL is designed to allow users to read, modify, write, create and re-organize WSDL documents in memory. JWSDL is not designed to validate WSDL documents beyond syntactic validity. One use of JWSDL is to develop a tool that validates WSDL semantically.

JWSDL is designed for use in WSDL editors and tools where a partial, incomplete or incorrect WSDL document may require representation.

 

Details of JWSDL can be obtained by accessing the following link:

 

http://wsdl4j.sourceforge.net/downloads/JSR110_proposed_final_draft.pdf

Preserve white spaces in a SOAP message

Sometimes, the business requirement mandates that a SOAP request/response should maintain leading or trailing spaces that are present in a variable. By default, this does not happen. For example, you may expect ” ABC” or “ABC “, but you get “ABC”. The spaces are removed. Also, you may encounter issues if you use a binding mechanism like JAXB to marshal/ unmarshal xml fragments.  This requires modifying the default marshalling or unmarshalling behavior. This is how you can still maintain any whitespaces:

Before marshalling call

marshaller.setPropertyMarshaller.JAXB_ENCODING, “UTF-8″)

 which informs MarshallerImpl#createWriter(…) to create a UTF8XmlOutput instead of SAXOutput. 

UTF8XmlOutput escapes line-break into “ ”, which will be preserved when unmarshalling is performed by any xml parser.

RPC-style vs Document-Style Web Service

There has been lot of confusion on which style of web service is used but It is always recommended to use a Document-style webservice to realize SOA.

RPC style web service:
These web services are easier to create and are usually synchronous in nature.
The responsibility of marshalling and de marshalling lays with SOAP engine, This leads to significant performance degradations when message passed to an operation is large or complex.
Since large sized messages lead to performance degradation in RPC style web service, they are not suitable for implementing coarse grained functionality requiring information messages having more number of fields.
However fine grained functionalities is better implemented by RPC style web services.
Document style web service:
Document style web services are more time consuming to create, as it is the onus of the service to create the required objects from XML document.
These web services can consume large sized documents without any significant drop in performance as there are no overheads of marshalling and de marshalling associated with SOAP engine.
Document style web services are ideal for representing coarse rained functionality as a single large sized  document can be used to transfer information required to implement a business functionality.
Document style web service are primarily used for implementing asynchronous service.

RPC encoded web services are easiest  create but offers least control in terms of usage of custom data types, validation and interoperability.
RPC encoded web service are slower in performance because of added overheads of marshalling and un marshalling.
Document literal web services are harder to create but scores higher in all the above metrics and this is one of the reasons WS –I basic profile encourages the usage of document literal web services.

Document style web services are better suited for defining custom data types as they are not constrained by the usage of a particular encoding style. Document –literal web services offers the best performance and RPC –encoded web services offers the least performance as in document-literal web service overheads of marshalling and un marshalling no longer lies with SOAP engine. In a document –literal web service alternative techniques such as  SAX based parsing or custom data binding tool like XML beans, castor can be used.In case SOAP engine does not maintain state a document –literal web service can be used to carry state related data in the document. While using RPC –encoded web service often platform specific data structures are exposed in WSDL, which might not be supported by other platforms.

SOA Governance

Any organization willing to implement SOA should already have a plan for its governance. Most people think that SOA Governance is optional and it’s not true. Without SOA Governance it is impossible to reap the true benefits of a full-fledged SOA. Some benefits that are directly related to success of any organization.

“With the widespread adoption of SOA, the challenges associated with SOA projects are emerging. SOA governance isn’t optional— it’s imperative. Without it, return on investment will be low and every SOA project out of pilot phase will be at risk.”

                                                        —Paolo Malinverno

                                                           Gartner, Inc.1

Failure to provide effective SOA governance exposes your organization to serious risks:

• Insufficient knowledge of available services
• General failure to reuse services
• Unnecessary, uncontrolled service duplication
• Resources wasted on services that can’t be reused
• Service sprawl across siloed SOAs
• Ineffective communication of best practices.

   

A good blog on SOA Governance: http://blogs.oracle.com/governance/

Defining SOA

If you ask 5 different people definition of the buzzword “SOA”, they all will come with a different answers. SOA is not something that can be defined in two or three lines. 

“SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions.”

To be more precise, any SOA must exhibit the following features:

Loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other.

Service contract – Services adhere to a communications agreement, as defined collectively by one or more service descriptions and related documents.

Autonomy – Services have control over the logic they encapsulate.

Abstraction – Beyond what is described in the service contract, services hide logic from the outside world.

Reusability – Logic is divided into services with the intention of promoting reuse.

Composability – Collections of services can be coordinated and assembled to form composite services.

Statelessness – Services minimize retaining information specific to an activity.

Discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.

This is important when the following objectives are to be achieved:

• Reducing overall total cost of ownership (TCO)

• Improving time to market

• Achieving business agility

• Fostering innovation

• Enabling compliance

• Improving the top and / or bottom line

• Increasing customer satisfaction and retention

• Global expansion

SOA Best Practices

Hundreds of Organizations are trying to demystify SOA and each wants to win the race by providing the best possible solution even if the infrastructure becomes heavy in the process.

Here is a good link which clears the air to a large extent:

http://it.toolbox.com/blogs/the-soa-blog/soa-best-practices-17730

Oracle’s breed of products in making SOA a reality are unmatchable: 

http://download.oracle.com/technology/tech/soa/soa_best_practices_1013x_drop3.pdf