SOA Quality Assurance Distributed Environment Testing Strategies Issues

SOA Quality Assurance Distributed Environment Testing Strategies, Issues and Best Practices

SOA – Services Oriented Architecture SOA is the journey to an elusive destination. Service orientation is all about agility, reuse and business focus The meaning of the term is dualistic: It is both abstract business and technical at the same time. A continuum between philosophy and code. It is not a specific technology or product, but a collection of enabling technologies, standards and products put together as a SOA

Semantic layer provides business representation of data User Lifecycle Administration User Administration Resource Access Control Event Management

A Solution – Service Oriented Architectures Service Capabilities performed by one for another to achieve a desired outcome SOA - A paradigm that encourages organizations to rethink how their IT capabilities are organized Oriented Functionally aligning architecture to enable a collection of independent services to be linked together to solve a business problem Architecture The fundamental organization of a system embodied in its capabilities, their interactions, and the environment SOA is an approach to organizing and using IT to match and combine needs with capabilities in support of the overall mission of an enterprise

Difficult decisions Model-Based Concurrent Engineering Processes Of course strategy is hard it’s about making tough choices. Vision

SOA Quality Assurance Testing Problem Distributed Environment Redefines QA Distributed = Evolving Distributed Computing Systems New software relies on old running systems Testing environment cannot be controlled Scale testing a special problem Requires new relationships and responsibilities for Service Producers and Service Consumers Requires a SOA Core Service Broker Service Level Agreements Core Enterprise Services, Registry and Metadata Repository Accreditation and Certification Services

What is SOA? The nexus between IT and Business – allow for a common dialog An new approach to both IT and Business gets done Reuse Agility Efficiency Loosely-Coupled Sharing

What is SOA not? SOA is NOT. . . Web. Services, Enterprise Service Bus, etc. SOA tools and software NOT a panacea SOA Infrastructure software is NOT a replacement for sound distributed systems engineering SOA tools will NOT address required Social Engineering SOA tools and Infrastructure software will NOT be universally and consistently understood Get help from your vendors and understand that most SOA tools can be used cooperatively Message-Oriented Middleware asynchronous != loosely coupled Understand the differences between Broker-based ESB and MOM-based ESB New A Methodology

SOA is not a Thing It’s not even an Architecture … it’s just an approach toward an architecture (of which distributed systems architectures are the most applicable). It’s a way of thinking and working such that the product of the work results in a systems that is: Agile and Adaptable Engenders reuse Encourages and Enables Sharing of Existing Systems and Data The SOA Products offerings only provide a toolbox of technical solutions, not a “silver bullet. ”

SOA is not a Methodology SOA nor SOA tools DO NOT do Distributed Engineering for you ESB does not solve ALL design problems MOM or EAI solutions are engineering solutions for specific Distributed Engineering problems The only thing harder than designing and building a complex distributed system is TESTING and DEBUGGING them

SOA Governance I’m not sure what this is really it. Nor do I know anyone else who has a really good answer. “The Nexus between politics and operations” Comprised of Policies, Procedures and Metrics Service Lifecycle Governance Tools: UDDI Registry Metadata Repository Web. Services Management (SOA Software [Blue. Titan], Amber. Point, etc. ) Traditional Enterprise Management Systems (Tivoli, HP Open. View, BPM Patrol, etc. ) Governance usually optimized for one of several outcomes: Reuse – The Cornerstone of Reuse is Communication Agility Positive Financial Outcome Sharing SOA Governance is just beginning to mature “Draconian”, “Autocratic”, “Oligarchy” or “Facist” Governance does not work well in large organizations Understanding how to govern large

Usual System Testing Development Environment Continuous Integration Unit and Integration Testing QA Environment Protected environment Scale Testing Hardware identical to Production Environment Separate network Production Environment Same as QA Environment Handles multiple Security Enclaves (NIPR, SIPR, JWICS)

Issues with Distributed SOA Testing It impossible to perform traditional QA testing a Distributed Environment Multiple Producer supported environments Development Unit-Test Scale-Testing Production Secure enclave testing required standalone service Producers must provide packaged service for SCIF based development Like to use VMWare or other Hypervisor technology to reduce technology burden on consumer. What happens if the service is a composite service? Even with SCIF based development, final scale and functional testing wants to use the provider-hosted service

Issues with Distributed SOA Testing There is no “Global” synchronized clock All event correlation required use of cause-event based clocks – otherwise known as Lamport Clocks. Unclear how to do this is a large-scale coordinated way Auditing and Logging Consistently available common logging and auditing services are required. Should be provided by a shared service infrastructure (NCES? ) NCES does not list this as a common service nor a segment of Enterprise Service Management

Adding Friction Producer Accreditation and Certification Producing “Composite” Services Consumer Friction Usage friction – adding hurdles to utilizing shared data and services Vetting consumers in various degrees Root-case analysis problems with provided composite services

Responsibility of Service Providers Provide the service using a “Community Standard” interface Web. Services: XML, XSD, HTTP, SOAP, etc. JMS, FTP, SMTP NOT: MQ Series, . NET, Proprietary “extensions” to Standards Provide an Accredited Service Assert that the services lives up to “Total Assurance or Service Safety” policies and standards Register the Service with the Shared Service Infrastructure provider Handle the Unintended User?

Responsibility of Service Consumers Use the service the way the producers intended it to be used Access service via brokered channel Access via Shared Service Infrastructure as opposed to direct access No “unintended” Denial-of-Service attacks No oversized payloads No unreasonable SLA expectations Open QA results Report errors promptly Utilize auditing, logging, security, etc. where possible

Role of the Broker-based Infrastructure Provide the Authoritative Registry and Metadata Repository Registry for Run-time Repository for Design-time Provide the Accreditation and Certification Service Functional Security / IA (Information Architecture) Service Level Agreement Ranges Provide SLA Adjudication Services Concept: SLA in the “Eye of the Consumer” Provide Metrics publishing for Governance Provide Scalable Service Network Provide automatic “Testing Mode” switching

Conclusion SOA is a dangerously overused acronym that required specific definition in each organization Your Organization with SOA done correctly will display the emergent properties of Agility, Reuse, Efficiency, Loosely. Coupling, etc. Functional Testing (QA) is brutally difficult to do in an open Distributed Computing Environment Governance from Broker, Provider and Consumer is not a solved problem Most challenges in Your Organization service creations and usage will depend greatly on how Social Engineering and Communication is accomplished