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

1

“Tomorrow’s Needs, Yesterday’s Technology” – DoD’s Architectural

Dilemma & Bold Initiatives 2007

Dr. Raymond A. PaulC2 PolicyOASD NII

[email protected]

2

Outline of Talk

Key propositions in this talkObservations on DoD architecturesDynamic Service-oriented architecture

(SOA) and its applicationsDynamic architecture for service-oriented

Applications Dynamic service-oriented system

engineeringConclusion

3

Key Propositions in this Talk

Network Centricity poses fundamentally new architectural requirements on DoD systems

Existing architectural approaches (methods, tools) are not sufficient to the task, leaving some gaping holes

Extension of existing approaches is fundamentally incorrect, since it adds yet another ‘patch up’, and increases interoperability

complexity, which is one of the key problems that needs to be addressed

makes existing complex systems more so, making it even more difficult to understand & use them

Any new architectural approach must lay primary emphasis on unique characteristics of Network Centricity be discriminating in deciding what to include in the approach; critical

if the goal is to achieve any measure of analyzability

4

Observations on DoD Architectures

5

Definition of SOA

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.

Web services does not equal SOA. Web services is a collection of technologies, including XML, SOAP, WSDL, and UDDI that allow service programming.

SOA is an application architecture within which all functions are defined as independent services with well-defined invokable interfaces. Note that:

All functions are defined as services. All services are independent. In the most general sense, the interfaces are invokable;

6

Advantages of SOA 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.

Second, SOA-based system is also agile, system development is in terms of system composition rather than code development.

SOA also changed the entire system development paradigm including system requirements, design, implementation, testing, operation and maintenance. For example, in system requirements, knowledge of existing

services is equally important as understanding the problem.

7

SOA Dynamic Discovery

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:

Scalability of services; you can add services incrementally. Decouples consumers from providers. Allows for hot updates of services. Provides a look-up service for consumers. Allows consumers to choose between providers at runtime rather than hard-coding a

single provider.

8

A Typical Architecture for a Service-Oriented Application

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.

9

SOA Architectural Perspective

The following three SOA architectures need to be considered:

The Application Architecture. This is the business facing solution which consumes services from one or more providers and integrates them into the business processes.

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.

The Component Architecture. This describes the various environments supporting the implemented applications, the business objects and their implementations.

10

DoD Architecture and UML

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

DoD also is a heavy user of UML in specifying system behaviors (sequence diagrams, class diagrams, use cases, collaboration diagrams) and architecture Behavior diagrams

A type of diagram that depicts behavioral features of a system or business process.  This includes activity, state machine, and use case diagrams as well as the four

interaction diagrams Interaction diagrams

A subset of behavior diagrams which emphasize object interactions This includes communication, interaction overview, sequence, and timing diagrams

Structure diagrams A type of diagram that depicts the elements of a specification that are irrespective of

time This includes class, composite structure, component, deployment, object, and package

diagrams

11

These are excellent, but …

These architecture initiatives provide much innovation for DoD, help to ensure system quality in numerous aspects such as requirement specification, design, implementation, and testing.

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.

And yet They are not sufficient for modern agile warfighting, and Leave significant unmet needs

12

Observations

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?

13

Observations (continued)

Rapid and adaptive acquisition and deployment for NCW Agile and adaptive acquisition (Income-Tax model for adaptive and

incremental acquisition) Agile warfighting with dynamic changing tactics Dynamic system architecture composed at runtime Dynamic system reconfiguration or re-composition at runtime even

during warfighting Rapid but reliable system engineering High assurance for C2 applications Dynamic and real-time system interoperability between two systems

not knowing each other before Key question

Is existing technology powerful enough to address the NCW issues identified above?

14

Network Centric Enterprise Services(NCES)

CoreEnterpriseServices

(CES)

Comms

Backbone

Community-of-Interest

(COI) CapabilitiesUsers

MessagingESM

Discovery Collaboration

Mediation Security/IA

AppStorage

UserAsst

Levels of Services above

