enterprise messaging system ems l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Enterprise Messaging System (EMS) PowerPoint Presentation
Download Presentation
Enterprise Messaging System (EMS)

Loading in 2 Seconds...

play fullscreen
1 / 23

Enterprise Messaging System (EMS) - PowerPoint PPT Presentation


  • 289 Views
  • Uploaded on

Enterprise Messaging System (EMS). SOA Brown Bag #6 . SWIM Team. April 14, 2011. 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Enterprise Messaging System (EMS)' - elina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
enterprise messaging system ems

Enterprise Messaging System (EMS)

SOA Brown Bag #6

SWIM Team

April 14, 2011

agenda
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
governance roles and responsibilities
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

governance implications
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

financial implications
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

funding swim services
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)
plans for moving forward
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
ems architecture overview dex conceptual architecture

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

ems architecture overview dex deployment architecture

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

ems messaging patterns
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

ems dex pub sub messaging overview

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

pub sub on ramping overview producer
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

pub sub on ramping overview consumer
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

ems dex pub sub messaging lessons learned
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
producer push model
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

esb interoperability support
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
web service virtualization
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
message compression
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
message filtering
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
multi threading
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

multi threading21
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

message batching
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