PracticalQA: November 2012

SOATest

SOA

Service-oriented architecture (SOA) is:

1. An evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications.

2. An application's business logic or individual functions are modularized and presented as services for consumer/client applications.

3. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.

Service-oriented architectures have the following key characteristics:

SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.
SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.
SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) are the standard used for service registry.
Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.

SOA infrastructure

To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. A typical SOA infrastructure looks like Figure 3. The following sections discuss the infrastructure's individual pieces.

Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.

SOAP, WSDL, UDDI

WSDL, UDDI, and SOAP are the fundamental pieces of the SOA infrastructure. WSDL is used to describe the service; UDDI, to register and look up the services; and SOAP, as a transport layer to send messages between service consumer and service provider. While SOAP is the default mechanism for Web services, alternative technologies accomplish other types of bindings for a service. A consumer can search for a service in the UDDI registry, get the WSDL for the service that has the description, and invoke the service using SOAP.

WS-I Basic Profile

WS-I Basic Profile, provided by the Web services Interoperability Organization, is turning into another core piece required for service testing and interoperability. Service providers can use the Basic Profile test suites to test a service's interoperability across different platforms and technologies.

J2EE and .Net

Though the J2EE and .Net platforms are the dominant development platforms for SOA applications, SOA is not by any means limited to these platforms. Platforms such as J2EE not only provide the framework for developers to naturally participate in the SOA, but also, by their inherent nature, bring a mature and proven infrastructure for scalability, reliability, availability, and performance to the SOA world. Newer specifications such as Java API for XML Binding (JAXB), used for mapping XML documents to Java classes, Java API for XML Registry (JAXR), used for interacting with the UDDI registries in a standard manner, and Java API for XML-based Remote Procedure Call (XML-RPC), used for invoking remote services in J2EE 1.4 facilitate the development and deployment of Web services that are portable across standard J2EE containers, while simultaneously interoperating with services across other platforms such as .Net.

SOA is not Web services

In an April 2003 Gartner report, Yefim V. Natis makes the distinction as follows: "Web services are about technology specifications, whereas SOA is a software design principle. Notably, Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect." Fundamentally, SOA is an architectural pattern, while Web services are services implemented using a set of standards; Web services is one of the ways you can implement SOA. The benefit of implementing SOA with Web services is that you achieve a platform-neutral approach to accessing services and better interoperability as more and more vendors support more and more Web services specifications.

What's the best fit for SOA?

You might be wondering in which business functions and situations SOA fits best and which best shows its potential? There are some situations and business functions that should conjure SOA immediately, because SOA can boost competitiveness and productivity, and clearly display its benefits. Such situations mainly include:

Centralized business functions used by multiple entities: SOA helps to identify such functions and package them into reusable, self-contained services that aren't affected by process changes around them.
Integration with partners: SOA promotes using standards, which is critical in any integration because standards create a common baseline for all parties to work on. Also, the agility provided by SOA enhances the integration experience with the flexibility to plug in, change, or update services almost seamlessly to your clients with SOA's decoupling capabilities.
The existence of old technologies that are still working: Some organizations aren't willing to give up their tried-and-true technologies. Security concerns make some customers, especially in sensitive industries such as banking, suspicious of new software systems and their unknown vulnerabilities. In these cases, SOA can help by wrapping legacy technologies in standardized ways, enabling their exposure in a standards-based environment suited for integration and reuse.

What factors contribute to SOA's most popular capability: business agility enablement?

Because change is inevitable, the only guarantee of the continuity of a business is its ability to anticipate and adapt to changes, also known as business agility. Crucial to the future of any business, SOA makes business agility possible with the following factors.

Loose coupling

Enables real-time business capabilities because it removes the hard connections that impede the ability to change
Changes the way IT costs are distributed, with less expenses in implementation and more investments in reuse
Increases the feasibility of real-time remote access to original sources of information, thus reducing the delay and dependencies
Integration projects are driven by business needs, with the visibility of capabilities provided (that is, business is the main driver)
Lets companies extract more data measuring business performance in real time by exposing and sharing information
Decreases time to market because connections to customers and partners can be made faster
Makes it easier for partners to do business with your company
Promotes and publicizes your services, making it easier for customers to find you and your services
Makes it easier to find new partners and services by helping you search for the most suitable service for your need

Reuse

