You are on page 1of 9

An Event-Driven Service Oriented Architecture for Space Command and Control Decision Making

Eric D. Yuan Michelle Watton Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 (703) 377-1787 (310) 297-5435 Yuan_eric@bah.com Watton_michelle@bah.com

AbstractMany sophisticated technologies and solutions exist or are being developed to address topics such as sensor data modeling, data fusion, and threat processing. To make an operational impact, however, these technologies and solutions must be linked to the relevant data sources and tailored to the operator needs in the Space Command and Control and Space Situational Awareness mission areas. Therefore we propose a holistic, mission-driven approach for data integration, with three key tenets to address industry challenges:

1. INTRODUCTION
Warfighters supporting the Command and Control (C2) and Space Situational Awareness (SSA) missions today, across the DoD and the Intelligence Community, are facing a daunting data challenge that is often described as swimming in sensors, drowning in data. For the space warfighter, this challenge is even more overwhelming due to the time-sensitive nature of space control missions and the high stake of space security. Specifically, the data challenge is manifested in the following aspects in the space control domain: Lack of data exposure and access. Being able to discover and share data is a prerequisite to C2 SSA missions. Even though the space community has made progress towards Net-Centricity, stove-piped sensor networks and data sources still dominate in the as-is environment and lack of timely data access (especially across mission enclave boundaries) through open standards-based interfaces remains a big obstacle. Further, proprietary data formats, access control constraints and releaseabilty constraints are also major data access barriers. Lack of cross-mission area information exchange and sharing. Another contributing factor to the stove-piped sensor networks and data sources in the as-is environment is the segregated mission areas at both organizational and system levels. Specifically, sensor assets and analysis are not shared across Space Control, Missile Warning, Missile Defense, and other space mission areas, resulting in lack of situational awareness and redundant capabilities. The same is true for data sharing across warfighting domains. For example, space control missions are increasingly affected by the operating conditions of IP-based data networks and cyber threats and attacks will have significant impacts to space mission success (as described in our example mission scenario in Section 4). Lack of data integration and analytics. More often than not, give me all data will not be enough to support Space C2 decision making. Without robust assistance to operators on integrating and fusing disparate data sources and connecting the dots across seemingly unrelated events, the operators will simply drown in data and be left without actionable information. Merely

Net-Centric data exposure and access through welldefined SOA web service interfaces Push-pull data integration based on an EventDriven Architecture Augmented data understanding through missiondriven capability analysis

The centerpiece of the framework is an Event-Driven Data Integration Environment (EDDIE) that serves as a broker between mission-specific data needs and various data providers. Leveraging the emerging Event-Driven Architecture (EDA) and Complex Event Processing (CEP) technologies, this layer provides a combination of on-demand pull of relevant information by an end user and the event-driven push of time-sensitive information to support decision making. Architecturally, this loosely-coupled framework is based on Net-Centric tenets and industry/DoD standards, allowing new tools and data sources to be ingested and evolve over time. The results of the event driven architecture framework enable the required C2 performance thresholds and objectives as well as a ' repeatable integration structure.

TABLE OF CONTENTS 1. INTRODUCTION .............................................................1 2. SERVICE ORIENTED AND EVENT DRIVEN ARCHITECTURES ..................................................................2 3. PROPOSED ARCHITECTURE..........................................3 4. MISSION SCENARIO......................................................5 5. IMPLEMENTATION .......................................................6 6. RELATED WORK ..........................................................6 7. CONCLUSION ................................................................7 REFERENCES ........................................................................8 BIOGRAPHY ..........................................................................9

'

978-1-4577-0557-1/12/$26.00 2012 IEEE

putting data on the network without intelligent processing and abstraction will also exacerbate the already limited communication bandwidths. Lack of data understanding under mission contexts. Though perhaps not as apparent, the lack of understanding in space C2SSA missions is yet another factor that contributes to the data overload problem. Indepth understanding of operational activities and processes, and the ability to express it through Space C2 systems, will make data retrieval and processing become targeted and efficient, eliminating the need to transport large amounts of data over the network. Furthermore, incorporating mission context into the system solutions will also make the latter smarter and more responsive to new threats and changing missions.

