SOA / Web Services / Java

A Technology Blog

Posts Tagged ‘web service’

Adapter and Façade – The Design Patterns of SOA

Posted by Vivek on August 6, 2011


This design pattern helps to take advantage of the existing technology or aplications. One of the principles of SOA is reuse. Adapter fosters reusability by integrating legacy or packaged applications with your ecosystem. Application built using mainframe technologies like CICS, COBOL etc still have a place in today’s IT infrastructure. Capabilities and usage of packaged applications like Siebel CRM, Peoplesoft HRM, Portal billing, SAP CRM etc are not limited because of technical implementations. One of the well known adapters is JCA (Java Connector Architecture) adapter.


A right level of granularity is essential when designing services. Services, in context of SOA, can be considered as a unit of logic. SOA recommeds use of coarse granular services. Reason is simple – It avoids making multiple calls to service and hence increases network throughput. But sometimes it is difficult to avoid designing and developing low-level services (mostly utility services). Façade helps in providing coarse granurality by encapsulating low level services. Façade pattern also abstracts client from the implementation details of a service. Most of the times, changes in a service does not impact client because of usage of Façade pattern.



Posted in SOA, Web Services | Tagged: , , | 1 Comment »

SOA Testing – Tools in the market

Posted by Vivek on May 9, 2010

Here is a list of the leading testing tools available in the market to test the SOA components. I believe that no tool can completely fulfill the testing requirements of an SOA but you can accomplish a lot. The tools should be intelligent enough to carry out:

i. Schema/ WSDL/ SOAP validation
ii. Simulation of webservice, both client and server  i.e., mock services
iii. Testing of web services standards such as web services addressing, security, reliable messaging etc.
iv. WS-I conformance testing
v. Testing of intermediaries
vi. Governance testing. Validation of design and run time policies and Service versioning.
vii. Asynchronous and notification framework testing
viii. Orchestration and Choreography testing
ix. Performance testing

Below is a list of tools that cover some or most of the above points:

1. Green Hat GH Tester : This tools provides comprehensive testing of SOA. Helpful in providing performance and security related testing and validation of SOA and BPM components. You can monitor SOA performance and track service invocation and response.

2. Mindreef SOAPScope Server : Acquired by progress software. Allows creation of mock services, validation and compliance checking.

3. Parasoft SOATest : Helps in performance or load and security testing. Provides governance testing by performing policy enforcement checks. Allows creation of mock services and performing regression testing.

4. Crosscheck Networks SOAPSonar : Performs functional, performance, compliance, and security testing across SOAP, XML, and REST based services.

5. iTKO Lisa : Performs UDDI test/ validation, performance , validation and compliance and mock service testing.

6. Matador Tech Tester : suitable for validation and regression testing.

7. SOAP UI: Performs functional, load/ performance and mock service testing. Also helpful in validation and compliance testing.


Posted in SOA Testing | Tagged: , , , , , , | 7 Comments »

Is your web-service conforming to WSI-Basic Profile?

Posted by Vivek on January 23, 2010

Though there are various ways to design a service and since webservices are XML based and XML is tagged as platform independent, different programming languages and different application server have their own set of rules while defining a web service. WSI-Basic Profile helps address some interoperability issues that might arise because of the proprietary nature of majority of tools and languages. Listed out below are some of the guidelines that can be useful while defining a service:

XML version is 1.0

Encoding must be UTF-8 or UTF-16

Namespace for WSDL is defined as

Namespace for SOAP binding is defined as

Namespace for SOAP encoding is defined as

Namespace should not be as

Custom Data types used in WSDL should conform to XML Schema version 1.0

Data Type that causes interoperability issues should not be used. For ex. wsdl:arrayType, arrayOfStrings etc. should not be used.

All the xsd:import elements should be used within the xsd:schema element of the types section

The attribute wsdl:required=”true” should not be used by any element.

wsdl:import URIs should be absolute and not relative.

wsdl:import should precede all other wsdl types , except wsdl:documentation. Similarly, wsdl:types should precede all other elements, except wsdl:documentation and wsdl:import

targetNamespace value of WSDL that is being imported should have the same value as wsdl:import.

All the imported schemas should have a root element defined with namespace

Part attribute, if any, in a document literal style of web service should be defined within binding or operation.

In Document Literal style, wsdl:part elements that are used in soapbind:body should have ‘element’ attribute defined.

In a wsdl:message/wsdl:part element, the ‘element’ attribute should refer to a global element declaration and not to any xsd types.

In an RPC Literal style, envelope should not have xsi:nil attribute value = “1” or “true”.

In an RPC Literal style, wsdl:part elements that are used in soapbind:body should have ‘type’ attribute defined.

In a wsdl:portType definition, Solicit-Response/Notification type operations should not be used.

A wsdl:message element should not have both type and element attributes defined.

The values for name attribute of wsdl:portType elements should be distinct.

In soap:binding element, the transport attribute should be defined and the value should be

In a soap:operation, the value of style attribute should be either “rpc” or “document”.

In a soap:operation, the soap:bodyelement should have use attribute set to “literal” ?

If soap:header/soap:headerfault/soap:fault elements are defined, the use attribute should be set to “literal”

The location attribute should have distinct value for different ports wsdl:port.

A soap:fault should be defined for each fault defined and it should contain name attribute. If use attribute is defined, it should contain a value ‘literal’

Similarly, a soap:headerfault should exist for each header fault defined.

If SOAP Action is defined within operation, it should be set in the HTTP header of the request otherwise, it should be set to empty quoted string.

SOAP envelope should contain namespace whereas SOAP encoding namespace should be SOAP message should also use UTF-8 or UTF-16 encoding.

Intermediaries, if present while transmitting SOAP message, should modify the header only if the must-understand attribute is set to true. Intermediaries should not modify the payload or elements with the SOAP Body.

A must understand faultcode must be generated in case receiver is unable to process the mandatory header of the SOAP message.

In case of a fault, soap:Fault must not have childrens other than faultcode, faultstring, faultactor and detail. In case of fault,  children of the soap:Fault element must be unqualified. There can be zero or more child elements of the detail element, which can be either qualified or unqualified.

Values of the faultcode element are defined by SOAP specification and preferably should not be modified.


Posted in Web Services | Tagged: , , , , | 8 Comments »