SOA Glossary and Acronyms: Welcome To SOA Test .Info ..This Blog Is Dedicated To SOA Testing Home

Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

SOA Test - SOA Testing - Part 2 Welcome to SOA Test .info ..

This Blog is dedicated to SOA Testing


l

Page 1 of 5

Home
Search

SOA Testing

Comments Posts

SOA Glossary and Acronyms


Access Services Access services are dedicated to integrating legacy applications and functions into the service-oriented architecture. This includes simple wrapping of those functions and rendering them as services (in the case where the existing function is a good match with the semantic requirements of the business model in which it will be used), or in more complex cases augmenting the logic of the existing function to better meet the needs of the business design. In the latter case, the access service may in fact invoke multiple legacy functions to achieve the semantic requirements of the service. In other architectures we have often referred to these access services as adapters. In the SOA Foundation architecture, access services are distinctly responsible for rendering these adapters as services so that they can be manipulated and composed within business processes like any other service component. Business Application Services Business application services implement your core business logic. These are service components created specifically as services within a business model and that represent the basic building blocks of your business design services that are not decomposable within the business model, but that can be composed to form higher level services. Information Services Information services contain the data logic of your business design. Interaction Services Interaction services are about the presentation logic of the business design components that support the interaction between applications and end-users. Also we recognize that interactions with the external world are not limited to just interactions with humans. In some cases, interaction logic orchestrates the interface to industrial robots, vehicles, sensors, RFID devices, environmental control systems, process control equipment, etc. Operational Infrastructure The runtime infrastructure used to execute the SOA. Partner Services Partner services capture the semantics of partner interoperability that have a direct representation in the business design. This can, for example, include the policies and constraints that other businesses must conform to work with your business including business vertical requirements such as the need to conform to specific industry message and interchange standards like EDIFACT, SWIFT, RosettaNet, etc. It can involve the business logic of managing how partners are selected, and which ones are used as a preference over others in particular circumstances. Service Versioning Service provider and consumer are autonomous, independent entities. Service implementation and interface may change over time. We need to control, track and assure the quality of the changing. SLA http://soatest.info/page/2 1/22/2010

SOA Test - SOA Testing - Part 2

Page 2 of 5

SLAs are agreements between a service provider and a customer and as such define the obligations of the parties involved. Primarily, this is the obligation of a service provider to perform a service according to agreed-upon guarantees for IT-level service parameters (such as availability, response time and throughput) for Services. Transformation The mediation transforms messages and maps operations, adapting the required interface to the implemented interface. SOA Service Oriented Architecture (or 47 other possible meanings) WSDL Web Service Definition Language UDDI Universal Description, Discovery and Integration SOAP Simple Object Access Protocol (XML protocol) REST Representational State Transfer WSIL Web Services Inspection Language WS-BPEL Business Process Execution Language (for Web Services) SLA Service Level Agreement MIME Multipurpose Internet Mail Extensions XML eXtensible Markup Language W3C World Wide Web Consortium WS-I Web Services Interoperability Organization Protocols HTTP Hypertext Transfer Protocol (world wide web protocol) HTTPS Hyper Text Transfer Protocol Secure sockets TCP/IP Transmission Control Protocol/Internet Protocol Be the first to comment - What do you think? Posted by admin2 - October 31, 2009 at 1:25 pm Categories: SOA Testing Tags:

SOA Test Case Design


Test Test Cases can be designed using following steps:
l l l

A test scenario can use a single service (e.g. Web Service) A test scenario can test multiple services (e.g. user interface, Web Services) Test scenarios should be written to be environment indifferent, to help reuse. A few exceptions are listed below. A test scenario can test the environment without the SOA solution, to verify the environment is correct and functional. A test scenario should describe how the test environment will be used (e.g., user interface connected to a web service) Any differences in the test environment should equate to different test scenarios (e.g., DB2 database is used) A test scenario should list the data that will be used to show how the objective will be met (e.g. set of values to be entered in the user interface). Unit Test Regression and some form of Integration Test Regression, including, but not limited to, web services, business processes and common modules. The objective of such testing is to provide early detection of code regressions. Testing on shorter regression cycles in the presence of more rapid updates to services requires up

http://soatest.info/page/2

1/22/2010

SOA Test - SOA Testing - Part 2

Page 3 of 5

to date knowledge of what function was changed and the system test cases that pertain to the changed function. Whenever a service is changed (either definition or implementation) it is also necessary know all the services that could potentially be impacted so that regression testing of the impacted services can also be performed. Be the first to comment - What do you think? Posted by admin2 - at 1:22 pm Categories: SOA Testing Tags:

SOA testing best practices