dynamically deploy query modules, configurable clustering and failover clusters, client connectivity to output streams, graphical consoles and support for SNMP management framework [13, 14]. For the first tier of simple event processing, custom coding may be the best cost/benefit implementation while the remaining tiers are best handled by a CEP engine. The design of CEP solutions starts with mission-specific business modeling. Existing high level business modeling within SOA is the Business Process Model (BPM) offered by Oracle and IBM among others, however CEP goes beyond BPM to define principles for designing, monitoring and managing event processing systems [12]. Designing your CEP system starts with identifying event patterns or persistent goals meeting mission needs. This upfront engineering is critical to the success of your CEP system because it is the foundation for event identification and processing. Engineering ensures mission applicable results in addition to algorithm rules being accurate. After the upfront engineering has been performed, more detailed rules and goals are applied to the CEP engine. We are leveraging CEP techniques with SOA principles to develop a modular architecture solving problems in the Command and Control C2 Space Situational Awareness (SSA) mission areas. The rest of this paper is organized as follows. Section 2 provides an overview of the Service Oriented and Event Driven Architectures. Section 3 introduces our proposed architecture. Section 4 introduces a realistic Mission Scenario which provides the operational context of how our architectural approach may be applied. Section 5 proceeds to provide the implementation details of the architecture. Section 6 describes related research work. Section 7 concludes the paper with reviewing the benefits of SOA and CEP as well as future research opportunities.

Left unaddressed, these challenges will severely impact the space warfighters ability to gain accurate SSA and execute timely and informed Space C2 decisions. Our paper proposes a multi-tiered Space C2SSA framework that combines Service Oriented Architecture (SOA) principles with Complex Event Processing (CEP) technologies in a holistic framework. SOA and CEP are viewed as complimentary technologies in the research and operational community [12, 21]. SOAs fundamental principles ensure modularity and remote access while CEP processes the data being accessed through the SOA [6,12]. To provide some background on the CEP market, CEP technology has been leveraged by Wall Street, internet alerting, DoD complex processing, manufacturing and within research communities for simulation, performance monitoring and cyber-physical systems [1, 5, 7, 8, 10, 15, 16, 17, 18, 22, 23, 24]. A key value-add of our solution is the CEP implementation into the SOA framework. We found CEP engines best described in [13, 14] which describes applications in the real-time financial market, financial trade, IT security event correlation, asset management and tracking as well as manufacturing process, power grid or energy pipeline monitoring. [13, 14] identify key components of CEP engines such as stream management, memory management, parallel execution and synchronization, windows and indexing. CEP engines commonly have four tiers including; Tier One: simple event processing applications Tier Two: event processing applications involving multiple streams and/or stored data, Tier Three: complex analysis and pattern matching across event streams, and Tier Four: multiple, enterprise-class event processing applications.

2. SERVICE ORIENTED AND EVENT DRIVEN ARCHITECTURES


SOA as an architecture style has been widely adopted in engineering large and complex systems or System of Systems (SoS) in commercial and public sectors alike. Under a SOA, a set of network-accessible operations and associated resources are abstracted as a service. The service is described in a standard fashion, published to a service registry, and then discovered and accessed by a service consumer. In line with this technological paradigm shift, recent Department of Defense (DoD) efforts in organizational and doctrinal transformation have highlighted the need for a SOA-based Net-Centric approach. Because of its decentralized, loosely coupled, and highly interoperable nature, SOA will be a key technology enabler for NetCentricity. In mission-critical systems such as military weapon systems or satellite control systems, SOA adoption has been rather 2

Tier four, multiple enterprise-class event processing applications, is the most complex and allows the ability to

limited, in part due to factors such as the added performance overhead of XML processing (making it ill-fitted for realtime and embedded systems), network latencies, and the challenges in testing loosely-coupled component-based architectures. In recent years, however, defense and intelligence system development programs have increasingly embraced SOA tenets, principles and technologies, seeking to reap the promised benefits such as: Reduced overall system complexity when a mission capability is realized using a set of loosely coupled services with standards based, platform-independent interfaces (analogous to Lego pieces in many respects) Adaptability and survivability the ability to rapidly reconfigure and adapt system capabilities through service composition and orchestration, in response to ever-changing mission needs Potential cost savings through service reuse, including taking advantage of services provided by the larger enterprise (e.g., the DoD Global Information Grid (GIG) enterprise services) Expedited development lifecycle through the use of mature Commercial Off the Shelf (COTS) SOA solutions.