core level

Support real-time & near-real-time warrior needs and business usersSupport real-time & near-real-time warrior needs and business users

C2

Intel

Weapon Systems

Dynamically Created COIs

Logistics

Sensors

Personnel

Finance

Etc.

15

GIG Enterprise Services

SOADR Supports real-time & near-real-time warrior needsSOADR Supports real-time & near-real-time warrior needs

DoD (Title 10) IC (Title 50)

UsersUsers

Business Domains Warfighter Domains

Domain/ COI

Capabilities

ICOrg 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

Inst

alla

tion

s &

Env

iron

men

t

Hum

an

Res

ourc

es

Man

agem

ent

Acq

uisi

tion

Stra

tegi

c P

lann

ing

& B

udge

t

Log

isti

cs

Acc

ount

ing

& F

inan

ceGovernance

COI’s

Capability Integrator

Com

man

d &

C

ontr

ol

Bat

tles

pace

A

war

enes

s

For

ce A

pplic

atio

n

Pre

cisi

on L

ogis

tics

Pro

tect

ion

Governance

Net-Centric Enterprise Services (NCES)

ApplicationUser

AssistantStorage Messaging IA/Security

IA/SecurityESM

IA/SecurityESM

IA/SecurityESM

Discovery

IA/SecurityESM

Collaboration

IA/SecurityESM Enterprise

Service Management

(ESM)

Mediation

IA/SecurityESM

IA/SecurityESM

ESM

IA/Security

16

Dynamic SOA and its Applications

17

Service Computation Model Three parties are involved

Service providers Have access to design and implementation, and the

interface Web Service Definition Language (WSDL) May themselves host services

UDDI/ebXML Provide searching and updating capabilities May have access to WSDL only

Clients Customer, may not have access to design and

implementation May have access to WSDL only

18

Traditional SOA Architecture Diagram

Publishing‚

Find

ƒ

Found

Registry

Service brokers

Registry

„

SOAP call

…

Results

Service providers

Service agents

Application builder

Applications

Internet

Computing servicedevelopment:.Net (Microsoft)WebSphere (IBM)

Programminglanguages:C++, C#Java

Application development platformsSpecification languages .Net, WebSphere,

WSFL, BPEL, PSML for composition, code generation

Directory servicesUDDI / WSDL / SOAP

ebXML / CPPOntology

Web and data service developmentXML, 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 servicedevelopment:.Net (Microsoft)WebSphere (IBM)

Programminglanguages:C++, C#Java

Application development platformsSpecification languages .Net, WebSphere,

WSFL, BPEL, PSML for composition, code generation

Directory servicesUDDI / WSDL / SOAP

ebXML / CPPOntology

Web and data service developmentXML, RDF, OWL, WSDL

White page

Yellow page

Green page

†

ˆ

‡

19

Dynamic SOA – search & invocation

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, dynamic service discovery and matching runtime ranking and selection of services runtime collaboration establishment runtime interoperability verification

20

Dynamic SOA – failure resilience In case of system failure, the 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 itself be monitored and replaced

The key is that each service is independent of other services, and thus replacement is natural

Only the affected services will be shut down and this allows the mission-critical application to proceed with minimum interruption

Thus, SOA improves reliability of systems and systems of systems

21

SOA Dynamism Changes the Entire Lifecycle From requirements engineering to V&V, SOA and WS

changes the landscape In the requirements stage, knowledge of existing

services is critical as reusability is often the key enabler In the design stage, the loosely coupled service

architecture allows dynamic composition, and dynamic re-composition

In the implementation phase, a majority of work will be composition (or linking) rather than code development as services will be reused

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

22

SOA Requirement Analysis 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

Internet search technologies, e.g. Google, Yahoo!, etc. provide tools to help in this

Profile and ranking of these services will be a key consideration The system will assume an architecture from the very beginning, i.e.,

SOA From the beginning, it is understood that the system components

