Lecture notes for SOA

8,821 views

Published on

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,821
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
424
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • The Information Dissemination Management began as a JROC recognized initiative in 1999 It evolved from the BADD and BC2A ACTDs where the need was itdentified for a capability to ensure the right information gets to the right person at the right time in the right format at the right place. The JROC approved the MNS in July 1999 and in January 2001 approved the JFCOM-sponsored CRD The MCEB, recognizing the need to set up an interagency working group, established in the third quarter of 2000 the IDM PWG which has representatives from all CINCS, Services, and several key agencies Now, this working group, working under the auspices of the MCEB NETOPS Panel are tackling headlong IDM operational and development issues Under this group, DISA has already made ground-breaking work on crafting a framework on IDM requirements for their IDM software development initiative. This requirements framework will form the basis for a full-up Operational Requirements Document Concurrently, the GBS program has taken on shape and is already operational at three CINCS, with CENTCOM being the latest edition. These CINCS are incorporating IDM concepts in functions into their Theater Information Management cell tactics, techniques, and procedures
  • Detect Reconfiguration Request Runtime validation of reconfiguration plan Runtime Service dependency analysis Prepare the system for reconfiguration by driving the affected services to the reconfigurable state Enforce the reconfiguration action Add, Remove, link and unlink.
  • Lecture notes for SOA

    1. 1. Service-Oriented Computing (SOC) and Service-Oriented Architecture (SOA) W. T. Tsai Department of Computer Science and Engineering Arizona State University Tempe, AZ 85287 [email_address]
    2. 2. Definition of Service <ul><li>A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. </li></ul><ul><li>A service in SOA can be a web service (WS), but not necessarily be. Any self-contained well-defined components, not necessarily on the web, can be used in an SOA application. </li></ul>
    3. 3. Definition of SOA <ul><li>A Service-Oriented Architecture (SOA) is a system consisting of modular software components with standardized component-access and usage interfaces that are independent of any specific platform or implementation technology. </li></ul><ul><li>At its most basic, an SOA is simply a collection of standardized services on a network that communicate with one another in the context of a business process. </li></ul>
    4. 4. Example of SOA <ul><li>This definition of SOA is a bit too abstract, but SOA is actually everywhere. </li></ul><ul><li>Let's look at an example of SOA which is likely to be found in your living room. Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different. </li></ul>
    5. 5. Difference from OO Programming <ul><li>The idea of SOA departs significantly from that of OO programming, which strongly suggests that you should bind data and its processing together. So, in OO programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems. </li></ul>
    6. 6. Difference from Web Service <ul><li>Web services does not equal service-oriented architecture . Web services is a collection of technologies, including XML, SOAP, WSDL, and UDDI, which let you build programming solutions for specific messaging and application integration problems. </li></ul><ul><li>Over time, you can reasonably expect these technologies to mature, and eventually be replaced with better, more efficient, or more robust ones. </li></ul><ul><li>They are, at the very least, a proof of concept that SOAs can finally be implemented. So what actually does constitute a SOA? </li></ul>
    7. 7. Difference from Web Service (Cont.) * The above table is from Microsoft’s website [1]
    8. 8. Difference from Web Service (Cont.) <ul><li>SOA is just an architecture. It is more than any particular set of technologies, such as Web services; it transcends them, and, in a perfect world, is totally independent of them. Within a business environment, a pure architectural definition of a SOA might be something like &quot;an application architecture within which all functions are defined as independent services with well-defined invokable interfaces which can be called in defined sequences to form business processes&quot;. Note what is being said here: </li></ul><ul><ul><ul><li>All functions are defined as services. </li></ul></ul></ul><ul><ul><ul><li>All services are independent. </li></ul></ul></ul><ul><ul><ul><li>In the most general sense, the interfaces are invokable; </li></ul></ul></ul>
    9. 9. Why we need SOA for IT management? <ul><li>Systinet [3] discusses the advantages to apply SOA on IT management. </li></ul><ul><li>An SOA enables software components to become standard services that can be invoked at runtime or on demand. </li></ul><ul><li>A business-driven SOA strategy will help focus on the goal of Dynamic Business Interoperability and lead to achievement of desired business outcomes. </li></ul>
    10. 10. Advantages of SOA <ul><li>First, SOAs make interoperability an innate characteristic of IT systems and applications built using this approach because the resulting loosely coupled and modular components share common communication and interface description mechanism. Organizations don’t have to invest inordinate amounts of time and resources writing code to connect applications, only to have to rewrite code again if small changes are made to the system. </li></ul><ul><li>Second, SOAs make IT more agile and more responsive to business process changes. Since services represent high-level business logic, IT is encouraged to think in terms of business functions. With SOA, IT systems begin to accurately and quickly adapt to organizational goals and processes. SOAs also make IT highly tolerant of change because reconfiguring loosely coupled services is simple, fast and low-cost. With an SOA, IT is able to react quickly to changing business demands, new requirements, or new processes. </li></ul>
    11. 11. What you need to think about when building SOA? <ul><li>Understand the Business Model </li></ul><ul><li>Focus on Interoperability </li></ul><ul><li>Focus on Business Agility </li></ul><ul><li>Define and Enforce Application Interoperability Policies </li></ul><ul><ul><ul><li>How Web services will be used? </li></ul></ul></ul><ul><ul><ul><li>What standards and interoperability policies must be defined and enforced? </li></ul></ul></ul><ul><ul><ul><li>How these will be driven within a SOA context? </li></ul></ul></ul><ul><li>Change IT Procurement Policies </li></ul><ul><ul><ul><li>Ongoing management of your SOA will demand vendor compliance to your SOA strategy and interoperability policy. </li></ul></ul></ul>
    12. 12. What you need to think about when building SOA? (Cont.) <ul><li>Transform Your IT Development Processes and Policies </li></ul><ul><ul><ul><li>The compliance to WS-I and internal standards should be enforced at design and runtime using available WSM and SOA enforcement tools. </li></ul></ul></ul><ul><li>Define and Enforce Your Business Interoperability Policies </li></ul><ul><li>Monitor, Measure and Analyze SOA Service Network </li></ul><ul><ul><ul><li>Are the services leveraging one another in a symbiotic network fashion? </li></ul></ul></ul><ul><ul><ul><li>Are we getting the maximum interoperability and services reuse from our SOA? If not, why not? Are policies being enforced at design and run-time? </li></ul></ul></ul><ul><ul><ul><li>Do we have a truly interoperability-based SOA or do we have islands of business and Web services? How can we unite these services? </li></ul></ul></ul><ul><ul><ul><li>Finally, were your initial SOA business goals met? How can we improve our performance? If our goals were not met, why not? What must be done? </li></ul></ul></ul>
    13. 13. Top-Level Processes <ul><li>The process of delivering the service implementation </li></ul><ul><ul><ul><li>'Traditional' Development </li></ul></ul></ul><ul><ul><ul><li>Programming </li></ul></ul></ul><ul><ul><ul><li>Web Services automated by tools </li></ul></ul></ul><ul><li>The provisioning of the service—the life cycle of the service as a reusable artifact </li></ul><ul><ul><ul><li>Commercial Orientation </li></ul></ul></ul><ul><ul><ul><li>Internal and External View </li></ul></ul></ul><ul><ul><ul><li>Service Level Management </li></ul></ul></ul><ul><li>The consumption process </li></ul><ul><ul><ul><li>Business Process Driven </li></ul></ul></ul><ul><ul><ul><li>Service Consumer could be internal or external </li></ul></ul></ul><ul><ul><ul><li>Solution assembly from Services, not code </li></ul></ul></ul><ul><ul><ul><li>Increasingly graphical, declarative development approach </li></ul></ul></ul><ul><ul><ul><li>Could be undertaken by business analyst or knowledge worker </li></ul></ul></ul>
    14. 14. SOA Process <ul><li>SOA Planning </li></ul><ul><ul><ul><li>SOA business services are defined and created based on the business model. </li></ul></ul></ul><ul><li>SOA Enablement </li></ul><ul><ul><ul><li>Service Provider-enablement. </li></ul></ul></ul><ul><ul><ul><li>Service Consumer-enablement. </li></ul></ul></ul><ul><ul><ul><li>Standards-based business service registry. </li></ul></ul></ul><ul><ul><ul><li>Supporting infrastructure such as Web services management, identity management, and service-oriented messaging services. </li></ul></ul></ul><ul><li>SOA Publishing </li></ul><ul><ul><ul><li>Definition of the procedures and policies, like: </li></ul></ul></ul><ul><ul><ul><ul><li>Who is allowed to publish a service to the registry? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>What release procedures must be followed? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>How will various designs, standards and security policies be approved, certified and enforced in the SOA? </li></ul></ul></ul></ul>
    15. 15. SOA Process (Cont.) <ul><li>SOA Discovery </li></ul><ul><ul><ul><li>Use UDDI </li></ul></ul></ul><ul><li>SOA Management </li></ul><ul><ul><ul><li>Building and deploying the ability to understand and manage relationships between business services </li></ul></ul></ul><ul><ul><ul><li>Component versioning and dependencies </li></ul></ul></ul><ul><ul><ul><li>Effecting reconfiguration of various aspects of a deployment such as location, transport, security and policy parameters </li></ul></ul></ul><ul><li>SOA Analysis </li></ul><ul><ul><ul><li>Monitoring and feedback mechanisms to help optimize SOA and ultimately, enable an organization’s business processes by SOA </li></ul></ul></ul><ul><ul><ul><li>Monitoring services status, users, usages, and metrics that indicate relative success of various business services in the SOA services portfolio </li></ul></ul></ul><ul><ul><ul><li>Providing impact and dependency analysis of individual services, groupings of services based on custom taxonomies (enabled by the registry) </li></ul></ul></ul><ul><ul><ul><li>Reporting on a wide variety of issues – business, IT, SOA, reuse, policy violations or compliance reporting, and so on </li></ul></ul></ul>
    16. 16. SOA Dynamic Discovery <ul><li>Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following: </li></ul><ul><ul><ul><li>Scalability of services; you can add services incrementally. </li></ul></ul></ul><ul><ul><ul><li>Decouples consumers from providers. </li></ul></ul></ul><ul><ul><ul><li>Allows for hot updates of services. </li></ul></ul></ul><ul><ul><ul><li>Provides a look-up service for consumers. </li></ul></ul></ul><ul><ul><ul><li>Allows consumers to choose between providers at runtime rather than hard-coding a single provider. </li></ul></ul></ul>
    17. 17. A Typical Architecture for a Service-Oriented Application <ul><li>Like any distributed application, service-oriented applications are multi-tier applications and have presentation, business logic, and persistence layers. The two key tiers in SOA are the services layer and the business process layer. </li></ul>
    18. 18. SOA Architectural Perspective <ul><li>The following three SOA architectures need to be considered: </li></ul><ul><ul><ul><li>The Application Architecture . This is the business facing solution which consumes services from one or more providers and integrates them into the business processes. </li></ul></ul></ul><ul><ul><ul><li>The Service Architecture . This provides a bridge between the implementations and the consuming applications, creating a logical view of sets of services which are available for use, invoked by a common interface and management architecture. </li></ul></ul></ul><ul><ul><ul><li>The Component Architecture . This describes the various environments supporting the implemented applications, the business objects and their implementations. </li></ul></ul></ul>
    19. 19. SOA Architectural Perspective (Cont.)
    20. 20. Basic Components of SOA Architecture <ul><li>Service providers . A service provider is a component or set of components that execute a business function in a stateless fashion, accepting predefined inputs and outputs. </li></ul><ul><li>Service consumers . A service consumer is a set of components interested in using one or more of the services provided by service providers. </li></ul><ul><li>Service repository . A service repository contains the descriptions of the services. Service providers register their services in this repository and service consumers access the repository to discover the services being provided. </li></ul>
    21. 21. Basic Components of SOA Architecture (Cont.)
    22. 22. SOA Challenges and Solutions <ul><li>While implementing a SOA, a company faces up to eight key challenges. These challenges align to the steps in a typical project deployment plan: </li></ul><ul><ul><ul><li>Service identification . What is a service? What is the business functionality to be provided by a given service? What is the optimal granularity of the service? </li></ul></ul></ul><ul><ul><ul><li>Service location . Where should a service be located within the enterprise? </li></ul></ul></ul><ul><ul><ul><li>Service domain definition . How should services be grouped together into logical domains? </li></ul></ul></ul><ul><ul><ul><li>Service packaging . How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services? </li></ul></ul></ul><ul><ul><ul><li>Service orchestration . How are composite services to be orchestrated? </li></ul></ul></ul><ul><ul><ul><li>Service routing . How are requests from service consumers to be routed to the appropriate service and/or service domain? </li></ul></ul></ul><ul><ul><ul><li>Service governance . How will the enterprise exercise governance processes to administer and maintain services? </li></ul></ul></ul><ul><ul><ul><li>Service messaging standards adoption . How will the enterprise adopt a given standard consistently? </li></ul></ul></ul>
    23. 23. Another Challenge of Current SOA <ul><li>However, current SOA can not satisfy the survivability requirements. It fails to discover and rebind to available services automatically upon the failure or overload of the on-duty service. </li></ul><ul><ul><ul><li>Mission-critical systems will be subjected to various attacks including physical attacks as well as electronic attacks. </li></ul></ul></ul><ul><ul><ul><li>One key feature of survivability is that the system is able to dynamically reconfigure in case of failures or overload. </li></ul></ul></ul><ul><li>The solution of this problem is service-oriented distributed dynamic reconfiguration. </li></ul>
    24. 24. Potential Application: NCES Vision Core Enterprise Services (CES) Comms Backbone Community-of-Interest (COI) Capabilities Users Messaging ESM Discovery Collaboration Mediation Security/IA App Storage User Asst Levels of Services above core level Support real-time & near-real-time warrior needs and business users 05/06/10 C2 Intel Weapon Systems Dynamically Created COIs Logistics Sensors Personnel Finance Etc.
    25. 25. Requirements for the distributed dynamic reconfiguration. <ul><li>Efficiency: the reconfiguration algorithm should introduce minimum disruption to the system </li></ul><ul><li>Consistency: the reconfiguration action should maintain the consistency of related components after reconfiguration. </li></ul><ul><li>Correctness: Reconfiguration constraints must be satisfied at all the times. </li></ul><ul><li>Real time: Reconfiguration must be carried out in real time at runtime for mission-critical C2 system . </li></ul><ul><ul><li>Real time means within a time limit </li></ul></ul><ul><ul><li>Runtime means that the reconfiguration must be carried out while the system is still in operation. </li></ul></ul>
    26. 26. Requirements for the distributed dynamic reconfiguration (cont’) <ul><li>Policy driven: system is governed by business policy, possibly distributed policies. </li></ul><ul><li>Distributed and parallel execution. </li></ul><ul><ul><li>Reconfiguration actions are executed by the distributed agents and the reconfiguration actions are done in parallel among these agents. </li></ul></ul><ul><li>Service-oriented </li></ul><ul><ul><li>The dynamic reconfiguration server or agents are themselves services in the SOA, so that they can be reconfigured too in case of their own failures. </li></ul></ul><ul><li>Dynamic Reconfiguration with hierarchical and layered system </li></ul><ul><ul><li>This promotes survivability </li></ul></ul>
    27. 27. Solution: Dynamic Reconfiguration Model for SOA
    28. 28. A Layered Partitioning of System with Dynamic Reconfiguration– A Systematic View Network Services
    29. 29. A Layered Partitioning of System with Dynamic Reconfiguration– A Systematic View (cont’) <ul><li>Dynamic Reconfigurability is embedded in each layer of the entire system, and at each level multiple DRS synchronized with each other to avoid any single point of failure. </li></ul>
    30. 30. Hierarchic System Composition with Dynamic Reconfiguration
    31. 31. Hierarchic System Composition with Dynamic Reconfiguration <ul><li>For large scale applications, hierarchic dynamic reconfiguration allows the distributed systems to be constructed in a hierarchical manner. </li></ul><ul><li>A composite system can be constructed from primitive systems with dynamic reconfigurability and these in turns can be constructed into more complex composite system with dynamic reconfigurability. </li></ul>
    32. 32. SOA with Dynamic Reconfiguration <ul><li>Every participating service, including DRS, is a service and each service is treated the same. As a service, the DRS provides the following functions: </li></ul><ul><ul><li>Dynamic service lookup, service publication, service binding, and service profiling, </li></ul></ul><ul><ul><li>Registration and de-registration, </li></ul></ul><ul><ul><li>Runtime services verification including constraint verification such as security verification, interoperability checking, and performance monitoring. </li></ul></ul>
    33. 33. SOA with Dynamic Reconfiguration (cont’) <ul><li>The Dynamic Reconfiguration Service (DRS) is implemented as a critical service with redundancy and the reconfiguration strategies and algorithms can be changed at runtime to fit the warfighting needs. </li></ul><ul><li>With this kind of mechanism, the behavior of the SOA can be changed in real time at runtime, and even the behavior of DRS can be changed too. </li></ul>
    34. 34. Architecture of DRS and its Distributed Agents DRS Coordination Services Clients Services Business Polices Proxy Services Auditing Services Service Register COIs Access Control
    35. 35. Architecture of DRS (cont’) Major Agents <ul><li>Service Directory (SD): This stores and organizes services in a hierarchical tree with internal tree node representing a group of related services. </li></ul><ul><li>Proxy Agents: An Proxy Agent (PA) is responsible for interoperability and integration between DRS, services and their clients. In addition, it also enforces security accessing control. </li></ul><ul><li>Auditing Agents: An Audit Agent (AA) monitors and checks the performance and user concerned properties of the participating services at runtime and updates their profiles. </li></ul>
    36. 36. Reconfiguration Process
    37. 37. Cyclic Flow of Dynamic Reconfiguration Process Services Dynamic Reconfiguration Services Monitoring Services Data COIs Human Participation Real-time Data Reconfiguration Actions Reconfiguration Actions Policies
    38. 38. Dynamic Policy Adaptation and Validation <ul><li>Dynamic Policy Adaptation </li></ul><ul><ul><li>Through the cyclic flow of situation aware of environment data collect and monitoring, reconfiguration policy formation, policy validation and reconfiguration execution. </li></ul></ul><ul><ul><li>Commander in the loop </li></ul></ul><ul><li>Policy Validation </li></ul><ul><ul><li>Reconfiguration Constraints are represented by Meta Business Policy and it will validate the reconfiguration policy in real time at runtime </li></ul></ul>
    39. 39. GIG Enterprise Services SOADR Supports real-time & near-real-time warrior needs DoD (Title 10) IC (Title 50) Users Users Business Domains Warfighter Domains Domain/ COI Capabilities IC Org Spaces National Intelligence Domain Transformational Communications (TC) & Computing Infrastructure ICSIS Community Space Technical Infrastructure Domain Levels of Services Above Core Level Capability Integrator Installations & Environment Human Resources Management Acquisition Strategic Planning & Budget Logistics Accounting & Finance Governance COI’s COI’s Capability Integrator Command & Control Battlespace Awareness Force Application Precision Logistics Protection Governance Net-Centric Enterprise Services (NCES) Application User Assistant Storage Messaging IA/Security IA/Security ESM IA/Security ESM IA/Security ESM Discovery IA/Security ESM Collaboration IA/Security ESM Enterprise Service Management (ESM) Mediation IA/Security ESM IA/Security ESM ESM IA/Security
    40. 40. Cyclic Flow of Dynamic Reconfiguration Process (cont’) <ul><li>The dynamic reconfiguration mechanism is controlled by a set of business policies, and these policies specify appropriate actions to take under various situations. </li></ul><ul><li>These policies can be pre-specified before system operations, but also they can be updated during runtime in real-time by the COI (community of interest) within the system. </li></ul><ul><li>The distributed situation-aware COI monitoring agent detects the changes in the operation environment, it informs the concerned COIs and then these COIs may update their polices to adjust to the changing environment. </li></ul>
    41. 41. Cyclic Flow of Dynamic Reconfiguration Process (cont’) <ul><li>Once the business policies are changed, the dynamic reconfiguration is changed as it is ruled by the policies, even though the overall reconfiguration mechanism remains the same. </li></ul><ul><li>In this way, commanders and decision makers make high-level decisions, based on the latest situation assessment, and let the SOA to actually implementation the transition plan. </li></ul><ul><li>Multiple monitoring agents, COIs, and DRS can participate in this process, and this process is done in a distributed but collaborative manner. </li></ul>
    42. 42. Ontology <ul><li>Why do we use ontology? </li></ul><ul><ul><ul><li>To describe the semantics of the data (which we name as Meta-Data) </li></ul></ul></ul><ul><li>Why do we describe the semantics? </li></ul><ul><ul><ul><li>In order to provide a uniform way to make different parties to understand each other </li></ul></ul></ul><ul><li>Which data? </li></ul><ul><ul><ul><li>Any data (on the web, or in the existing legacy databases) </li></ul></ul></ul>
    43. 43. Why Do We Need Ontology in SOA? <ul><li>First reason is that ontology can be used to represent the relationship and dependencies between services as well as service interactions. It is also useful to perform dynamic service matching. </li></ul><ul><li>Another reason is that, the use of ontology can greatly enhance the service reusability in SOA. A typical example is FERA [4], a collaboration framework proposed by Intel, which enables enterprises to expose their business processes across a federation of enterprises through SOA and therefore enhance the service reusability. One of the weapon to achieve this goal is via ontology. In FERA, the context of collaboration needs to be defined using open standard semantics, while the ontology of contents needs to be consistent across all shared meta-data definitions. This enables the processes to be configured as they fit the business needs and reconfigured when the needs change. </li></ul>
    44. 44. Problems on Testing SOA <ul><li>Even small changes can cause major disruptions in today’s highly interactive and independent applications. </li></ul><ul><li>Unfortunately, the pace of changes means traditional testing architectures with lengthy development and testing will not work. </li></ul><ul><li>But the testing must be done. </li></ul><ul><li>Several SOA testing frameworks have been proposed. Worksoft’s Certify [2] will be discussed as the test management repository and framework solution to this testing problem for XML-based applications. </li></ul>
    45. 45. A Typical SOA-architected Service Solution <ul><li>The following figure shows a typical SOA-architected service solution for an insurance company. </li></ul>
    46. 46. Traditional Solutions <ul><li>Indirect testing and standardization have traditionally provided ways to work around at least some of difficulties associated with these problems. </li></ul><ul><li>But both traditional solutions doesn’t work well on SOA testing. </li></ul>
    47. 47. Problem of Indirect Testing <ul><li>Can these services be tested indirectly? Won’t exercising the provider and consumer applications – those that enable or use the services allow us to uncover problem? The problem is one of timing and data. Such indirect testing can’t be done until late in the development cycle when the cost of correction is very high. Nor does indirect testing provide an effective way to find the source of a problem. These is no enough data about an incorrect transaction or failed result to identify with of at least five places caused the problem: the provider application, the encoding, the transport, the message content or the consumer application. </li></ul><ul><li>Another frustration to indirect testing is found in the ‘boundless’ nature and fundamental promise and power of SOA. A significant part of the attractiveness of SOA comes from the unpredictability of its utilization. SOA applications can be utilized by any application including those not yet developed and accessed by consumers outside the enterprise. It has boundless potential for use. Can’t standards provide us a way out of this dilemma? The answer is not completely. </li></ul>
    48. 48. Standards Don’t Always Help <ul><li>While this standard makes applications integration much more flexible than previously hard-wired connections, it makes testing more complex. A traditional monolithic application has a user interface to allow verification of business functionality, but the layers of an SOA do not offer such an interface – yet they must be tested individually as they are developed and together as they are integrated. </li></ul><ul><li>The only way to test the business functionality of XML messages is through a test interface that allows messages to be created, sent, received and verified either simulated or live. Without it, there is no means of verifying functionality at each integration point. </li></ul><ul><li>Until now, each development group has had to write customized code to provide a test interface to the messaging layer. This adds time and cost to the overall project as well as ongoing maintenance into the future. Further, testing the integration of all layers requires an interface that allows business processes be executed end to end, across applications, platforms and perhaps enterprises. </li></ul><ul><li>Is there no way out of this testing trap? Let’s examine one approach from Worksoft. </li></ul>
    49. 49. Introducing Worksoft’s Certify <ul><li>Worksoft introduced Certify™ to bring the power of a proven test automation repository and framework to the testing of XML messages. Certify provides a straightforward interface for developers, testers, business analysts and expert users to define the format and content of the messages they want to send and receive, whether across a transport protocol or between files. Layers can be tested either standalone or together. Certify can be used to configure the enterprise environment, define the messages, and start exercising business process functionality at every level and interface. </li></ul><ul><li>Certify provides: </li></ul><ul><ul><ul><li>A central repository for all test assets </li></ul></ul></ul><ul><ul><ul><li>Business process automation and verification across both the UI and services </li></ul></ul></ul><ul><ul><ul><li>Exercise messaging either emulated or live </li></ul></ul></ul><ul><ul><ul><li>Test object management and maintenance </li></ul></ul></ul><ul><ul><ul><li>Traceability from business processes to messages to applications </li></ul></ul></ul><ul><ul><ul><li>End-to-end execution across platforms, applications and layers </li></ul></ul></ul><ul><ul><ul><li>Detailed result logs, management reports and analysis </li></ul></ul></ul><ul><li>Certify’s approach has the potential to deliver dramatic productivity gains in automating and maintaining XML test cases. User of Certify means that custom code does not need to be developed. All test cases are developed in a repository using a standard, structured format. Test coverage can be quickly extended using data variations. </li></ul>
    50. 50. Certify’s operational process <ul><li>The first step is for the systems architect to configure the transport that will be used to send and receive XMl messages. While XMl is a standard, the implementation of the messaging layer is not. There are a number of transports and protocols, including both public and private APIs. </li></ul><ul><li>Next, the architect constructs a set of shared Certify processes that handle the sending and receiving of messages so that analysts can simply call them. This removes the need for analysts to understand the system infrastructure or transport protocol. </li></ul><ul><li>The next step is to import the schema or messages into the Certify application map, then rationalize the object names so they are useful and meaningful for test or business analysts. The message itself is presented to the user as a window, and each element within the message becomes an object. </li></ul>
    51. 51. Business Meaningful Element Names in All Messages
    52. 52. Perform Edit/Execute Command <ul><li>The message map provides users with a point and click editor for defining message data content to be sent or verified. As shown in Figure 4, the analyst selects the message, then the element within the message, then the action to be performed, such as to set or verify the value. Once the message contents are defined, the message can be generated and sent or received and verified. </li></ul>
    53. 53. Reference <ul><li>[1] Microsoft, “Service Oriented Architecture”, http:// msdn.microsoft.com/architecture/soa/default.aspx . </li></ul><ul><li>[2] Ptak, Noel & Associates, “Automated Testing: Preventing DOA for SOA”, http://www.worksoft.com/ContentDisplay/UploadDocs/Worksoft%20Preventing%20SOA%20DOArppdf.pdf . </li></ul><ul><li>[3] Systinet, “A Practical Guide to SOA for IT Management”. </li></ul><ul><li>[4] George Brown and Robert Carpenter, “Successful Application of Service-Oriented Architecture Across the Enterprise and Beyond”, </li></ul><ul><li>http://developer.intel.com/technology/itj/2004/volume08issue04/art09_successful/p01_abstract.htm . </li></ul><ul><li>[5] Nick Kushmerick, “Semantic Web: Vaporware or Worthy Dream?”, http://rakaposhi.eas.asu.edu/cse494/notes/semantic-web.ppt . </li></ul><ul><li>[6] Linda G. Hayes, “Testing SOA Could Test Your Nerves”, http:// itmanagement.earthweb.com /columns/quaquest/article.php/3416971 . </li></ul>

    ×