Makes processes more consistent because they depend on the same reused components
Promotes increased quality through competition between the services providers
Gives consumers a wide choice of suppliers
Covers essentially all classes of IT assets: hardware, software, data, and process assets
Decreases the impact of change because it's done in a central location and reflects on all concerned parties
Let’s you focus on business processes rather than technical implementation
Helps decrease the cost of integration because the component has already been integrated
Let’s you make system changes without constraining business change
Promotes flexibility, which gives you more space to innovate
Let’s you publish once but consume many times

Extensibility

Makes SOA solutions available to all sizes of organizations
Changes software-deployment activities from a big-bang model into a more dynamic, less-time-consuming model, which is more appropriate to the business
Makes it easier to add or change partners
Accelerates mergers and acquisitions
Facilitates exposed services, which represent potential new revenue sources

So what will a company lose if it doesn't adopt SOA?

Given that SOA is a plausible solution for a company, the cost of not implementing it can result in three major setbacks:

Inability to move to higher-value markets that provide more business growth and exposure. Because a company is bound to its existing tailored systems, it becomes stuck in its original place in the market and struggles to address the higher-value markets. However, with SOA, an organization can change business tactics and enable new ones, giving it an edge.
Inability to address more technologically advanced competition.
Competition from lower-cost sources.

Is SOA always a better solution?

SOA provides benefits in almost all cases of business organizations. However, in very special cases, it might prove to be a liability more than a drive towards better business. These cases include:

A homogeneous IT environment: If an organization depends on a set of coherent products—belonging to a same vendor, for example—, has a limited scope of work, and has no need to add or change any of these products, an SOA might be a liability more than a useful strategy.
When true real-time performance is critical: To provide loose coupling between different consumers and producers, an SOA depends on interoperable protocols, which are slow by nature. It can also induce mediation logic and asynchronous protocols, which aren't suitable for real-time performance.
When things don't change: If the customer sees no change happening to the business logic, presentation, data flow, process, or any other aspect of the application, converting old systems to SOA might not return sufficient value to make the effort worthwhile.
When tight coupling is not an inconvenience: Loose coupling is of best use when it's used with a component that's not under your control and, this, you can't control its change. On the other hand, when the component is yours and under your control, loose coupling can be a burden, especially if the component isn't really reusable.

What is Service-Oriented Architecture?

Service Oriented Architecture or SOA for short is a new architecture for the development of loosely coupled distributed applications. In fact service-oriented architecture is collection of many services in the network. These services communicate with each other and the communications involves data exchange & even service coordination. Earlier SOA was based on the DCOM or Object Request Brokers (ORBs). Nowadays SOA is based on the Web Services.
Broadly SOA can be classified into two terms: Services and Connections.

Services:

A service is a function or some processing logic or business processing that is well-defined, self-contained, and does not depend on the context or state of other services. Example of Services are Loan Processing Services, which can be self-contained unit for process the Loan Applications. Other example may be Weather Services, which can be used to get the weather information. Any application on the network can use the service of the Weather Service to get the weather information.

Connections:

Connections means the link connecting these self-contained distributed services with each other, it enable client to Services communications. In case of Web services SOAP over HTTP is used to communicate the between services.
The following figure is a typical example of the service-oriented architecture. It shows how a service consumer sends a service request to a service provider. After accepting the request, service provider sends a message to the service consumer. In this case a service provider can also be a service consumer.

Different Technologies Used:

SOA is much different from point-to-point architectures. SOA comprise loosely coupled, highly interoperable application services. These services can be developed in different development technologies (such as Java, .NET, C++, PERL, PHP), the software components become very reusable i.e. the same C# (C Sharp) service may be used by a Java application and / or any other programming language. WSDL defines a standard, which encapsulates / hides the vendor / language specific implementation from the calling client / service.

SOA definitions

