SOA Quality Assurance

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

2. 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

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

4. Service 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 SOA - A paradigm that encourages organizations to re-think how their IT capabilities are organized Capabilities performed by one for another to achieve a desired outcome 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 A Solution – Service Oriented Architectures

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

6. 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

7. 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

8. What is SOA not? • SOA is NOT ... • WebServices, Enterprise Service Bus, etc. • SOA tools and software are 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

9. 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.”

10. 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

11. 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 • WebServices Management (SOA Software [BlueTitan], AmberPoint, etc.) • Traditional Enterprise Management Systems (Tivoli, HP OpenView, 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

12. 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)

13. 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

14. 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

15. Adding Friction • Producer 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

16. Responsibility of Service Providers • Provide the service using a “Community Standard” interface • WebServices: 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?

17. 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

18. 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

19. 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