(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 the difference here is, many services will be ready for reuse immediately

after the requirements analysis.

23

Evaluating Web services at Runtime Traditional ‘Shrink wrapped & shipped’ software has its own QA

process, and integration with other software is either limited or impossible

A Web service is different it interacts with other software frequently and extensively it is necessary to evaluate its quality at runtime in real time

What are attributes of quality for web services? Trust Reliability – the service will not crash Performance – the service will return results rapidly Security& Privacy – the service will not leak sensitive data to 3rd

parties and it will not return false, malicious information back to the client

Safety – the service will not harm its users, mission and environment Need Service Level Agreement (SLA) to ensure cooperation

24

Evaluate “Reliability” of Services at Runtime

Can we test across inter-organizational web services in real time and at runtime? Functional testing: Can we generate the test

cases/scripts for inter-organization services? 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?

25

Collaborative V&V for SOA

Traditional IV&V (OO)

Service-Oriented CV&V

Definition By independent team Collaboration among multi-parties

Approach Off-line field testing On-line just-in-time testing

Regression Off-line regression On-line regression

Integration Static configuration & linking

Dynamic reconfiguration & binding

Testing coverage

Structural & functional Specification& Usage based

Profiling Static and centralized Dynamic and distributed

Model checking

Based on source code or states

Just-in-time dynamic model checking

Reliability model

Input domain & Reliability growth models

Dynamic profiling and group testing

Certification Static certification center Dynamic certification based on history

26

SOA Application Design

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

However, this is just the beginning

27

Dynamic Architecture for Service-Oriented Applications

28

SOA Applications Architecture

SOA applications have their own architectures: The Application Architecture. The 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 the sub-

SOA architecture that describes the various elements that support the implementation of services

29

Layered SOA Application Architecture

Presentation: Portlets & WSRP

Business Process Choreography

Services (Composite Services)

Enterprise Components

Operational Systems

Integration Architecture

QoS

, Security, M

anagement,

& M

onitoring

5 layers:

• Presentation

• Business Process Choreography

• Services

• Enterprise Components

• Operational Systems

With 2 supporting mechanisms:• Integration Architecture • QoS, Security, Management & Monitoring

A SOA application has its own architecture, such as a layered architecture similar to conventional enterprise architecture below.

30

NCES and GIG-ES

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.

31

Dynamic SOA Application Architecture

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.

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 concept for SOA: Lifecycle Management Embedded in Operation Infrastructure

32

Dynamic Architecture via Dynamic Composition

Control CenterCommunication Backbone

Service 1 Service 2 Service 3

Service 4 Service 5 Service N... ...

Service 1

Service 3

Service 4

Service 2

Service 1

Service 3 Service 4Service 2

Service 1 Service 3 Service 4Service 2

(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

Dynamic Re-Composition / Re-Architecture

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

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

Dynamic re-architecture: this occurs after the target application has been deployed, SOA applications can change their architecture topology at runtime

34

Traditional redundancy fault tolerant vs. Dynamic Re-Composition

Traditional fault-tolerance mechanisms are applicable in a fixed architecture

they can replace a failed component but it cannot dynamically change the architecture of the application

in SOA, both are possible Another difference is that the traditional

approach has limited resources (replacements) due to the high cost of replication

in an SOA environment, potentially an unlimited number of replacements can be available because new replacement services may arrive after deployment

35

Lifecycle Management Embedded in Operation Infrastructure

A development infrastructure may include modeling, analysis, design, architecture, code generation, verification and validation.

An operation infrastructure may include: Code deployment, code execution, policy enforcement, monitoring, communication, and system reconfiguration.

Assembling Assembling

Modeling

Deployment

Management

Governance and

Processes

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

IBM SOA Foundation architecture

Assembling Assembling

Modeling

Deployment

Management

Governance and

Processes

IBM SOA Foundation architecture

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.

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

SOA Architecture Classification (SOAC)

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

Based on four factors

39

SOA Architecture Classification (SOAC)

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 and enforcement SPC

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. only a subset of {SP, SC, SM, SS, SR, SG, SD, SO} are supported

SP

Architecture classification factor notations

40

SOA Architecture Classification using a tuple

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)

Continue on next page…

41

SOA Application Architecture Classification

System engineering support: an application 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

42

SOAC Roadmap

(S, N, FN, SN)

(D, N, FN, SN)

(D, R, XX, XX)

(D, R, FN, XX) (D, R, FB, XX) (D, R, FC, XX) (D, R, FB/FC, XX)

(D, R, FN, SN)

(D, R, FN, SP)

(D, R, FN, SY)

(D, R, FB, SN)

(D, R, FB, SP)

(D, R, FB, SY)

(D, R, FC, SN)

(D, R, FC, SP)

(D, R, FC, SY)

(D, R, FB/FC, SN)

(D, R, FB/FC, SP)

(D, R, FB/FC, SY)

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

(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

Fault-Tolerant Communication Backbone

Service 1 Service 2 Service 3

Service 4 Service 5 Service NDynamic (Re-)Composition

Manager

Dynamic Workflow Specification

Data Collection

AnalysisFault-tolerant

Control Center

44

New Approach for Software Architecture

Software architecture research has traditionally focused on component interconnection, architecture design styles, architecture specification, and architecture design evaluation

However they have not emphasized the dynamic aspect of architecture, particularly 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

45

Dynamic Service-Oriented System Engineering

46

A New System Engineering Approach is Needed 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) Dynamic SOA reliability engineering Dynamic SOA security & privacy analysis Dynamic SOA safety analysis Dynamic SOA collaborative verification and validation Dynamic SOA system composition and re-composition

47

Dynamic System Engineering When a new application is being considered in a service-

oriented environment, we need the following 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

48

Service-Oriented System Engineering

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

49

From Object-Oriented Paradigm toService-Oriented Paradigm

OO Languages

OO ModelingLanguages &IDE

Object-OrientedConcept

& Architecture

SimulaSmalltalk

Objective C C++Java

UMLCORBA

MS .NetJDKGCC

OO Technology & Framework

OO system engineering (OOSE)OO testing

OO maintenanceOO application frameworks

OO databases (OODB)OO lifecycle (XP? MDA?)

SO ModelingLanguages & IDESO Standards

XMLUDDI ebXMLWSDLSOAPOWL

Service-OrientedConcept

& Architecture

BPELWSFL

XLANG

MS. NetWebSphere

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

Service-Oriented System Engineering

DSCA forReasoning

and Control

Policyenforcement

Testing

Deployment

Reliabilitymodeling

C&C

Modelchecking

Simulation

Application

Data collectionData mining

DSCA forReasoning

and Control

Policyenforcement

Testing

Deployment

Reliabilitymodeling

C&C

Modelchecking

Simulation

Application

Data collectionData mining

51

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

52

Overall Summary

SOA - particularly SOC - has to be more adaptive

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.

The new paradigm environment MUST be transdisciplinary,

fast changing with rapid diversification and globalization.

•Summary

53

Conclusion Service-oriented computing is making strides due to acceptance by

government and major computer and software companies However there are several experience issues we need to address

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.

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.

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

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

54

Conclusion (continued)

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.

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.

55

Thank you for your Attention!

Ray (New System Engineering Paradigm Evangelist) Paul

56

Appendix

57

DoD Architecture and UML 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 DoD is a heavy user of UML in specifying system behaviors (sequence diagrams, class

diagrams, use cases, collaboration diagrams) and architecture Behavior diagrams

A type of diagram that depicts behavioral features of a system or business process. 

This includes activity, state machine, and use case diagrams as well as the four interaction diagrams

Interaction diagrams A subset of behavior diagrams which emphasize object interactions This includes communication, interaction overview, sequence, and timing

diagrams Structure diagrams

A type of diagram that depicts the elements of a specification that are irrespective of time

This includes class, composite structure, component, deployment, object, and package diagrams

58

These are excellent, however… 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.

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.

And yet They are not sufficient for modern 21st century agile warfighting,

and Leave significant unmet needs