Enterprise Messaging System (EMS)

1. Enterprise Messaging System (EMS) SOA Brown Bag #6 SWIM Team April 14, 2011

2. Agenda • SWIM Current Status • Plans for Moving Forward • EMS Architecture Overview • EMS Messaging Patterns • EMS Pub/Sub Messaging Overview • EMS Pub/Sub On-Ramping Overview • EMS On-Ramping Lessons Learned

3. Governance Roles and Responsibilities NAS Governance SWIM performs Service-Oriented Architecture (SOA) suitability assessments in support of the Enterprise Architecture Review Board/Technical Review Board (EAB/TRB) Identify potential providers of NAS services Programs assessed at investment decisions (IARD, IID, FID) EAB/TRB approves authorized providers of SWIM-compliant National Airspace System (NAS) services Enterprise SOA Governance SWIM ensures governance compliance SWIM will NOT attempt to govern SOA implementations that are internal to NAS programs

4. Governance Implications Programs will use the enterprise SOA infrastructure provided by SWIM Programs will not develop their own redundant enterprise SOA infrastructure Programs will meet SWIM-compliance requirements as required by EAB/TRB Disputes related to implementation of enterprise SOA will be resolved by the EAB/TRB

5. Financial Implications Enterprise SOA infrastructure costs will be included in the SWIM Segment 2 baseline SWIM-compliance costs for NAS services will be included in each program’s Joint Resources Council (JRC) funding request Programs will prepare SWIM Provider Provisioning Plan (SPPP) at the Final Investment Decision (FID) Joint effort between program and SWIM Based on the program’s Final Program Requirements and Architecture

6. Funding SWIM Services • General Approach: • SWIM conducted JRC, with F&E funding requested to develop initial Core Services, followed by “user-funded Operations & Maintenance (O&M)” • JRC conducted by Service-requesting program; funding provided to SWIM, who builds service with O&M phase “user- funded” • Requires knowledge of: • Total costs to provide Core Services • Number of anticipated service consumers • Schedule of need dates for service consumers • Decision on service development costs and benefits: • Spread among all consumers? • “First consumer” bears the full burden of the cost? • NextGen expected to provide FY11 development cost for: • Network Time Protocol (NTP) • Identity and Key Management (IKM)

7. Plans for Moving Forward • Building out initial nodes • ACY (May) & ATL (June) • Planning future upgrades • Additional Customer-Required Functionality • Additional Nodes (e.g. OKC, SLC) • Identifying customers • SPPP • Producer Template (ITWS, CIWS, WMSCR, TBFM/TMA, NNEW, AIM, MAPS) • Consumer Template (Internal and External) • Producer/Consumer Workshops

8. Stakeholders – Make Decisions Process – Procedures, Metrics, Control Mechanisms Policies – Decisions Made NAS Users External Customers Sponsor Programs NAS Enterprise Security Gateway Interface Toolkit NAS-Wide Governance Providing Central Direction System/Security Admin Service Administration WAN Services Network Security Service Portfolio Management Service Level Security Enterprise Services Identity Management Access Management UESB Enterprise Service Repository Enterprise Domain Tier ESB Enterprise Registry/ Catalog Domain Specific Governance Providing Local Autonomy Infrastructure Service Developers Service Management Enterprise Services Federated Registry Federated Repository Service Domain Tier Managed Access To Enterprise Services Standards-Based ESB Interface Legacy System Interface ARTCC n TRACON n SWIM Implementing Program Legacy System TRACON 1 ARTCC 1 SWIM Service Container Legacy Infrastructure NAS Applications NAS Applications NAS Applications NAS Applications NAS Applications NAS Applications NAS Users NAS Users EMS Architecture Overview – DEX Conceptual Architecture Enterprise Domain Tier DEX Separates the IT and integration infrastructure concerns from domain specific ATM concerns Decoupled using JMS and WS Legend DEX Service FTI Service Service Container Enabled Apps Legacy NAS System Apps Enables NAS use of multiple vendor technologies avoiding lock-in NAS programs and lines of business are executed by domain experts Policy Implementation Points

9. Core ARTCC N Core ARTCC 1 Core ARTCC 1 DEX Messaging Node DEX Messaging Node DEX Messaging Node ARTCC (Western Hub) ARTCC (Eastern Hub) ARTCC (Central Hub) DEX Messaging Node DEX Messaging Node DEX Messaging Node DEX Access Management Node DEX Access Management Node DEX Access Management Node Primary NOCC Backup NOCC DEX System Management Node DEX System Management Node EMS Architecture Overview – DEX Deployment Architecture NAS Service Management Service Administration FTI WAN Service Level Security Enterprise Registry/Catalog Enterprise Service Repository DEX Enabled NESG DEX Enabled NESG External FAA Customers (e.g. Airlines, Airports) External FAA Customers (e.g. Airlines, Airports) Enterprise Domain Service Bus

10. EMS Messaging Patterns • Publish/Subscribe – implemented using Java Messaging Service (JMS) • Request/Response – implemented using web services Primary emphasis has been Pub/Sub messaging services

11. CBR Header Header Header data data data EMS DEX Pub/Sub Messaging Overview 2. Connect Producer for publishing via JMS Producer Subscription Configuration (DEX Navigator) Content Stream 3. Configure subscription content for Consumers 1. Define messages, metadata, and taxonomy 1. Define messages, metadata, and taxonomy Content Taxonomy (Content Catalog) Messaging Service Consumer B Consumer A Routing Info 4. Connect Consumers and subscribe to assigned topic(s) 5. Route data to Consumer(s) based on currently configure subscriptions Jump Start Kit Jump Start Kit Jump Start Kit DEX Admin or Consumer

