Perhaps it’s just our preoccupation with new development, but it never ceases to amaze me how little attention is paid to the entire application lifecycle. This seems especially true whenever a new technology is introduced and assimilated. Consider Web services, for example.

There are countless books and seminars, primarily targeted to the developer, focused on the design and coding of Web services and service oriented architectures (SOA). Yet, precious little information is given to the latter phases of the application lifecycle, such as the testing, deployment and management of Web services-based architectures. In this column, we will tackle the unique challenges surrounding just one of these phases - the testing of Web services, particularly as it is applied in an inter-enterprise SOA model.

Is Web Services Testing Different?

Before delving into Web services testing concepts, let’s explore the unique aspects of Web services that present a challenge to traditional testing models.

There are three key aspects to Web services used in SOAs that are worthy of mention.

First, a Web services-based architecture results in a distributed, loosely coupled system with dependent stakeholders.

While this architecture holds great benefit in terms of scalability and extensibility of the system, it poses a great challenge for the tester. No longer is each component of the system necessarily constructed and deployed by a single corporate entity. Potentially, the overall system may actually be derived from components that are constructed, tested and hosted by multiple stakeholders. As such, it is difficult to establish consistent code quality, availability and quality of service (QoS) across these entities.

The second difference in the Web services solution is that it provides a standards-based, service-driven model to integration. While prior object technologies such as CORBA provided facilities for building distributed architectures, they did so via complex programmatic interfaces. With Web services, standards for data format (XML), communication (SOAP) and programmatic interface (WSDL) are data-driven, simple and share a common XML-based foundation. Traditional testing tools must evolve to fully support these standards for effective testing to occur, but that hasn’t really happened yet.

The use of Web services standards also offers other implications to current testing tools. Web services-based integration highlights the importance of validating interface points and message formats rather than simply testing at the graphical user interface level. Using testing tools that utilize GUI-driven automation is simply inadequate for a Web services project.

-1-

Explore Our Topics

• BPM & Enterprise Architecture
• BPM Standards
• BPM Implementation
• BPM Best Practices
• Cloud BPM
• Continuous Process Improvement
• BPM Governance
• Service Governance

• Business to Business (B2B)
• BPM for Customer Management
• BPM for Financial Services
• BPM for Government
• BPM for Healthcare & Insurance
• BPM for Supply Chain

• Business Activity Monitoring
• Event Processing
• Process Intelligence
• Business Rules Management
• Decision Management
• Operational Intelligence

• Workflow Automation
• BPM & Enterprise 2.0
• BPM & Web 2.0
• BPM & ECM
• Case Management
• Collaboration
• Enterprise Portals
• Social BPM

• BPM & Cloud Integration
• BPM Analysis & Optimization
• Business Process Simulation
• Process Visibility & Monitoring
• Process Orchestration
• Process Discovery
• Process Modeling

Home
Webinars
Blogs
ebizQ Forum
All Topics
Subscriptions
White Papers
Analyst Corner
Follow us on Twitter
Fan us on Facebook

Explore Our Topics

BPM Strategy
BPM Solutions
Event Processing Strategy
Content-Centric & Collaborative BPM
Process-Centric BPM

About Us
Editorial Submissions
Feedback
FAQ
Advertise With Us
Site Map
Privacy Policy
Unsubscribe