"Tomorrow's Needs, Yesterday's Technology" – DoD's ...

1,094 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,094
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • GOOD MORNING !! I’d like to talk about “Tomorrow’s Needs, Yesterday’s Technology” – DoD’s Architectural Dilemma and a plan for its resolution.
  • The talk out line is as follows
  • The DoD Network Centric transformation, poses new architectural requirements on DoD systems. Existing architectural approaches are insufficient to the task Extension of existing approaches is fundamentally incorrect since; it continues the patch on patch problem which increases complexity it makes existing complex systems even more difficult to understand and use New architectural approaches must; it lays primary focus on unique characteristics of network centricity and we need to be discriminating in deciding what to include in the approach we need to be critical if the goal is to achieve any measure of analyzability
  • Let’s take a look at several observations on DoD architectures……
  • DoD has started several architecture initiatives such as the DOD ARCHITECTURE FRAMEWORK To some degree the global information grid can be considered as an architecture initiative. DoD is also a heavy user of UML in specifying system behaviors in terms of sequence diagrams, class diagrams, use cases, collaboration diagrams and architecture; behavior diagrams interaction diagrams structure diagrams
  • These are excellent innovative architecture initiatives to ensure quality in requirements, specification, design, and implementation. UML provides a common vocabulary between different stakeholders. However, they are not sufficient for modern agile war fighting and leaves significant unmet needs What would be sufficient for modern agile war fighting? What significant unmet needs must be met?
  • Recent trends in Network-Centric Warfare (NCW) have significant effect on our technology and management: GIG-compliant including policy-driven computing Service-Oriented Architecture (SOA) Network Centric Enterprise Services (NCES), GIG-ES, JBMC2, FCS and Composable FORCEnet Dynamic publication, runtime selection and discovery, dynamic composition Distributed services and agents These systems must be dynamic systems and keep on changing even at runtime These architectures are not static but dynamic and evolving in other words, modern DoD systems need to respond to change at runtime and in real time Key question Are the existing approaches to architecture powerful enough to handle these dynamic structure and mechanisms, which are key to building systems for Network Centric Warfare?
  • We must have rapid and adaptive acquisition and deployment for NCW. We must have; Dynamic system architecture composed at runtime Dynamic system reconfiguration or re-composition at runtime even during warfighting Dynamic and real-time system interoperation between two systems not knowing each other before. The question; is existing technology adequately capable to address the NCW issues stated above??
  • This is a diagram for NCES. This shows that components can be dynamically changing. We should no longer have a static view of system architecture or components any more. Notice, the slide says nothing concerning legacy systems.
  • This is an example of SOA, and this slide shows that things are changing and are very dynamic, and we need a dynamic mechanism to handle these issues.
  • The service based computation model has 3 parties Involved: Service Providers - access to design and implementation as well as well as WSDL interface UDDI/ebXML – provides searching and updating Clients – customer may not access to design and implementation. May have access to WSDL only
  • Traditional SOA is as follows: Service Brokers (directory services and registry along with white, yellow, and green pages Application builders (development platforms, specification languages, composition, and code generation) Service Providers (computing service development and web and data service development
  • Instead of static composition with dynamic objects and dynamic binding in OO, SOA allows dynamic composition at runtime , having only knowledge of the service interfaces. This includes: D ynamic discovery and matching Runtime ranking and selection of services Runtime collaboration establishment Runtime interoperability verification
  • In case of system failure, SOA reconfiguration strategy is unique In OO, it is necessary to develop the reconfiguration strategy manually. In SOA, a faulty service can be easily replaced by another standby service by the DRS (Dynamic Reconfiguration Service), and the DRS also is a service that can be monitored and replaced. The key is that each service is independent of other services, and thus replacement is natural. Thus, SOA improves reliability of systems and systems of systems.
  • Dynamic SOA changes the entire lifecycle landscape from requirements, design, implementation, and test and evaluation. For example, during the requirements stage knowledge of existing services is critical because reusability will be the enabler.
  • Reusability will be a key consideration during the requirements phase. Searching and discovering services that can be reused will be key – this means that a broker or library will be needed Profile and ranking of these services will be a key consideration. From the very beginning, it is understood that the system services and architecture can be changed at any given time, even during runtime. The requirements phase is continuous and considers the evolution plan as new services may arrive after the system is deployed. Once the requirements are fully understood and specified, lots of code will be available immediately. This is similar to Extreme Programming or Agile processes rather than the Waterfall model. However, the difference here is, many services will be ready for reuse immediately after the requirements analysis.
  • Traditional ‘Shrink wrapped and shipped’ software has its own QA process, and integration with other software is either limited or impossible. Web services are different. It interacts with other software frequently and extensively, therefore, it is necessary to evaluate quality at runtime in real time. First, what are attributes of quality for web services? Trust Reliability – the service will not crash Performance – the service will return results rapidly Security – the service will not leak sensitive data to 3 rd parties and it will not return false, malicious information back to the client Safety – the service will not harm its users, mission and environment
  • Can we test across infra and inter-organizational web services in real time and at runtime? On Functional testing: Can we generate the test cases/scripts for inter-organization services? For Coverage analysis: What kind of coverage can we anticipate? What would be good enough? Test, evaluation and monitoring: how can we collect and evaluate test results including security and scalability test results? Can we develop reliability models for web services?
  • Here, we compare traditional IV&V to Service Oriented Collaborative V&V Instead of being conducted by an independent team, Service Oriented Collaborative V&V is collaboration among multiple parties Instead of testing coverage being traditionally structural and functional. In SOA it is specification and usage based.
  • SOA applications must assume the SOA, i.e., clients, brokers, and suppliers are linked by dynamic discovery and matching, and each service is an independent unit for computation and reuse. However, this is just the beginning.
  • Moving right along to Dynamic Architectures for Service oriented Applications.
  • A SOA based system has its own architecture. The system has three architectures : The Application Architecture . This application architecture will be built on top of an SOA. The Service Architecture . This is the commonly known SOA architecture. The Component Architecture . This is a sub-SOA architecture that describes the various elements that support the implementation of services.
  • This shows an example of a 5 layered application architecture, similar to the conventional enterprise architecture shown. Notice the two supporting mechanisms: 1) Integration Architecture 2) QoS, Security management and monitoring
  • Both diagrams depicted show only major components from the functionality point of view. Both are rather incomplete from the architecture point of view, and they can be improved.
  • SOA applications may be composed at runtime, thus the SOA application architecture may be formed at runtime, i.e., the application architecture can be dynamic. In case of system failures or overload, the SOA application may be dynamically changed at runtime, and this will result in dynamic re-composition and dynamic re-architecture. Another new SOA concept : Lifecycle Management (ownership) Can be Embedded in Operational Infrastructure
  • The diagram on the right shows 3 different applications (and 3 different architectures) using the same set of services on the left. The composition of these dynamic architecture is done at runtime. The building blocks are services. Services may be connected to a bus-like communication backbone such as an ESB (Enterprise Service Bus). The control center specifies and controls the application composition via a workflow specification, thus different applications with different architectures can be composed using the same set of services.
  • These slides show three different but related concepts. Dynamic architecture is the most complex while most SOA can support some form of dynamic composition.
  • The traditional fault-tolerant mechanism is done in a fixed architecture, it can replace a failed component however it cannot dynamically change the architecture of the application. In SOA, both are possible. The second difference is, the traditional approach has limited resources (replacements) due to the high cost of replication. A SOA environment has, potentially an unlimited number of replacements that can be available because new replacement services may arrive after deployment.
  • SOA merges the operational infrastructure with the developmental infrastructure to support dynamic composition (and dynamic re-composition and dynamic re-architecture) The development lifecycle tool need to be integrated with execution infrastructure
  • Plz look at the IBM SOA FOUNDATION ARCHITECTURE. IT HAS: Modeling : This stage will gather requirements and establish a model to represent the system. Assembling : In this stage, the designer can either create required services from scratch or find an existing service from a service broker to develop the application according to the model constructed in the previous stage. Deployment : In this stage, the runtime environment is configured to meet the application’s requirements, and the application is deployed into that environment for execution. Management : After the application is deployed, the services used in the application are provisioned and monitored for information needed to prevent, isolate, diagnose, and fix any problem that might occur at runtime. Governance and processes : The entire process will be controlled and orchestrated by policies
  • The diagram on the right shows an example architecture using Microsoft Visual Studio. Microsoft also takes this approach in their Whitehorse and Indigo projects, where they have capabilities for modeling, architecture, code generation, code deployment and code execution.
  • NOW, we take a look at SOA Classification, which has four factors: The structure of the application, either static or dynamic The runtime re-composition capability. If the architecture can support runtime re-composition, services in the applications using this type of architectures can be replaced by some other services to meet changed requirements or fix runtime failures. The fault-tolerance capability. This can be further decomposed into two sub-factors: fault-tolerant control center and/or fault-tolerant communication backbone. The system engineering support
  • SOA Architecture classification factor notations are as follows: Architecture element Possible value Notation Structure Static S Dynamic D Dynamic Re-composition Yes R No N Fault-tolerance Fault-tolerant communication backbone FB Fault-tolerant control services FC No FN System Engineering Support Policy checking enforcement Completeness and consistency checking SC Modeling checking SM Simulation SS Reliability assessment SR Code generation SG Data collection SD Service composition/re-composition SO No SOSE support SN Full SOSE support SY Partial SOSE support, i.e.
  • Here, we show the SOA Classification using a tuple. We have the following Structure : an application can have S (for static structure) or D (dynamic structure), but not both; Re-composition : an application can have R (for with dynamic re-composition capability) or N (for without dynamic re-composition capability), but not both; Fault-tolerance : an application can have FB (fault-tolerant communication backbone), FC (fault-tolerant control services), or FN (no fault-tolerance);
  • SOA Application Classification for System Engineering support can have any: SPC – policy checking; SC – completeness and consistency checking; SM – model checking; SS – simulation; SR – reliability assessment; SG – code generation; SD – data collection; SO – service composition/re-composition. If it has all the supports, it is denoted with SY. If it has none, it will de denoted as SN. If it has some of them, it will be denoted as SP.
  • As shown in the diagram, the root of the tree represents the most basic SOA architecture style. If we use the notation < to represent a containment relationship between two architectures: (D, R, FN, XX) < (D, R, FB, XX) < (D, R, FC, XX) < (D, R, FB/FC, XX)
  • This architecture (using the notation introduced) has a fault-tolerant communication backbone as well as a fault-tolerant control center. The communication backbone can be a computing platform, such as .NET, or ESB (Enterprise Service Bus). The control center may dynamically change the application architecture at runtime based on data collected.
  • We now postulate a new approach for software architecture. Software architecture research has traditionally focused on component interconnection, architecture styles, architecture specification, and architecture evaluation. They have not emphasized the dynamic aspect of architecture, in particular when the application architecture can be determined at runtime. The classification approach proposed is the first attempt to classify various architectural approaches for dynamic SOA architectures.
  • Next, we look at Dynamic Service Oriented System Engineering
  • A new System Engineering Approach is badly needed. As SOA applications be composed at runtime, the traditional system engineering will not be sufficient to address all the needs of SOA applications. We need dynamic Service-Oriented System Engineering (SOSE) Dynamic SOA reliability engineering Dynamic SOA security analysis Dynamic SOA safety analysis Dynamic SOA verification and validation Dynamic SOA system composition and re-composition
  • As part of the paradigm shift and moving away from the traditional documentation driven approach and colorful PowerPoint slides, dynamic system engineering is different. When a new application is being considered in a service-oriented environment, we need: Dynamic requirement specification by model composition Dynamic specification and model analysis (performance analysis, simulation, model checking, completeness and consistency checking, reliability analysis, security analysis) Dynamic design by composition and discovery Runtime code generation and composition Dynamic verification and validation Dynamic deployment, execution monitoring and assessment
  • SOSE (Service-Oriented System Engineering) is a key part of the new computing paradigm, it will change the entire landscape and could solve many existing chronic acquisition and maintenance problems .Constipation in the acquisitions pipeline could now get a possible laxative. Development Cycle time could be in minutes. Dynamic service-oriented requirement engineering (model-based, architecture-based, reuse-oriented, framework-oriented analysis, simulation-based analysis with formal analysis) Dynamic service-oriented architecture and design (enterprise computing, dynamic collaboration, system composition, dynamic system analysis) Service-oriented programming languages (model-based development, support automated code generation Dynamic service-oriented implementation (by dynamic discovery, composition, and model-based architecture, and automated code generation) Dynamic testing, verification, evaluation, simulation, reliability analysis of services Dynamic policy construction, verification, simulation, enforcement of security and other policies using formal policy languages Dynamic System maintenance and update will be via service re-composition and possibly architectural reconfiguration
  • This diagram is a comparison of the OO and SO paradigm. To be qualified as a paradigm, it is necessary to have concepts, programming languages, modeling techniques, and system engineering techniques. OO is a paradigm because it has concepts, OO programming languages, OO modeling techniques, and we have just OO system engineering techniques. If SO is a a new paradigm, then we are just at the beginning, we need SO programming languages, SO modeling, and SO system engineering. Note that numerous issues in SO have not been addressed at all, specifically we just began to address SOSE (service-oriented system engineering), SO maintenance, SO frameworks, SO databases, SO lifecycle. Even in OO, we still have some issues that we have not addressed adequately yet, e.g., OO system engineering. Note in SO system engineering, things are dynamic and concurrent, and at runtime. That makes SOSE very different from OO system engineering.
  • This is a complicated diagram to explain. Basically in the new SOA system engineering, modeling, code generation, analysis, testing, simulation are all integrated in a fully integrated process. Lots of analysis will be done at runtime. The key point is that there is a merger of development infrastructure and operational infrastructure, and these two infrastructures are connected at runtime via code deployment and data collection. This is drastically different from traditional OO programming where the development infrastructure is different from operational infrastructure, in SOA, they are the same infrastructure, and they talk to each other at runtime. This diagram also shows that SOSE embodies many different traditional system engineering tasks that were unrelated before, and also many of these technologies must be done at runtime instead of offline.
  • As DoD embraces SOA, it is important to recognize that SOA represents a new computing paradigm, and the new paradigm needs a new set of system engineering tools and techniques including architecture, specification, analysis, modeling, simulation, and evaluation. The core concept of SOA is dynamism including dynamic composition and deployment, and this dynamism requires a new approach of system engineering different from the traditional static documentation driven system engineering.
  • DoD has created several architecture initiatives such as the DOD ARCHITECTURE FRAMEWORK To some degree the global information grid can be considered as an architecture initiative. DoD is a heavy user of UML in specifying system behaviors in terms of sequence diagrams, class diagrams, use cases, collaboration diagrams and architecture, for: behavior diagrams interaction diagrams structure diagrams
  • These are excellent innovative architecture initiatives to ensure quality in requirements, specification, design, and implementation. UML provides a common vocabulary between different stakeholders. However, they are not sufficient for modern agile war fighting and leaves significant unmet needs
  • "Tomorrow's Needs, Yesterday's Technology" – DoD's ...

    1. 1. “ Tomorrow’s Needs, Yesterday’s Technology” – DoD’s Architectural Dilemma & Bold Initiatives 2007 Dr. Raymond A. Paul C2 Policy OASD NII [email_address]
    2. 2. Outline of Talk <ul><li>Key propositions in this talk </li></ul><ul><li>Observations on DoD architectures </li></ul><ul><li>Dynamic Service-oriented architecture (SOA) and its applications </li></ul><ul><li>Dynamic architecture for service-oriented Applications </li></ul><ul><li>Dynamic service-oriented system engineering </li></ul><ul><li>Conclusion </li></ul>
    3. 3. Key Propositions in this Talk <ul><li>Network Centricity poses fundamentally new architectural requirements on DoD systems </li></ul><ul><li>Existing architectural approaches (methods, tools) are not sufficient to the task, leaving some gaping holes </li></ul><ul><li>Extension of existing approaches is fundamentally incorrect, since </li></ul><ul><ul><li>it adds yet another ‘patch up’, and increases interoperability complexity, which is one of the key problems that needs to be addressed </li></ul></ul><ul><ul><li>makes existing complex systems more so, making it even more difficult to understand & use them </li></ul></ul><ul><li>Any new architectural approach must </li></ul><ul><ul><li>lay primary emphasis on unique characteristics of Network Centricity </li></ul></ul><ul><ul><li>be discriminating in deciding what to include in the approach; critical if the goal is to achieve any measure of analyzability </li></ul></ul>
    4. 4. Observations on DoD Architectures
    5. 5. Definition of SOA <ul><li>A Service-Oriented Architecture (SOA) is a system consisting of modular software components with standardized component-access and interfaces that are independent of any platform or implementation technology. An SOA is simply a collection of standardized services on a network that communicate with one another. </li></ul><ul><li>Web services does not equal SOA. Web services is a collection of technologies, including XML, SOAP, WSDL, and UDDI that allow service programming. </li></ul><ul><li>SOA is an application architecture within which all functions are defined as independent services with well-defined invokable interfaces. Note that: </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>
    6. 6. Advantages of SOA <ul><li>First, interoperability in SOA is priority one due to its system organization. If changes are needed, just replace one service with another, thus SOA-based systems are tolerant on changes and system can be easily reconfigured. </li></ul><ul><li>Second, SOA-based system is also agile, system development is in terms of system composition rather than code development. </li></ul><ul><li>SOA also changed the entire system development paradigm including system requirements, design, implementation, testing, operation and maintenance. </li></ul><ul><ul><li>For example, in system requirements, knowledge of existing services is equally important as understanding the problem. </li></ul></ul>
    7. 7. SOA Dynamic Discovery <ul><li>Dynamic discovery is an important part of SOA. An SOA is composed of three service providers, service consumers, and a 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>
    8. 8. 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>
    9. 9. 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>
    10. 10. DoD Architecture and UML <ul><li>DoD has started several architecture initiatives such as DODAF (numerous views such as OV) and in some degree GIG can be considered as an architecture initiative </li></ul><ul><li>DoD also is a heavy user of UML in specifying system behaviors (sequence diagrams, class diagrams, use cases, collaboration diagrams) and architecture </li></ul><ul><ul><li>Behavior diagrams </li></ul></ul><ul><ul><ul><li>A type of diagram that depicts behavioral features of a system or business process.  </li></ul></ul></ul><ul><ul><ul><li>This includes activity, state machine, and use case diagrams as well as the four interaction diagrams </li></ul></ul></ul><ul><ul><li>Interaction diagrams </li></ul></ul><ul><ul><ul><li>A subset of behavior diagrams which emphasize object interactions </li></ul></ul></ul><ul><ul><ul><li>This includes communication, interaction overview, sequence, and timing diagrams </li></ul></ul></ul><ul><ul><li>Structure diagrams </li></ul></ul><ul><ul><ul><li>A type of diagram that depicts the elements of a specification that are irrespective of time </li></ul></ul></ul><ul><ul><ul><li>This includes class, composite structure, component, deployment, object, and package diagrams </li></ul></ul></ul>
    11. 11. These are excellent, but … <ul><li>These architecture initiatives provide much innovation for DoD, help to ensure system quality in numerous aspects such as requirement specification, design, implementation, and testing. </li></ul><ul><li>As an universal and common language, UML provides a common vocabulary between different stake holders such as program managers (PMs), system engineers, QA, and system architect. </li></ul><ul><li>And yet </li></ul><ul><ul><li>They are not sufficient for modern agile warfighting, and </li></ul></ul><ul><ul><li>Leave significant unmet needs </li></ul></ul>
    12. 12. Observations <ul><li>Recent trends in Network-Centric Warfare (NCW) have significant effect on our technology and management: </li></ul><ul><ul><li>GIG-compliant including policy-driven computing </li></ul></ul><ul><ul><li>Service-Oriented Architecture (SOA) </li></ul></ul><ul><ul><ul><li>Network Centric Enterprise Services (NCES), GIG-ES, JBMC2, FCS and Composable FORCEnet </li></ul></ul></ul><ul><ul><ul><li>Dynamic publication, runtime selection and discovery, dynamic composition </li></ul></ul></ul><ul><ul><ul><li>Distributed services and agents </li></ul></ul></ul><ul><ul><li>These systems must be dynamic systems and keep on changing even at runtime </li></ul></ul><ul><li>These architectures are not static but dynamic and evolving </li></ul><ul><ul><li>in other words, modern DoD systems need to respond to change at runtime and in real time </li></ul></ul><ul><li>Key question </li></ul><ul><ul><li>Are the existing approaches to architecture powerful enough to handle these dynamic structure and mechanisms, which are key to building systems for Network Centric Warfare? </li></ul></ul>
    13. 13. Observations (continued) <ul><li>Rapid and adaptive acquisition and deployment for NCW </li></ul><ul><ul><li>Agile and adaptive acquisition (Income-Tax model for adaptive and incremental acquisition) </li></ul></ul><ul><ul><li>Agile warfighting with dynamic changing tactics </li></ul></ul><ul><ul><li>Dynamic system architecture composed at runtime </li></ul></ul><ul><ul><li>Dynamic system reconfiguration or re-composition at runtime even during warfighting </li></ul></ul><ul><ul><li>Rapid but reliable system engineering </li></ul></ul><ul><ul><li>High assurance for C2 applications </li></ul></ul><ul><ul><li>Dynamic and real-time system interoperability between two systems not knowing each other before </li></ul></ul><ul><li>Key question </li></ul><ul><ul><li>Is existing technology powerful enough to address the NCW issues identified above? </li></ul></ul>
    14. 14. Network Centric Enterprise Services(NCES) 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 C2 Intel Weapon Systems Dynamically Created COIs Logistics Sensors Personnel Finance Etc.
    15. 15. 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 COI’s Capability Integrator Installations & Environment Human Resources Management Acquisition Strategic Planning & Budget Logistics Accounting & Finance Governance 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
    16. 16. Dynamic SOA and its Applications
    17. 17. Service Computation Model <ul><li>Three parties are involved </li></ul><ul><ul><li>Service providers </li></ul></ul><ul><ul><ul><li>Have access to design and implementation, and the interface Web Service Definition Language (WSDL) </li></ul></ul></ul><ul><ul><ul><li>May themselves host services </li></ul></ul></ul><ul><ul><li>UDDI/ebXML </li></ul></ul><ul><ul><ul><li>Provide searching and updating capabilities </li></ul></ul></ul><ul><ul><ul><li>May have access to WSDL only </li></ul></ul></ul><ul><ul><li>Clients </li></ul></ul><ul><ul><ul><li>Customer, may not have access to design and implementation </li></ul></ul></ul><ul><ul><ul><li>May have access to WSDL only </li></ul></ul></ul>
    18. 18. Traditional SOA Architecture Diagram  Publishing ‚ Find ƒ Found Registry Service brokers Registry „ SOAP call … Results Internet Computing service development: .Net (Microsoft) WebSphere (IBM) Programming languages: C++, C# Java Application development platforms Specification languages .Net, WebSphere, WSFL, BPEL, PSML for composition, code generation Directory services UDDI / WSDL / SOAP ebXML / CPP Ontology Web and data service development XML, RDF, OWL, WSDL White page Yellow page Green page † ˆ ‡  Publishing ‚ Find ƒ Found Registry Service brokers Registry „ SOAP call … Results Service providers Service agents Service providers Service agents Application builder Applications Application builder Applications Internet Computing service development: .Net (Microsoft) WebSphere (IBM) Programming languages: C++, C# Java Application development platforms Specification languages .Net, WebSphere, WSFL, BPEL, PSML for composition, code generation Directory services UDDI / WSDL / SOAP ebXML / CPP Ontology Web and data service development XML, RDF, OWL, WSDL White page Yellow page Green page † ˆ ‡ Service providers Service agents Application builder Applications
    19. 19. Dynamic SOA – search & invocation <ul><li>Instead of static composition (with dynamic objects and dynamic binding) in the Object-Oriented (OO) approach, SOA allows dynamic composition at runtime , requiring knowledge of the service interfaces only. This includes, </li></ul><ul><ul><li>dynamic service discovery and matching </li></ul></ul><ul><ul><li>runtime ranking and selection of services </li></ul></ul><ul><ul><li>runtime collaboration establishment </li></ul></ul><ul><ul><li>runtime interoperability verification </li></ul></ul>
    20. 20. Dynamic SOA – failure resilience <ul><li>In case of system failure, the SOA reconfiguration strategy is unique </li></ul><ul><ul><li>In OO, it is necessary to develop the reconfiguration strategy manually </li></ul></ul><ul><ul><li>In SOA, a faulty service can be easily replaced by another standby service by the DRS (Dynamic Reconfiguration Service), and the DRS also is a service that can itself be monitored and replaced </li></ul></ul><ul><ul><ul><li>The key is that each service is independent of other services, and thus replacement is natural </li></ul></ul></ul><ul><ul><li>Only the affected services will be shut down and this allows the mission-critical application to proceed with minimum interruption </li></ul></ul><ul><li>Thus, SOA improves reliability of systems and systems of systems </li></ul>
    21. 21. SOA Dynamism Changes the Entire Lifecycle <ul><li>From requirements engineering to V&V, SOA and WS changes the landscape </li></ul><ul><li>In the requirements stage, knowledge of existing services is critical as reusability is often the key enabler </li></ul><ul><li>In the design stage, the loosely coupled service architecture allows dynamic composition, and dynamic re-composition </li></ul><ul><li>In the implementation phase, a majority of work will be composition (or linking) rather than code development as services will be reused </li></ul><ul><li>In the V&V phase, CV&V should be used rather than IV&V as the source code of many services may not be available </li></ul>
    22. 22. SOA Requirement Analysis <ul><li>Reusability will be a key consideration during the requirements phase </li></ul><ul><ul><li>Searching and discovering services that can be reused will be key – this means that a broker or library will be needed </li></ul></ul><ul><ul><li>Internet search technologies, e.g. Google, Yahoo!, etc. provide tools to help in this </li></ul></ul><ul><ul><li>Profile and ranking of these services will be a key consideration </li></ul></ul><ul><li>The system will assume an architecture from the very beginning, i.e., SOA </li></ul><ul><li>From the beginning, it is understood that the system components (services) and architecture can be changed at any given time, even during runtime </li></ul><ul><li>The requirements phase is continuous and considers the evolution plan as new services may arrive after the system is deployed </li></ul><ul><li>Once the requirements are fully understood and specified, lots of code will be available immediately </li></ul><ul><ul><li>this is similar to Extreme Programming or Agile processes rather than the Waterfall model </li></ul></ul><ul><ul><li>the difference here is, many services will be ready for reuse immediately after the requirements analysis. </li></ul></ul>
    23. 23. Evaluating Web services at Runtime <ul><li>Traditional ‘Shrink wrapped & shipped’ software has its own QA process, and integration with other software is either limited or impossible </li></ul><ul><li>A Web service is different </li></ul><ul><ul><li>it interacts with other software frequently and extensively </li></ul></ul><ul><ul><li>it is necessary to evaluate its quality at runtime in real time </li></ul></ul><ul><li>What are attributes of quality for web services? </li></ul><ul><ul><li>Trust </li></ul></ul><ul><ul><li>Reliability – the service will not crash </li></ul></ul><ul><ul><li>Performance – the service will return results rapidly </li></ul></ul><ul><ul><li>Security& Privacy – the service will not leak sensitive data to 3 rd parties and it will not return false, malicious information back to the client </li></ul></ul><ul><ul><li>Safety – the service will not harm its users, mission and environment </li></ul></ul><ul><li>Need Service Level Agreement (SLA) to ensure cooperation </li></ul>
    24. 24. Evaluate “Reliability” of Services at Runtime <ul><li>Can we test across inter-organizational web services in real time and at runtime? </li></ul><ul><ul><li>Functional testing: Can we generate the test cases/scripts for inter-organization services? </li></ul></ul><ul><ul><li>Coverage analysis: What kind of coverage can we anticipate? What would be good enough? </li></ul></ul><ul><ul><li>Test, evaluation and monitoring: how can we collect and evaluate test results including security and scalability test results? </li></ul></ul><ul><li>Can we develop reliability models for web services? </li></ul>
    25. 25. Collaborative V&V for SOA Dynamic certification based on history Static certification center Certification Dynamic profiling and group testing Input domain & Reliability growth models Reliability model Just-in-time dynamic model checking Based on source code or states Model checking Dynamic and distributed Static and centralized Profiling Specification& Usage based Structural & functional Testing coverage Dynamic reconfiguration & binding Static configuration & linking Integration On-line regression Off-line regression Regression On-line just-in-time testing Off-line field testing Approach Collaboration among multi-parties By independent team Definition Service-Oriented CV&V Traditional IV&V (OO)
    26. 26. SOA Application Design <ul><li>SOA applications must assume the SOA, i.e., clients, brokers, and suppliers linked by dynamic discovery and matching, and each service is an independent unit for computation and reuse </li></ul><ul><li>However, this is just the beginning </li></ul>
    27. 27. Dynamic Architecture for Service-Oriented Applications
    28. 28. SOA Applications Architecture <ul><li>SOA applications have their own architectures : </li></ul><ul><ul><li>The Application Architecture . The application architecture will be built on top of an SOA </li></ul></ul><ul><ul><li>The Service Architecture . This is the commonly known SOA architecture </li></ul></ul><ul><ul><li>The Component Architecture . This is the sub-SOA architecture that describes the various elements that support the implementation of services </li></ul></ul>
    29. 29. Layered SOA Application Architecture <ul><li>5 layers: </li></ul><ul><li>Presentation </li></ul><ul><li>Business Process Choreography </li></ul><ul><li>Services </li></ul><ul><li>Enterprise Components </li></ul><ul><li>Operational Systems </li></ul><ul><li>With 2 supporting mechanisms: </li></ul><ul><li>Integration Architecture </li></ul><ul><li>QoS, Security, Management & Monitoring </li></ul>A SOA application has its own architecture, such as a layered architecture similar to conventional enterprise architecture below.
    30. 30. NCES and GIG-ES <ul><li>Both diagrams show only major components from the functionality point of view. Both are rather incomplete from the architecture point of view, and they can be improved. </li></ul>
    31. 31. Dynamic SOA Application Architecture <ul><li>As SOA applications may be composed at runtime, thus the SOA application architecture may be formed at runtime, i.e., the application architecture can be dynamic. </li></ul><ul><li>In case of system failures or overload, the SOA application may be dynamically changed at runtime, and this will result in dynamic re-composition and dynamic re-architecture. </li></ul><ul><li>Another new concept for SOA: Lifecycle Management Embedded in Operation Infrastructure </li></ul>
    32. 32. Dynamic Architecture via Dynamic Composition (a) Configuration 1 (b) Configuration 2 (c) Configuration 3 In SOA, the building blocks are services. Services may be connected to a bus-like communication backbone such as an ESB (Enterprise Service Bus). The control center specifies and controls the application composition via a workflow specification, thus different applications with different architectures can be composed using the same set of services. Generic SOA application architecture
    33. 33. Dynamic Re-Composition / Re-Architecture <ul><li>Dynamic composition : occurs during the system modeling and assembling stages. SOA applications can use the same set of services to compose application architectures with different topologies </li></ul><ul><li>Dynamic re-composition : occurs after the target application has been deployed. SOA applications can change its architecture, including replacing services at runtime. This does not change the topology of the application </li></ul><ul><li>Dynamic re-architecture : this occurs after the target application has been deployed, SOA applications can change their architecture topology at runtime </li></ul>
    34. 34. Traditional redundancy fault tolerant vs. Dynamic Re-Composition <ul><li>Traditional fault-tolerance mechanisms are applicable in a fixed architecture </li></ul><ul><ul><li>they can replace a failed component but it cannot dynamically change the architecture of the application </li></ul></ul><ul><ul><li>in SOA, both are possible </li></ul></ul><ul><li>Another difference is that the traditional approach has limited resources (replacements) due to the high cost of replication </li></ul><ul><ul><li>in an SOA environment, potentially an unlimited number of replacements can be available because new replacement services may arrive after deployment </li></ul></ul>
    35. 35. Lifecycle Management Embedded in Operation Infrastructure <ul><li>A development infrastructure may include modeling, analysis, design, architecture, code generation, verification and validation. </li></ul><ul><li>An operation infrastructure may include: Code deployment, code execution, policy enforcement, monitoring, communication, and system reconfiguration. </li></ul>IBM SOA Foundation architecture The SOA lifecycle management can be embedded in the operation infrastructure to facilitate dynamic software composition. In this way, the SOA application development infrastructure and operation infrastructure can be merged together in a single and unified SOA infrastructure.
    36. 36. IBM SOA Foundation architecture <ul><li>Modeling : This stage will gather requirements and establish a model to represent the system </li></ul><ul><li>Assembling : In this stage, the designer can either create required services from scratch or find an existing service from a service broker to develop the application according to the model constructed in the previous stage </li></ul><ul><li>Deployment : In this stage, the runtime environment is configured to meet the application’s requirements, and the application is deployed into that environment for execution </li></ul><ul><li>Management : After the application is deployed, the services used in the application are provisioned and monitored for information needed to prevent, isolate, diagnose, and fix any problem that might occur at runtime </li></ul><ul><li>Governance and processes : The entire process will be controlled and orchestrated by policies. </li></ul>IBM SOA Foundation architecture
    37. 37. Microsoft Whitehorse SOA Designer Microsoft Whitehorse SOA Designer Microsoft also takes this approach in their Whitehorse and Indigo projects, where they have capabilities for modeling, architecture, code generation, code deployment and code execution.
    38. 38. SOA Architecture Classification (SOAC) <ul><li>The structure of the application, either static or dynamic </li></ul><ul><li>The runtime re-composition capability. If the architecture can support runtime re-composition, services in the applications using this type of architectures can be replaced by some other services to meet changed requirements or fix runtime failures </li></ul><ul><li>The fault-tolerance capability. This can be further decomposed into two sub-factors: fault-tolerant control center and/or fault-tolerant communication backbone </li></ul><ul><li>The system engineering support </li></ul>Based on four factors
    39. 39. SOA Architecture Classification (SOAC) Architecture classification factor notations SP Partial SOSE support, i.e. only a subset of {SP, SC, SM, SS, SR, SG, SD, SO} are supported SY Full SOSE support SN No SOSE support SO Service composition/re-composition SD Data collection SG Code generation SR Reliability assessment SS Simulation SM Modeling checking SC Completeness and consistency checking SPC Policy checking and enforcement System Engineering Support FN No FC Fault-tolerant control services FB Fault-tolerant communication backbone Fault-tolerance N No R Yes Dynamic Re-composition D Dynamic S Static Structure Notation Possible value Architecture element
    40. 40. SOA Architecture Classification using a tuple <ul><li>Structure : an application can have S (for static structure) or D (dynamic structure), but not both; </li></ul><ul><li>Re-composition : an application can have R (for with dynamic re-composition capability) or N (for without dynamic re-composition capability), but not both; </li></ul><ul><li>Fault-tolerance : an application can have FB (fault-tolerant communication backbone), FC (fault-tolerant control services), or FN (no fault-tolerance) </li></ul>Continue on next page…
    41. 41. SOA Application Architecture Classification <ul><li>System engineering support : an application can have any </li></ul><ul><ul><li>SPC – policy checking; </li></ul></ul><ul><ul><li>SC – completeness and consistency checking; </li></ul></ul><ul><ul><li>SM – model checking; </li></ul></ul><ul><ul><li>SS – simulation; </li></ul></ul><ul><ul><li>SR – reliability assessment; </li></ul></ul><ul><ul><li>SG – code generation; </li></ul></ul><ul><ul><li>SD – data collection; </li></ul></ul><ul><ul><li>SO – service composition/re-composition. </li></ul></ul><ul><li>If it has all the supports, it is denoted with SY </li></ul><ul><li>If it has none, it will de denoted as SN </li></ul><ul><li>If it has some of them, it will be denoted as SP </li></ul>
    42. 42. SOAC Roadmap As shown in the diagram, the root of the tree represents the most basic SOA architecture style. If we use the notation < to represent a containment relationship between two architectures: (D, R, FN, XX) < (D, R, FB, XX) < (D, R, FC, XX) < (D, R, FB/FC, XX)
    43. 43. (D, R, FB/FC, SN) Architecture This architecture has a fault-tolerant communication backbone as well as a fault-tolerant control center. The communication backbone can be a computing platform, such as .NET, or ESB (Enterprise Service Bus). The control center may dynamically change the application architecture at runtime based on data collected. (D, R, FB/FC, SN) Architecture
    44. 44. New Approach for Software Architecture <ul><li>Software architecture research has traditionally focused on component interconnection, architecture design styles, architecture specification, and architecture design evaluation </li></ul><ul><li>However they have not emphasized the dynamic aspect of architecture, particularly when the application architecture can be determined at runtime </li></ul><ul><li>The classification approach proposed is the first attempt to classify various architectural approaches for dynamic SOA architectures </li></ul>
    45. 45. Dynamic Service-Oriented System Engineering
    46. 46. A New System Engineering Approach is Needed <ul><li>As SOA applications will be composed at runtime, the traditional system engineering may not be sufficient to address all the needs of SOA applications. We need dynamic Service-Oriented System Engineering (SOSE) </li></ul><ul><ul><li>Dynamic SOA reliability engineering </li></ul></ul><ul><ul><li>Dynamic SOA security & privacy analysis </li></ul></ul><ul><ul><li>Dynamic SOA safety analysis </li></ul></ul><ul><ul><li>Dynamic SOA collaborative verification and validation </li></ul></ul><ul><ul><li>Dynamic SOA system composition and re-composition </li></ul></ul>
    47. 47. Dynamic System Engineering <ul><li>When a new application is being considered in a service-oriented environment, we need the following </li></ul><ul><ul><li>Dynamic requirement specification by model composition </li></ul></ul><ul><ul><li>Dynamic specification and model analysis (performance analysis, simulation, model checking, completeness and consistency checking, reliability analysis, security analysis) </li></ul></ul><ul><ul><li>Dynamic design by composition and discovery </li></ul></ul><ul><ul><li>Runtime code generation and composition </li></ul></ul><ul><ul><li>Dynamic verification and validation </li></ul></ul><ul><ul><li>Dynamic deployment, execution monitoring and assessment </li></ul></ul>
    48. 48. Service-Oriented System Engineering <ul><li>Dynamic service-oriented requirement engineering (model-based, architecture-based, reuse-oriented, framework-oriented analysis, simulation-based analysis with formal analysis) </li></ul><ul><li>Dynamic service-oriented architecture and design (enterprise computing, dynamic collaboration, system composition, dynamic system analysis) </li></ul><ul><li>Service-oriented programming languages (model-based development, support automated code generation </li></ul><ul><li>Dynamic service-oriented implementation (by dynamic discovery, composition, and model-based architecture, and automated code generation) </li></ul><ul><li>Dynamic testing, verification, evaluation, simulation, reliability analysis of services </li></ul><ul><li>Dynamic policy construction, verification, simulation, enforcement of security and other policies using formal policy languages </li></ul><ul><li>Dynamic System maintenance and update will be via service re-composition and possibly architectural reconfiguration </li></ul>
    49. 49. From Object-Oriented Paradigm to Service-Oriented Paradigm OO Languages OO Modeling Languages & IDE Object- Oriented Concept & Architecture Simula Smalltalk Objective C C++ Java UML CORBA MS .Net JDK GCC OO Technology & Framework OO system engineering (OOSE) OO testing OO maintenance OO application frameworks OO databases (OODB) OO lifecycle (XP? MDA?) SO Modeling Languages & IDE SO Standards XML UDDI ebXML WSDL SOAP OWL Service- Oriented Concept & Architecture BPEL WSFL XLANG MS. Net WebSphere SO Technology & Framework SO System Engineering (SOSE?) SO testing (WebStrar?) SO maintenance (re-composition?) SO frameworks (FERA? SOI?) SO databases (Ontology DB, SODB?) SO Lifecycle (MDA, [re-]composition)
    50. 50. Service-Oriented System Engineering
    51. 51. SOSE Summary <ul><li>As DoD embraces SOA, it is important to recognize that SOA represents a new computing paradigm, and the new paradigm needs a new set of system engineering tools and techniques including architecture, specification, analysis, modeling, simulation, and evaluation. </li></ul><ul><li>The core concept of SOA is dynamism including dynamic composition and deployment, and this dynamism requires a new approach of system engineering different from the traditional static documentation driven system engineering. </li></ul>
    52. 52. Overall Summary <ul><li>SOA - particularly SOC - has to be more adaptive </li></ul><ul><li>Services and processes grow with their application and human environments. SOA criteria have to change with the situation, circumstance, and the environment. These are dynamic characteristics. Therefore, SOA has to be dynamic and adaptive . </li></ul><ul><li>The new paradigm environment MUST be transdisciplinary, fast changing with rapid diversification and globalization. </li></ul><ul><li>Summary </li></ul>
    53. 53. Conclusion <ul><li>Service-oriented computing is making strides due to acceptance by government and major computer and software companies </li></ul><ul><li>However there are several experience issues we need to address </li></ul><ul><ul><li>SOA is related to a number of traditional areas such as business models, programming languages, model construction and verification, software architecture and design, software reusability, databases, ontology, autonomic computing, grid computing, and computer networks. </li></ul></ul><ul><ul><li>While most of these topics are covered in universities, they are often scattered into different colleges, we need a definitive and systemic TRANSDISCIPLINARY factory for SOA research, development and education. </li></ul></ul><ul><ul><li>Regarding SOA research, there is a great need to perform dynamic service-oriented system engineering such as service-oriented requirement engineering, service-oriented design, service-oriented model and verification, dynamic service verification and validation, dynamic service maintenance and re-composition, dynamic service security analysis, dynamic service reliability analysis, and dynamic service profiling and collaboration </li></ul></ul><ul><ul><li>Regarding to architecture, there is a shortage of both skilled people who have transdisciplinary knowledge for developing and applying SOA and software services in a variety of domains such as, process control, computing and communication infrastructure </li></ul></ul>
    54. 54. Conclusion (continued) <ul><li>SOA application architecture must be dynamic including dynamic composition, re-composition and re-architecture at runtime. The dynamic SOA application architecture needs a new approach for architecture specification, classification, and evaluation. </li></ul><ul><li>While the existing DoD architecture and system engineering may be able to handle the initial specification and design of SOA applications, it is necessary to focus on changes and dynamic composition (and re-composition), and these will change the existing DoD practice of SOA. Specifically, DoDAF should be updated to address the dynamic aspects of SOA application architecture, and it is necessary to develop dynamic SOSE (Service-Oriented System Engineering) techniques. </li></ul>
    55. 55. Thank you for your Attention! Ray (New System Engineering Paradigm Evangelist) Paul
    56. 56. Appendix
    57. 57. DoD Architecture and UML <ul><li>DoD started several architecture initiatives such as DODAF (numerous views such as OV) and in some degree GIG can be considered as an architecture initiative </li></ul><ul><li>DoD is a heavy user of UML in specifying system behaviors (sequence diagrams, class diagrams, use cases, collaboration diagrams) and architecture </li></ul><ul><ul><li>Behavior diagrams </li></ul></ul><ul><ul><ul><li>A type of diagram that depicts behavioral features of a system or business process.  </li></ul></ul></ul><ul><ul><ul><li>This includes activity, state machine, and use case diagrams as well as the four interaction diagrams </li></ul></ul></ul><ul><ul><li>Interaction diagrams </li></ul></ul><ul><ul><ul><li>A subset of behavior diagrams which emphasize object interactions </li></ul></ul></ul><ul><ul><ul><li>This includes communication, interaction overview, sequence, and timing diagrams </li></ul></ul></ul><ul><ul><li>Structure diagrams </li></ul></ul><ul><ul><ul><li>A type of diagram that depicts the elements of a specification that are irrespective of time </li></ul></ul></ul><ul><ul><ul><li>This includes class, composite structure, component, deployment, object, and package diagrams </li></ul></ul></ul>
    58. 58. These are excellent, however… <ul><li>These architecture initiatives provide some innovation for DoD, they help to ensure system quality in numerous aspects such as requirement specification, design, implementation, and testing. </li></ul><ul><li>As an universal and common language, UML provides a common vocabulary between different stake holders such as program managers (PMs), system engineers, QA, and system architect. </li></ul><ul><li>And yet </li></ul><ul><ul><li>They are not sufficient for modern 21 st century agile warfighting, and </li></ul></ul><ul><ul><li>Leave significant unmet needs </li></ul></ul>

    ×