Web Services Process Flow

A service provider describes its service using WSDL. This definition is published to a directory of services. The directory could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories can also be used. Service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service. Part of the WSDL provided by the service provider is passed to the service consumer and this tells the service consumer what the requests and responses are for the service provider.

Web Services

A Web service is a method of communication between two electronic devices over a network.
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-process able format (specifically Web Services Description Language WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

The W3C also states, "We can identify two major classes of Web services, REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations.

Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services.

The full-function web services platform can be thought of as XML, HTTP, SOAP, WSDL and UDDI. At higher levels, one might also add technologies such as XAML, XLANG, XKMS, and XFS -- services that are not universally accepted as mandatory.

SOAP (Simple Object Access Protocol) is a protocol specification that defines a uniform way of passing XML-encoded data. It also defines a way to perform remote procedure calls (RPCs) using HTTP as the underlying communication protocol.

UDDI (Universal Description, Discovery and Integration Service) provides a mechanism for clients to dynamically find other web services. Using a UDDI interface, businesses can dynamically connect to services provided by external business partners. A UDDI registry is similar to a CORBA trader, or it can be thought of as a DNS service for business applications.

Web Services Description Language (WSDL) is a new specification to describe networked XML-based services. It provides a simple way for service providers to describe the basic format of requests to their systems regardless of the underlying protocol (such as Simple Object Access Protocol or XML) or encoding (such as Multipurpose Internet Messaging Extensions). WSDL is a key part of the effort of the Universal Description, Discovery and Integration (UDDI) initiative to provide directories and descriptions of such on-line services for electronic business.

SOA Testing Challanges

When it comes to testing SOA applications, one has to look beyond functionality and performance (load) testing. SOA testing requires testing of interfaces and services that might bring together diverse systems and platforms, along with other performance (latency) and security related aspects.
One of the other challenges to be tackled in SOA Testing is the availability of the environment with the dependent underlying services and/or applications. For instance, an SOA Implementation might bring together two or more autonomous internal applications/services when composing a business process.
The availability of these internal applications/services becomes highly important during integration testing in parts as well as during end-to-end testing of the business process.
Some of the SOA Testing challenges are:
• Services that do not have a user interface
• Data driven business logic within services
• External services to the organization
• The quality of 'service' software will be vital to promote reuse and facilitate business agility. Services that have known bugs and quality issues will not be reused by the development teams. A significant increase in testing activities and test assets (functional, performance and security regression suites that include sophisticated harnesses and stubs) will be required at a service (program) level
• Predicting the future usage of services to assist with performance, load, stress, scalability
• As your SOA evolves, security testing will have a higher priority and profile within your organizations test strategy
Additional considerations:
• In SOA, Services are based on heterogeneous technologies. The ability to string together multiple types of components to form a business process requires unconstrained thinking from an architect's perspective, and test planning and scheduling complexities from a tester's perspective.
• In SOA, application logic is in the middle-tier, operating within numerous technologies, residing outside the department, or even outside the company.
• To test SOA, you need to go far beyond merely testing a user interface or browser screen. Web Services (WSDL/SOAP) will be an important component for many SOAs, but if you're only testing Web Services, you are not likely to test the entire technology stack that makes up the application. What are the transactions happening at the messaging layer? Is the right entry being reflected in the database?