SOA follow a request-response mode, where a service consumer usually binds with a service provider before the interaction begins. By contrast, in an EDA the events are distributed in a publish-subscribe fashion where an event publisher often doesnt have a priori knowledge of who the event recipients are. The event routing / distribution is usually enabled by a Message Oriented Middleware (MOM).

Figure 1 Service-Based vs. Event-Driven Paradigms It is obvious that SOA and EDA are complimentary architecture styles and, when combined, can be synergistic and powerful, as will be elaborated in the next section.

Indeed, as todays mission systems become increasingly software-intensive, the net-centric SOA approach is fast becoming the de facto way of architecting and acquiring large warfighting capabilities [25]. In conjunction with service-orientation, event processing has become another major software architecture issue. Event processing can be viewed from two perspectives: From the architectural perspective, Event Driven Architecture (EDA) is recognized as a distinctive architecture style, which is centered around a push based, asynchronous communications model. Just like SOA, EDA also promotes loose coupling of software components, that is, decoupling of events from event sources and processors, thereby promoting agility and adaptability. From the operational perspective, mission needs have dictated the supporting system capabilities be able to sense and respond rapidly and effectively act upon changing conditions in the operating environment. Oftentimes this is achieved through CEP techniques as introduced in Section 1. Whether its business activity monitoring in the private sector or intelligence and surveillance in the military, CEP has been recognized as a strategy technology that brings competitive advantage.

3. PROPOSED ARCHITECTURE
Our proposed C2SSA Reference Architecture using the SOA and CEP approaches is illustrated in Figure 2. The centerpiece of the framework is an Event-Driven Data Integration Environment (EDDIE) that serves as a broker between mission-specific data needs and various data providers. Leveraging the emerging Event-Driven Architecture (EDA) and CEP technologies, this layer provides a combination of on-demand pull of relevant information by an end user and the event-driven push of time-sensitive information to support decision making. Architecturally, this loosely-coupled framework is based on Net-Centric tenets and industry/DoD standards, allowing new tools and data sources to be ingested and evolve over time.

The different information exchange paradigms between SOA and EDA may be explained using a simple illustration in Figure 1. Most information exchanges that occur in a 3

EDDIE serves as a broker between mission-specific data needs and various data providers. Figure 3 depicts the internal architecture inside the EDDIE layer, where events are elevated to a first-class citizen of the architecture with complete lifecycle management, routing, and processing. Event processing involves progressive steps such as understanding (e.g. identification, classification, and characterization), processing (e.g. geospatial processing or fusion), and effects (such as development of corrective actions). The results of event processing could include alerts and reports that are to be routed to human users, or new composite events that will be routed back to the CEP through their own lifecycle.

Figure 2 Proposed Reference Architecture On the left side of the above proposed architecture is the mission-driven capability analysis. This type of capability driven engineering identifies the event patterns and mission goals the system is trying to deduce or detect. This process, often called Mission Engineering, may involve operator interviews and working groups for identifying discrete capabilities and activities that comprise mission goals. Information exchange transactions, mission threads and asis system automation targets are also indentified and inventoried to help develop system capability and SOA roadmaps. On the right side of the diagram, we indicate the SOA infrastructure stack as the underlying plumbing substrate which may consist of security, messaging, discovery, Service management and monitoring, service orchestration and data management. The mission capabilities identified during engineering are implemented by the SOA Infrastructure stack. Then we get into the mission-specific data area. The data providers represented at the bottom of the proposed architecture represents one-to-many data streams providing mission information to the system. The Data Abstraction Layer mediates information transported using different data models and formats. The abstraction layer ensures the output of information to the next layer has a consistent and repeatable format. This enables the EDA layer to efficiently process and understand information. For the C2SSA mission areas, a combination of structured logic-based, datadriven and offline event monitoring is needed. Monitoring includes one-to-many data streams as well as offline query monitoring in the EDDIE. Logic-based event processing deduces the event pattern or mission goal while data-driven processing detects an event pattern or goal [2]. The CEP engine uses temporal, logical and spatial operations to process the incoming events from one-to-many data streams. 4