The reusable nature of SOA can make the testing of Service Oriented Architecture applications further complex. Services are designed and built to be reused. We may or may not know who else may use them or how they will be consumed. This forces us to define test objectives to ensure that individual production services will perform satisfactorily regardless of how they are consumed. Here some of the best practices you need to keep in mind while doing SOA Testing: 1. Ensuring that business requirements are met sounds simple enough. Loose coupling of services makes it particularly important to test the business choreography and business rules of the applications. The process/business choreography may be handled by external business process tools. You need to ensure that business requirements meet technology to deliver the desired results. As the business services become more fine-grained and more of the process logic is handled by tools external to the application code, it becomes difficult to determine which technology or application component isnt meeting the requirements. 2. End-to-End Testing takes on a new meaning for Service Oriented Architecture testing. In traditional (non-services based) application programming, the end points are well defined and its clear what is expected. Thats not necessarily the case for SOA applications. Services are reusable both within an application and across applications. System testing includes both testing the individual services as well as testing the business processes, which are a choreographed set of services. There are several cases that need to be considered. Your application uses existing (legacy or heritage) services. The original applications are stable and continue to run in a production environment. The new application you are testing is invoking these services in a (potentially) new Service Oriented Architecture way for the first time. This makes it very important to understand and set your test objectives very carefully to ensure that all possible end-to-end scenarios are covered. Your application may be creating new services that will be used by other applications in the future. Its important to consider how those services might be used. They may be invoked from different environments, by different user groups, or from different geographies. Your test plan and test scenarios need to be written such that they are as reusable as the services they test. Some of the services you need may be provided by 3rd party or vendor products. Its important to ensure that those services meet the needs of your application and continue to perform consistently as new versions of the services are provided by the vendor. Security testing will be based on the security policies set for the enterprise and the application. Specific objectives should include things like ensuring that your security requirements are satisfied regardless of who uses the services and how. Consider how your security infrastructure will interact with the various application layers and technologies used. This includes the middleware (including an Enterprise Service Bus or ESB), application servers, process servers, and application code. These can span server environments or geographies. A specific SOA case which should be considered and tested is that of a

http://soatest.info/page/2

1/22/2010

SOA Test - SOA Testing - Part 2

Page 4 of 5

business process invoking multiple services, on behalf of the user of that process. What must be tested is if the user is or should be able to access the various IT components (usually applications) which are invoked by the various services or not. Be the first to comment - What do you think? Posted by admin2 - at 1:15 pm Categories: SOA Testing Tags:

SOA Testing Challenges


Some characteristics of SOA that present unique challenges in testing Service Oriented Architecture applications are: 1. The full business process is in play (many different applications running on many platforms and systems. This requires good amount of business as well as system level knowledge to test it properly. 2. All of the pieces of that process need to be verified in isolation as well as in working in conjunction (requires a bottom-up, phased testing approach) 3. Validating of the integration of an entire business process resulted in the intended execution of transactions, interactions, and data transformations. We need to check many data points and many test results that need to be organized and verified together which would be a big challenge. 4. There will be a big number of permutations and combinations of paths through an SOA system (requires well engineered repeatability and regression libraries to be developed and maintained) 5. There is a domino effect when a small error is introduced into an Service Oriented Architecture (a small error can affect many business processes, so vigilance and thoroughness are key, and another reason regression testing is of vital importance) 6. Services can be changed frequently. 7. Services can be used off the shelf and to which total control may not be available. Be the first to comment - What do you think? Posted by admin2 - at 12:52 pm Categories: SOA Testing Tags:

What Is SOA: SOA is different things to different people


SOA is different things to different people: From pure definition perspective SOA is defines as Distributed Component Based Software Engineering with Standards. For a Business executive SOA is a set of services that a business wants to expose to their customers and partners, or other portions of the organization. The IT architect sees the Service Oriented Architecture as an architectural style which requires a service provider, requestor and a service description. In other words it is a set of architectural principles, patterns and criteria which address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, composability. For a Software Developer the SOA is: 1. A programming model complete with standards, tools and technologies such as Web Services 2. A middleware solution optimized for service assembly, orchestration, monitoring, and management. Be the first to comment - What do you think? Posted by admin2 - at 11:15 am Categories: SOA Testing Tags:

http://soatest.info/page/2

1/22/2010

SOA Test - SOA Testing - Part 2 Previous Page Next Page


l

Page 5 of 5

Recent Posts SOA Principles and Patterns What is SOA? What is SOA Test? What is a reusable Service? What are the main benefits of SOA ? SOA Glossary and Acronyms SOA Test Case Design SOA testing best practices SOA Testing Challenges What Is SOA: SOA is different things to different people Web Principles Explained The SOA Testing approach What is SOA? SOA Overview Categories
SOA Testing Archives

December 2009 October 2009 August 2009 July 2009 SOA News

Implementing SOA Using Java EE: Evolution of Service Oriented Architecture - informIT The Busy Executive's SOA Reference Guide - SYS-CON Media (press release) Solutions Architect (SOA,SOMA,IFW) - CBD Location - 6 Month Contract - iT News The decade of development - ITWeb Salary Stagnation Leaves IT Pros Dissatisfied - eWeek The Open Group Balances Exploration of Next Generation SOA with Development of ... PR Newswire (press release) Mid-Continent Group Selects SOA-Enabled Camilion Authority Suite - ebizQ Unravelling the SOA, BPM relationship - ITWeb Four SOA Watch protestors due in federal court Jan. 25 - Columbus Ledger-Enquirer Clouds, Virtualization, and SOA - No Jitter (blog)

WordPress Theme by HeatMapTheme.com

http://soatest.info/page/2

1/22/2010

You might also like