For more info on a specific newsletter, click the title. Details will be displayed in a new window.
Subscribe to
Computerworld 40 years of the most authoritative source of news and information for IT leaders.
|
|
|
|
August 15, 2005 (Computerworld) -- The good news about service-oriented architectures (SOA) is the flexibility they provide for ad hoc integration within and across enterprises. It's also the bad news when it comes to testing, which relies on predictability and repeatability.
The key is to first isolate the architectural layers so that functionality can be tested -- and issues exposed -- at their source as early as possible, then to gradually integrate the components until end-to-end business processes can be verified.
Equally important is to engage subject matter experts throughout the development life cycle to ensure compliance not only with technical specifications but also with business requirements. Waiting for business process acceptance testing to be performed when all the layers are complete is to invite disaster and delay: a service that returns the wrong result in the right way is perhaps even more dangerous than one which fails to execute altogether because it has a higher risk of being undetected, and uncovering the root source of a problem takes longer the more layers are involved.
The challenge for testing an SOA is that the test design should be approached from the top down, and test execution from the bottom up. This paradoxical approach assures that as each layer is implemented the overall enterprise objective -- supporting critical business processes -- is maintained.
It's All About the Data
As exciting as SOA is, never forget that it's just another way to move data from one place to another, and if the data is wrong, then nothing else matters.
This is why subject matter experts are crucial to the test process for SOA. Their role is to define the data contents of the transactions that support the business processes. For each business process, they must identify the supporting data that is required, and for each service request and reply, they must provide the expected values. This can be done in a simple spreadsheet format or in a test repository database long before the service architecture is actually implemented, and can be incrementally expanded as the services take shape.
For example, if an insurance company receives an electronic claim whose adjudication, payment calculation and remittance is handled through services behind the scenes, then it's essential that the final outcome be correct: the claim is approved or refused appropriately and the amount paid, if any, is accurate. Only an insurance claims specialist can or should define the test cases that will verify the functionality of each application's role in the overall process.
The importance of starting with data analysis is that it maintains focus on what business functions must be exposed as services in order to meet high-level business process requirements. Further, it provides the data contents for the messages that will be used to exercise the infrastructure as it's implemented. Without this data focus, the implementation of an SOA runs the risk of delivering a technically acceptable solution that fails to deliver business value.
The Medium is the Message
Once the business experts have identified the data values, these must be formatted into messages that express service requests and replies. For testing, messages must be created for each request and reply between each provider and consumer application that can be used to test each layer of the architecture.
Message templates can be defined by industry standards or internal specifications. Some industries have already promulgated voluntary standards such as Association for Cooperative Operations Research and Development (ACORD) for example, or regulatory standards such as Health Insurance Portability and Accountability Act (HIPAA) for health care-related transactions.
With a language as verbose as XML, the test data should be maintained separately from the templates and merged only for execution. Default values should be provided for any data elements not critical to the verification of a particular service in order to keep the volumes manageable. This shields subject matter experts from the details of formatting, minimizes the opportunity for formatting errors and permits verification of the templates against standards.
Once the templates and data values are merged into useful messages they can be used to verify every layer of the architecture. Isolating a consumer or provider application can be done by substituting a message stored in a data file for the other side of the transaction. For example, a consumer request can be sent to a file or a reply received from a file instead of the provider.
|
Print this Story |
|
Send Us Feedback |
|
E-mail this Story |
|
Digg this Story |
|
Slashdot this Story |
|
|
|
|
|
 |
|
All Zones Application Performance Zone Business Continuity Zone Data Center Management Zone Enterprise-Class Security Zone The File Data Management Zone Grid Computing on Windows Zone Security Management Zone ITIL Best Practices Zone The SAS Zone Storage Virtualization Zone Business Intelligence and Analytics Zone |
 See your link here
|
 |
||||||||
| ||||||||
| ||||||||
| ||||||||
|
Download this white paper, free, compliments of Novell!
Safeguarding Critical Data
Read up on the latest ideas and technologies from companies that sell hardware, software and services.
- Microsoft promises four patches next week
- Google gives away home-cooked Web application security scanner
- Expect iPhone, Fourth of July scams, security firm says
- More top stories
Intercept Spam & Viruses With MessageLabs MessageLabs is offering a complimentary 30 day trial of its managed Anti-virus and Anti-spam security solutions. MessageLabs guarantees complete protection against all know and unknown email threats. By providing 24 hour support, your business can increase productivity and decrease risk. Register for a complimentary trial and receive a free datasheet.Download this white paper now!
|
| Detect, identify, and locate RF interference in 802.11 WLANs. AnalyzeAir software provides IT network professionals with the vision they need into the hidden world of RF, providing them with the ability to see the spectrum in a visible and intelligible format. AnalyzeAir software lets you see, monitor, analyze, and manage all the RF sources and wireless devices that influence your Wi-Fi network's performance and security, even if those devices are unauthorized or transient. AnalyzeAir Trial Software v3.1 highlights the features found in AnalyzeAir Software using a set of saved spectrum files. Replay the data and experience the visibility that AnalyzeAir Wi-Fi Spectrum Analyzer provides. Note: The trial software is limited to a player version only. It does not communicate with an AnalyzeAir PC card so it does not collect actual spectrum data. Register for this trial now.
|
CIO
Computerworld
CSO
DEMO
GamePro
Games.net
IDG Connect
IDG World Expo
Infoworld
The Industry Standard
ITworld
JavaWorld
LinuxWorld
MacUser
Macworld
Network World
PC World
Playlist
Copyright © 2008 Computerworld Inc. All
rights reserved. Reproduction in whole or in part in any form or medium
without express written permission of Computerworld Inc. is prohibited.
Computerworld and Computerworld.com and the respective logos are
trademarks of International Data Group Inc.
|