12. Pub/Sub On-ramping Overview - Producer Content products & metadata defined by Producer DEX Activity Producer Activity Messages, routing attributes and content taxonomy defined, Producer queue needs defined Producer and DEX Activity Producer queue(s) configured, names provided to Producer Content Catalog updated by DEX administrator DEX connection information and client JAR file provided by DEX administrator Producer application connects to DEX Optional Dex Jumpstart Kit “On-ramping” Tool

13. Pub/Sub On-ramping Overview - Consumer DEX Navigator Connection information & credentials provided by DEX administrator DEX Activity Consumer Activity DEX Navigator Content list & metadata accessed by Consumer Consumer and DEX Activity Content & topic(s) selected by Consumer to define subscription(s) Content & topic(s) configured by DEX administrator to support subscription(s) DEX connection information and client JAR file provided by DEX administrator Consumer application connects to DEX Optional Dex Jumpstart Kit “On-ramping” Tool

14. EMS DEX Pub/Sub Messaging – Lessons Learned • Producer Push Model • Enterprise Service Bus (ESB) Interoperability Support • Web Service Virtualization • Message Compression • Message Filtering • Multi-threading • Message Batching

15. Producer Push Model Products are pushed to the DEX DEX Messaging Node • Benefits • A common set of security policies can be established and enforced for accessing enterprise level information • The sharing of all enterprise level information can be monitored from the Producer service access point to the Consumer access point providing SLA policy enforcement and enhanced situational awareness • A common approach to providing effective load balancing and highly available messaging for enterprise level data can be leveraged across the enterprise • Loose coupling with providers • Common interface for providers Producer Service Bus Processor Service Bus Processor Service Bus Processor FTI WAN Load Balancer SAP Content

16. ESB Interoperability Support • ESB has powerful interoperability capabilities • Demonstrated support for JMS interoperability between different vendors (Oracle, IBM, Progress) • Demonstrated application level messaging protocol mediation • JMS to Web Services (WS) – JMS producer sending to WS consumer • WS to JMS – WS producer sending to JMS consumer • Message format transformations • JMS – Simple Object Access Protocol (SOAP) • SOAP – JMS • Extensible Markup Language (XML) - XML

17. Web Service Virtualization • Definition – management of web service endpoints transparently for consumers • Alternatives • Run-time Registry, Load balancer, ESB • Experience to date • Run-time Registry can interoperate with ESB • Run-time Registry may be overkill (high $$$) given anticipated NextGen scenarios (Weather Domain may be exception) • Load Balancer on Roadmap • ESB message flows can be configured with web service endpoints, this is current approach of DEX

18. Message Compression • Message compression can be used to increase throughput while lowering network bandwidth utilization • Compression becomes more beneficial as message size increases (500B ~25%, 10kB ~80%) • Alternative approaches - Producer compression, DEX compression • Producer • If messages are small Producer can pack messages and compress yielding better results • Consumer would need to decompress and unpack messages • DEX • For larger messages DEX can compress received messages, route to consumers, and decompress transparently to consumers

19. Message Filtering • Definition – removing or altering the content of a message payload • Alternative approaches - Producer filtering, DEX filtering • Producer filtering • Producer filters data and publishes filtered and non-filtered messages tagged to indicate filtering characteristics to DEX • DEX routes messages to authorized users per established policy using header attributes • Use when domain specific business rules govern filtering to keep business domain decoupled from enterprise domain – e.g., Airport Surface Detection Equipment, Model X (ASDE-X) sensitivity filtering • DEX filtering • DEX filters data and publishes data to authorized users per established policy • Use when generic business rules govern filtering – e.g., unconditionally clearing given fields of a message for a class of consumers

20. Multi-threading • Messaging throughout can often be adversely effected by message transfer delay (latency) • This is especially true for acknowledged messages. • For example, a roundtrip latency of 10 milliseconds (ms) would limit a sequential message transfer using a single thread to no greater than 100 messages per second (mps) Message 99 Message 1 Message 2 Thread Message 100 10 ms 20 ms 990 ms 1000 ms

21. Multi-threading • Multi-threading – using multiple threads in a process to achieve more effective utilization of processing resources • Messaging throughout can be increased to overcome high latencies by using a multi-threaded process that is transferring messages • Enables message transfers to be overlapped to effectively compensate for the transfer latencies of sending and then waiting on the acknowledgement • Each thread can transfer messages almost concurrently (minimal input/output (I/O) resource wait time) and in this three-thread case almost triple the effective throughput • As long as there is available bandwidth, the thread count can be increased to achieve increasing throughput • The other limiting factor on thread count is processing resources of the host processor Thread Thread Thread Message 99 Message 99 Message 99 Message 1 Message 1 Message 1 Message 1 Message 1 Message 1 Message 100 Message 100 Message 100 Net throughput approaches 300 mps 10 ms 20 ms 990 ms 1000 ms

22. Message Batching • In order to achieve higher message throughput rates over the Wide Area Network (WAN), a message batching feature may be utilized • Message batching consists of collecting a configurable number of messages (Message Max) and creating one large message at the DEX that contains these messages for subsequent transmission to the consumer • There are additional configurable parameters that control the amount of time the message batcher will wait for the Message Max to occur for batching • There is a trade-off between batch size and latency – large batch yields higher latency • Once the batched message is received on the consumer end, the messages are unpacked and delivered to the end consumer one at a time making the message batching transparent to the end consumer • Tests with WAN 24ms round trip latency

23. WWW.SWIM.GOV