(From http://en.wikipedia.org/wiki/Service-oriented_architecture )

Term	Definition / Comment
service	(Ideally) a self-contained, stateless business function which accepts one or more requests and returns one or more responses through a well-defined, standard interface. Services can also perform discrete units of work such as editing and processing a transaction. Services should not depend on the state of other functions or processes. The technology used to provide the service, such as a programming language, does not form part of this definition.
orchestration	Sequencing services and providing additional logic to process data. Does not include data presentation.
stateless	Not depending on any pre-existing condition. In a SOA, services should not depend on the condition of any other service. They receive all information needed to provide a response from the request. Given the statelessness of services, service consumers can sequence (orchestrate) them into numerous flows (sometimes referred to as pipelines) to perform application logic.
provider	The function which performs a service in response to a request from a consumer.
consumer	The function which consumes the result of a service supplied by a provider.
discovery	Service oriented architecture relies on the ability to identify services and their capabilities. Therefore, a SOA depends on a directory which describes the services available in its domain.
binding	The relationship between a service provider and consumer is dynamic; it is established at runtime by a binding mechanism.

Why SOA?

SOA architecture enables seamless Enterprise Information Integration. Here are some of the Benefits of the Service Oriented Architecture:

· Due to its platform independence, it allows companies to use the software and hardware of their choice.

· There is no threat of vendor lock-in

· SOA enables incremental development, deployment, and maintenance.

· Companies can use the existing software (investments) and use SOA to build applications without replacing existing applications

· The training costs are low, so the available labor pool can be used for running the applications.

Parasoft SOATEST

Parasoft SOAtest is "a comprehensive testing and analysis tool suite for tailored to the unique testing and validation needs of Service Oriented Architectures."

SOAtest s primary function is to test Web services in a variety of ways:

1. It can emulate the client or the server (by stubbing out services)

2. Validate WSDL documents; act as a unit, functional, or load test agent

3. More all in an easy to understand user interface.

4. Additionally, SOAtest has rich test-case management capabilities

Individual tests can be grouped into test suites that can be executed in sequence, allowing for various scenarios to be validated. Each test can have separate methods for determining input parameters and validating responses. When a test is executed, either by itself or as part of a test suite, any failures are clearly identified in the lower pane for analysis and remediation.

Creating Test Cases
Tests can either be created individually or as a part of a larger test suite. The tool seems to drive you toward creating test suites rather than individual tests, which is nice for reuse, organization, and best of all - regression testing a collection of tests. SOAtest supports the creation of test suites from a wide range of sources including:

Web Services Description Language (WSDL) files
Business Process Execution Language (BPEL) files
Universal Description, Discovery & Integration (UDDI) registry end-points
Web Services Inspection Language (WSIL) files
BEA Aqualogic Enterprise Repository end-points

The test suite creation wizard will ask you to designate a file, URL, or end-point to query and also ask you to designate what tests you want to create. Upon completing the wizard, you'll have a whole set of tests automatically generated and ready-to-run as is or customized prior to execution.

Functional Testing
I was very impressed with the functional verification testing capabilities. SOAtest supports the following functional verification features:

Check schema validity against a WSDL
XML-aware diff engine that flags only true XML structure changes
Surgical inclusion/exclusion of XML message elements in the verification process via XPATH
A graphical rules engine for managing assertions

Every one of these features is enabled through simple intuitive menu options, dropdown lists, check boxes, and XML tree structures. The interface is simple to navigate and although there's a wealth of options, they're organized to avoid the feeling of being overwhelmed.

Executing one or more functional tests multiple times based on an external data set (database or spreadsheet) was another feature that I sought out. SOAtest came through in this area as well supporting the ability to point at a data source (CSV, Excel, relational databases, etc.) and run through a battery of tests that pull values out of the data source and send service requests containing the extracted data values. This lets you define a single test case or suite of tests and then automatically test the full range of data values that the test case needs to support without creating additional tests for each value.

Testing with Mock Services
In a truly test-driven environment, I'd create service interfaces and corresponding suites of test cases before any implementation code is developed. Although this is good in theory, without a supporting toolset, it's not very realistic. SOAtest provides all the capabilities needed to support this kind of development model. When creating a new project/test suite, simply point the tool at a WSDL file and check the "Generate Server Stubs" radio button. The servers stubs will run on SOAtest's embedded Tomcat server and let you create and run testing scenarios before you've written a single line of implementation code. This way, when you're ready to implement the service interfaces, you have a defined a suite of tests for verification. This helps to control the scope (when you meet all the tests, stop working) and provides one or more test suites that can be incorporated into automatic regression testing (see below) to ensure that functionality isn't compromised as the project progresses.

Of all the features that I've worked with, I found the service mock-up process the most cumbersome. The other aspects of SOAtest were intuitive and easy-to-work with, whereas I had to wrestle a while to get the mock service capability working on anything other than the tutorial walk-through. In the end, the functionality of this capability was excellent, albeit a bit difficult to initially configure.

Regression Testing
Running your tests once is nice. Running your tests regressively is better. Running your tests regressively and automatically at night is divine. SOAtest supports all three scenarios. Any of the test suites that you define in a SOAtest project can be converted to regression test suites. Furthermore, using XPATH you can selectively indicate which portions of the test cases may change from test to test and which values should never change. Once you have a set of regression tests that you're happy with, SOAtest provides a command-line mechanism to kick off your test suites automatically. Thus in an agile, continuous integration environment you can run regression testing at night, at lunch, or every hour on the hour to ensure that you find bugs early and often.

Reporting
SOAtest provides several reporting features (auto-generated reports for nightly regression tests, on-demand, detailed summary reports for test suites, and WS-I interoperability reports). I found the quality and readability of the reports developed by SOAtest to be quite good. Figure 2 provides a snapshot of part of the SOAtest detailed report. The WS-I interoperability reports were pretty low quality, difficult to navigate, and provided information overload. In fairness to SOAtest, those reports are copyrighted by WS-I and seem to be auto-generated by one or more WS-I tools. Consequently, I'm not sure that Parasoft has any control over the quality of these reports. Nonetheless, I would have liked a WS-I conformance report of the same quality and user-friendliness as the native SOAtest reports.

Advanced Testing Features
the palette of testing and analysis features in SOAtest is extensive. In the interest of not filling up this entire magazine with feature descriptions, I'll list several of the compelling features that I've not covered already:
- Scenario-based testing where subsequent test cases depend on data returned from previous test cases
- Stress/load testing your SOA and specifying Quality of Service parameters
- Testing non-XML services (JMS, MQ, TIBCO, EJB, REST, Binary, Text, etc.)
- Validate SOAP security using WS-Security (encryption, digital signatures, and authentication)
- Asynchronous service testing
- Custom scripting with Python, JavaScript, or Java

Drawbacks
As I mentioned earlier, the mock service feature is a bit awkward to work with initially. Also, the WS-I conformance report was not up to the same quality standards as the native SOAtest reports. With SOA's strong integration and interoperability play, there are a lot of enterprises that have Java and other services that all need to be involved in the same business process and testing scenario.

WSDL

Abstract

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

1. Introduction

As communications protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way. WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitute a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:

Types– a container for data type definitions using some type system (such as XSD).
Message– an abstract, typed definition of the data being communicated.
Operation– an abstract description of an action supported by the service.
Port Type–an abstract set of operations supported by one or more endpoints.
Binding– a concrete protocol and data format specification for a particular port type.
Port– a single endpoint defined as a combination of a binding and a network address.
Service– a collection of related endpoints.

Following is the WSDL file that is provided to demonstrate a simple WSDL program. Assuming the service provides a single publicly available function, called say Hello. This function expects a single string parameter and returns a single string greeting. For example if you pass the parameter world then service function say Hello returns the greeting, "Hello, world!”

Content of HelloService.wsdl file

<definitions name="HelloService"

targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"

xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

</message>

</message>

</operation>

</portType>

<soap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/>

<soap:operation soapAction="sayHello"/>

<input>

<soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:examples:helloservice"

use="encoded"/>

</input>

<soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:examples:helloservice"

use="encoded"/>

</output>

</operation>

</binding>

<documentation>WSDL File for HelloService</documentation>

<soap:address

location="http://www.examples.com/SayHello/">

</port>

</service>

</definitions>

Analysis of the Example

Definition : HelloService
Type: Using built-in data types and they are defined in XMLSchema.
Message :

sayHelloRequest : firstName parameter
sayHelloresponse: greeting return value

Port Type: sayHello operation that consists of a request and response service.
Binding: Direction to use the SOAP HTTP transport protocol.
Service: Service available at http://www.examples.com/SayHello/.
Port: Associates the binding with the URI http://www.examples.com/SayHello/ where the running service can be accessed.

WSDL verification

WSDL verification can be considered the first step in testing Web Services. Although WSDLs are generally created automatically by various tools, it doesn’t necessarily mean that the WSDLs are correct. When WSDLs are manually altered, WSDL verification becomes even more important. Ensuring correct and compliant WSDLs enables your service consumers to function correctly, and avoids vendor lock-in, thus achieving interoperability and realizing SOA goals of service reuse. SOAtest can automatically generate a test suite of comprehensive WSDL tests to ensure that your WSDL conforms to the schema and passes XML validation tests. Additionally, it performs an interoperability check to verify that your web service will be interoperable with other WS-I compliant services.

Few Terminologies used in SOA:

ESB

An enterprise service bus (ESB) is a software architecture model used for designing and implementing the interaction and communication between mutually interacting software applications in Service Oriented Architecture (SOA). As software architecture model for distributed computing it is a specialty variant of the more general client server software architecture model and promotes agility and flexibility with regards to communication and interaction between applications. Its primary use is in Enterprise Application Integration of heterogeneous and complex landscapes.

All customer services communicate in the same way with the ESB: the ESB translates a message to the correct message type and sends the message to the correct producer service.

Penetration test