Figure 3 CEP Logical Architecture The mission services layer is built upon the data abstraction and event processing layers. This is where the missiondriven capability analysis is fully leveraged to engineer and design mission specific services. All of the previous layers are supporting the purpose of the system, being the mission. Leveraging standards such as Business Process Execution Language (BPEL0 and Business Process Modeling Notation (BPMN), repeatable mission processes and operator checklists can often be automated by web service orchestrations and choreographies, relieving operators or analysts from the tedious tasks of re-entering data from one application to another, so that they can focus on the mission itself. Last but by no means the least, the User-Defined Operating Picture (UDOP) layer works hand-in-hand with the mission services in providing users a smooth and integrated work space, tailored to the mission context and user preferences. This is the last mile of the overall architecture and the user experience often makes or breaks the effectiveness of the overall system. Rich Internet Applications (RIA) frameworks, in which users can select and activate specific mission applications through an app store-like interface much like mobile smart phone users do on iOS or Android phones today fits nicely with the componentbased SOA platforms and will become the norm of nextgeneration UDOP.

This type of layered, component-based architectural approach satisfies Modular Open System Architecture (MOSA) standards and ultimately ensures easier maintainability and extensibility as technologies upgrade and increase in size. The resulting solutions will naturally satisfy net-centric design principles as well as solves the data overload problem in the C2SSA mission area.

The primary event foundation analysis algorithm uses assessment if the event is initiated or terminated. This is done by Initiates (a, f, t) and Terminates (a, f, t). a represents the action, f represents the fluent or property that the event created, t represents time. For our mission scenario, below are details on specific mission events that are computed by the CEP engine. GIG Router Event: The GIG router exception at a particular location on the network (a), decreases the cyber network mission assurance with a value impact of 4.3 (f), at time 0330 on Oct 13th, 2011 (t) and therefore this event is initiated. Intel Report Event: The Intel Report of an advisory satellite is emitting active energy overhead of a SATCOM satellite (a), increases the probability of SATCOM Commanding being intercepted or interrupted with a value of 4.6 (f), at time 1700 on October 14th, 2011 (t) and therefore this event is initiated. Intel Report Event: The Intel Report of a probable future cyber attack in a particular location (a), increases the probability of cyber network attack with a value of 3.5 (f), at time 1700 on October 13th, 2011 (t) and therefore this event is initiated. Air Force Satellite Control Network (AFSCN) Phased Array Event: The AFSCN Phased Array channels became non-operational (a), increasing the probability of not being able to receive SATCOM state of health (SOH) telemetry with a value of 4 (f), at time 1900 on October 14th, 2011 (t) and therefore this event is initiated. AFSCN Phased Array Event: The AFSCN Phased Array channels became non-operational (a), increasing the probability of not receiving launch telemetry in support of the Space Launch with a value of 5 (f), at time 1900 on October 14th, 2011 (t) and therefore this event is initiated.

4. MISSION SCENARIO
In the mission scenario, we will be describing foundational CEP event concepts and how the SOA and CEP combination can be used to assess mission impact to the space situational awareness (SSA) mission areas including cyber network awareness, SATCOM commanding, High Accuracy Catalog (HAC) space surveillance and space launch. The course of action (COA) analysis for each of these mission areas is directly impacted by CEP results and the relationship of events to mission assurance. In Figure 4 we outline the relationship of events to mission areas of Cyber Networks, SATCOM Commanding, High Accuracy Catalog (HAC) space surveillance and Space Launch. These events are modeled as part of a business model to assess the mission impact of each event determining the right course of action (COA).

Figure 4 Event Relationships to Mission Areas Figure 4 describes the events on the right hand side represented by different colored plot lines and the value of impact to mission assurance per the selected mission areas. The business process evaluation starts to identify event impacts and understand the relationship of events to mission assurance. The additional information a CEP architecture needs in addition to the event relationship to the mission area is the timeframe reference and event logic. Event logic is based on event calculus which is a logical language for representing reasoning of cause and effect. CEP concepts use a basis of event calculus as the foundation, then combine event calculus logic to drive the CEP engine [9]. Event calculus is rooted in reasoning logic such as abductive analysis concepts. Lets review event calculus foundations.

By using these mission scenarios and event impacts, it is clear that one event can impact multiple mission areas for different reasons. It also starts to identify events that seem unrelated may in fact be a larger complex event for a greater situational awareness purpose. Additional calculations if the action is occurring now (initiated), representing it happened in the past (terminated), or if the event has been proven false after the initial initiation state (clipped) is important for the foundations of the CEP engine. The next layer of the CEP calculations determines if the event or postulate is affecting a domain (domain dependent). The domain dependency determination, even if remote, over time with multiple occurrences may in fact impact mission assurance more than originally understood. The domain dependency calculation uses event calculus such as [9];

Initiates (Launch, TelemetryNotAvailable, t ) HoldsAt (GIGRouter345 Exception, t )


The equation is determining if the event (e.g., GIG Router exception) is initiating, terminating, or holding based on the data received. The logic of understanding if an event is occurring and how that event impacts a domains mission assurance is the basis of CEP. We are representing one example of CEP logic in the equation above, however for each mission there are numerous reasoning logic algorithms that may be selected. The selected reasoning logic is the basis for a particular CEP engine. Now lets discuss how Service Oriented Architecture and the flow of events drive a particular mission COA. In this mission scenario we will reuse the previously described events and evaluate how the events may be sequenced and how a SOA can discover events to kickoff a manual or automated CEP scenario. Below we describe a data and event flow that results in a COA to ensure high accuracy catalog space surveillance mission assurance without interruption. (1) Cyber monitoring SOA services detect abnormal traffic patterns in a critical GIG network router; alert event published to NCES, indicating potential cyber attack (2) Space operations unit subscribing through a SOA to all events pertaining to a particular geographic area, receives the intelligence report events Space operations unit also receives through a SOA Intel Community report of increased cyber terrorist activities in the same area (3) The CEP engine calculates events using a SOA Vulnerability Assessment Service (discovery and query of events), the CEP engine suggests that a space surveillance sensors OCONUS ground station depends on a communications path being interrupted by the GIG router alert and within the geographic area of the intelligence reports, results in a vulnerable asset (initiated). (4) CEP creates a composite Threat Event (i.e. composite event) based on the two lower-level events, which triggers a CEP threat processing. The SSA analyst develops 3 COAs based on the CEP threat processing results. (5) Space C2 commander evaluates COAs to mitigate the threat; selected a COA to plan for alternate communication path. (6) When the cyber attack occurs, the Space C2 commander executes alternate COA, space surveillance mission carries on without interruption 6

As described in this mission scenario section, we touched on the foundations of event calculations and how the flow of data using a SOA with CEP appropriately ensures mission success.

5. IMPLEMENTATION
The EDDIE architecture proposed in Section 3 is very much technology-agnostic and platform-independent. Given the rapid advances in SOA and CEP technologies, it may be readily implemented using mainstream Commercial off the Shelf (COTS) or even Open Source Software (OSS) products. CEP engines, for instance, are now offered by companies such as Oracle, IBM, Tibco, Sybase, among others. One implementation example, adapted from our engagement with a military organization, is illustrated in Figure 5. Lessons learned from our implementation experience include the following: Due to the broad-reaching scope of this architecture, it is not possible nor desirable to implement the end-toend capability using a single product suite or a single vendor. Instead, the technical design should be based on a best-of-breed set of products. The success of the resulting best-of-breed implementation hinges upon a well-defined set of interoperability standards and specifications which significantly reduce risks of integration. Communities of interest (COI) should play an active role in defining standard event data vocabularies, schemas, and ontologies.

6. RELATED WORK
The state of the technology would not be complete without understanding who the market leaders are in providing CEP solutions. Industry insiders state CEP is still primarily used in research; however Wall Street is the biggest market currently using CEP operationally. Because of the lack of large foundational operational utility, many of the CEP providers have merged in an effort to gain sufficient market share. Sybase is one of the market leaders in providing CEP software solutions and acquired Aleri and Coral8 in February 2010 [21]. Aleri is known for its Wall Street projects including a liquidity management project for Barclays Capital and data filtering and performance monitoring for Mitsubishi UFJ Securities. Coral8 is known for its low-cost, developer-friendly CEP engine and graphical display product used by several industries. Other companies in the CEP market include IBM who acquired Infodyne and Apsoft and Oracle who acquired BEA. TIBCO and Microsoft are also working to increase their CEP capabilities and increase their market share. Many of the research tools being used for CEP have foundations in rule based expert systems including CLIPS and JESS to

mention a couple. Ruse based algorithms such as RETE developed by Dr. Charles Forgy in 1970 and CEP/Event Stream Processing (ESP) are continuously being validated for applicability to numerous applications for CEP [11]. To apply CEP technology to a particular mission area, specifically in the Aerospace business a significant amount of business process modeling is needed to ensure the CEP algorithm meet the mission need.

Ultimately, better decision support for commanders

Some areas of research still needing to be addressed include: Common languages, taxonomies, and ontologies for representing events and event relationships Situational understanding and assessment based on the streaming of events in an EDA Event-driven data fusion, such as de-duping of similar events from multiple sources Event combination and correlation with varying levels of confidence in the originating source

7. CONCLUSION
The proposed event driven SOA CEP approach will help expedite and expand existing SSA and C2 efforts in addressing C2SSA challenges and achieve the following benefits: Expedited timeline and enhanced Course Of Action (COA) development capability through capability reuse; Better alignment to requirements; Mission-relevant demonstration to leadership to ensure continued endorsement and support; Advanced technologies based on Net-Centric principles, resulting in easy adoption and operational transition

Some commercial CEP engines are actively working to resolve these problems, however additional research and business logic is needed to ensure the solutions will meet the mission needs.

Figure 5 - Representative Implementation Architecture 7

REFERENCES
[1] Alexopoulou, N.; Nikolaidou, M.; Chamodrakas, N.Y.; Chamodrakas, Y.; Martakos, D. Enabling On-the-Fly Business Process Composition through an Event-Based Approach. IEEE. [2] Anicic, Darko; Fodor, Paul; Sthmer, Roland; Stojanovic, Nenad. An Approach for Data-driven and Logic-based Complex Event Processing [3] FZI Forschungszentrum Informatik, Haid-und-Neu-Strae 10-14, 76131 Karlsruhe, Germany. Department of Computer Science, Stony Brook University, Stony Brook, NY 11794-4400, U.S.A. 2009 [4] AnnMarie Ericsson ; Mikael Berndtsson (2006). Detecting Design Errors in Composite Events for Event Triggered Real-Time Systems Using Timed Automata. Sch. of Humanities & Informatics, Skovde Univ. Services Computing Workshops, 2006. SCW '06. IEEE. [5] Asdre, K.; Nikolopoulos, S.D. (2006). P-tree structures and event horizon: efficient event-set implementations. Department of Computer Science, Ioannina Univ. Simulation Conference, 2005 IEEE Proceedings. [6] Chandy, K. Mani; Olson, Michael. (2008). Federated Event Systems: The Event Web. California Institute of Technology. [7] Francois Bry ; Michael Eckert. (2006). A High-Level Query Language for Events. Inst. for Informatics, Munich Univ. Services Computing Workshops, 2006. SCW '06. IEEE. [8] Ghosh, S. (2001). P2EDAS: asynchronous, distributed event driven simulation algorithm with inconsistent event preemption for accurate execution of VHDL descriptions on parallel processors. Dept. of Comput. Sci. & Eng., Arizona State Univ., Tempe, AZ. Computers, IEEE Transactions. [9] Kowalski, Robert; Sergot, Marek; Shanahan, Murray; Miller, Rob. A Logic-based Calculus of Events, in New Generation Computing, Vol. 4, No. 1, February 1986, pp. 6795. http://en.wikipedia.org/wiki/Event_calculus [10] Ling Liu ; Pu, C. ; Wei Tang . Continual queries for Internet scale event-driven information delivery. College of Computer Science, Georgia Institute of Technology, Atlanta, GA. Knowledge and Data Engineering IEEE Transactions, pages 610-628. [11] Lin, Peter; Lindberg, Johan; Kutner, Joe. Enhancing RETE Algorithm to support Dynamic Typing. 4th revision. 2008

[12] Luckham, David (2007). SOA, EDA, BPM and CEP are all Complementary. http://www.complexevents.com/2007/04/30/soa-edabpm-and-cep-are-all-complementary/soa-eda-bpm-andcep-are-all-complementary/. [13] Morrell, John. (2006). Making the Case for Complex Event Processing Software. http://www.informationmanagement.com/infodirect/20061103/10668341.html?zkPrintable=true. [14] Morell, John; Vidich, Stevan (2008). Building Distributed Applications. Complex Event Processing Architecture .NET Framework. Applies to: Financial Services Architecture .NET Framework. [15] Ortmann, S. ; Maaser, M. ; Langendoerfer, P. (2009). Adaptive pruning of event decision trees for energy efficient collaboration in event-driven WSN. IHP Microelectron., Frankfurt (Oder), Germany. Mobile and Ubiquitous Systems: Networking & Services, MobiQuitous, 6th International IEEE Conference. [16] Ping-peng Yuan ; Gang Chen ; Jin-xiang Dong ; Wei-li Han. (2002). Research on an event specification for eventbased collaboration support software architecture. Dept. of Comput. Sci. & Eng., Zhejiang Univ., China. Computer Supported Cooperative Work in Design, 7th International IEEE Conference, pages 99-104. [17] Reiss, S.P. (2003). Event-based performance analysis. Dept. of Comput. Sci., Brown Univ., Providence, RI, USA. Program Comprehension, 11th IEEE International Workshop. [18] Roth, Heinz; Schiefer, Josef; Obweger, Hannes; Rozsnyai, Szabolcs. (2010). Event data warehousing for Complex Event Processing. IEEE Computer Society. Secure Business Austria, Favoritenstrasse 16, 1040 Vienna, Austria. [19] Sharon, G. ; Etzion, O. Event-processing network model and implementation. IBM Haifa Labs, Haifa University Campus, Mount Carmel, 31905, Israel. IBM Systems Journal 2010. [20] Sharon, G. ; Etzion, O. (2010). Event-processing network model and implementation. IBM Haifa Labs, Haifa University Campus, Mount Carmel, 31905, Israel.IBM Systems Journal. [21] Sybase CEP platform, (2010). http://www.sybase.com/products/financialservicessolution s/sybasecep.

[22] Teo, Y.M. ; Onggo, B.S.S. (2004). Formalization and strictness of simulation event orderings Dept. of Comput. Sci., National Univ. of Singapore. Parallel and Distributed Simulation, PADS 18th Workshop, pages 89-96. [23] Walzer, K; rode, J; Wunsch, D; Groch, M. (2008). Event-driven manufacturing: Unified management of primitive and complex events for manufacturing monitoring and control. Factory Communication Systems IEEE International Workshop. [24] Ying Tan ; Vuran, M.C. ; Goddard, S. (2009). SpatioTemporal Event Model for Cyber-Physical Systems. Comput. Sci. & Eng., Univ. of Nebraska-Lincoln, Lincoln, NE, USA. Distributed Computing Systems Workshops. [25] Wenzel, G.; Yuan, E.; (2010). A Roadmap-Based Framework for Acquiring More Agile and Responsive C4I Systems, Proceedings of the 2010 AFCEA-GMU C4I Symposium, Fairfax, VA.

scale, distributed enterprise solutions using leading edge technologies, with special strengths in Service Oriented Architectures (SOA), Web Services, Enterprise Architecture (EA), IT Strategy, and System Integration. In the SOA arena specifically, Mr. Yuan has extensive experience in SOA capability planning, Net-Centric systems evolution and governance, architecture frameworks and methodologies, service portfolio management, and SOA standards and specifications. In the past 8 years he has provided strategy and technical leadership for several transformational initiatives across the DoD, including Integration Space Situational Awareness (ISSA), Distributed Common Ground System (DCGS) family of systems, Army Enterprise SOA Foundation (AE SOAF), and Net-Centric Enterprise Services (NCES).

BIOGRAPHY
Mr. Eric Yuan is a Senior Associate with Booz Allen Hamiltons Strategic Technology and Innovation (ST&I) Team. He has over 15 years of professional experience in software development and IT consulting in both commercial and public sectors. He has extensive expertise in architecting and delivering large-

Dr. Michelle Watton is a Lead Associate with Booz Allen Hamiltons Strategic Technology and Innovation (ST&I) Team. Michelle has over 11 years of experience primarily with ground and space data processing and commanding within operational satellite programs and space research projects. Michelle has published research associated with space situational data processing including modeling uncertainty using ontologies and fuzzy logic (Colorado Technical University, 2007), optimizing neural network abnormality classification (AIAA 20th Annual Conference on Small Satellites 2006) and Service Oriented Architecture based Enterprise Management for MILSATCOM Tactical Environments (MILCOM Conference 2011)