Jeff Simpson Federal SOA Architect

1. SOA Quality Assurance:Distributed Environment Testing Strategies, Issues and Best Practices in Net-Centric Operations and Warfare Jeff Simpson Federal SOA Architect

2. An opening thought “It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.” Charles Darwin

3. SOA Quality Assurance Testing Problem • Net-Centric Environment Redefines QA • Net-Centric = 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

4. What is SOA? Oh, no … not another “What is SOA?” slide

5. What is SOA? • SOA is … • The latest acronym that represents the Savior Of Architects and “Marketeers” after they have beaten OO, Java, etc. into the ground.

6. What is SOA? • SOA is …(seriously) • 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 No. These are emergent attributes or properties, not the definition

7. What is SOA? • SOA is … (my definition) • SOA represents the current level of maturity of the practice of Distributed Computing Systems • It connotes a “sharing” paradigm and doctrine shift • It connotes Moving from the “Need to Know” doctrine (reactive) to the “Need to Share” doctrine (proactive) “Need to Know”  “Need to Share” + “Authority to Know” • Environment Redefines QA into Total Assurance • Services need to be compliant with “Safety Policies” with cover Functionality, Security, Operations and Standards • NCOW = Evolving Distributed Computing Systems

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. Different Things to Different Peopleor … Back to the Future “My guess is that object-oriented programming will be in the 1980’s what structured programming was in the 1970’s. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is”. Tim Rentch Excerpt from Object-Oriented Analysis and Design by Grady Booch Service-Oriented Architecture Object-Oriented Architecture 1990’s 2000’s

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

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

12. 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 operations as large as NCOW is unclear

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

14. Issues with Net-Centric SOA Testing • It impossible to perform traditional QA testing a Net-Centric 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

15. Issues with Net-Centric 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 Mangement

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

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

18. The Unintended User? • There is much talk about the Unintended User. • I’m not sure what people are talking about any more with that term. • I think people mean: The Unanticipated User • Some definitions may be in order: • The Unanticipated User: • A user that you simply did not expect to show up and use your service. • This problem is solved by adequately scaling your service. Solutions include running service in a Cluster or “Virtualize” the service. • The Unknown User: • A user that shows up to use the service, regardless of whether you capacity planned for them, that are not authorized. • This problem is solved by dynamically changing security profiles and access control. • The Unintended User (a.k.a. the Demanding User) • A user that is probably known, and authorized, but does not want to use your service the way it was intended to be used. • Will need to “pay a premium” to the services producer

19. 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 (NCES) 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 CES auditing, logging, security, etc. where possible

20. 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 • Service Level Agreement Ranges • Provide SLA Adjudication Services • NCOW Concept: SLA in the “Eye of the Consumer” • Provide Metrics publishing for Governance • Provide Scalable Service Network • Provide automatic “Testing Mode” switching

21. Conclusion • SOA is a dangerously overused acronym that required specific definition in the context of NCOW. • NCOW 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 • The Social Engineering is a “long pole” in the tent • Governance from Broker, Provider and Consumer is not a solved problem • Most challenges in NCOW serivce creation and usage will depend greatly on how Social Engineering and Communication is accomplished

22. Thank You jsimpson@bea.com