Agenda. December 11, 2008, Doc# P RT SOA Services PDR 2

Transcription

1 December July 2, 11, 2008; 2008, Rev - 1 Doc# P RT SOA Architecture RT SOA Services PDR update PDR 11/12/08 1 1

2 Agenda 09:30 Welcomes Gary 09:45 Program Overview/Plan Gary/Brett 10:00 Software Development Kit Matt 11:00 Services Overview- Fred 11:30 Lunch 12:00 Adaptive Methods Services 13:00 Advanced Acoustic Concepts Services 14:00 Forward Plan Brett/All 14:15 Wrap-up Doc# P RT SOA Services PDR 2

3 Welcome Entrance Criteria Architecture PDR Completed; November 10, 2008 Software Development Kit Presented; December 5, 2008 Action Items Provided Risk assessments and risk mitigation plans are formally addressed Meeting coordination between teammates and Sponsor Exit Criteria Agreement on Service architecture Agreement on experiment plan Preliminary plan and date for Architecture CDR Doc# P RT SOA Services PDR 3

4 Program Overview

5 Problem Statement Tightly coupled tactical subsystem interface changes require application updates that are cost prohibited due to development, integration and recertification issues. Tactical systems often have multiple interface dependencies that are highly integrated causing single interface changes to affect multiple systems Changes to data distribution protocol routing require application changes Commercial SOA solutions do not support messaging performance required by tactical systems Proprietary infrastructure promotes vendor lock in and often cost prohibitive Multiple infrastructure solutions incur redundant costs to the Navy Communications across low bandwidth and ad-hoc networks impose challenging data sharing solutions Needed Capability Updates Are Being Delayed Because of Cost & Schedule Impacts Doc# P RT SOA Services PDR 5

6 Operational View RT SOA Deployment Target Organic Sensor backbone and integration Tactical Edge Communication that must handle Mobil Ad Hoc Networks and unreliable networks Organic Sensors Based on CANES_Industry_SRR_Outbrief-FINAL pdf RT SOA Benefits Low Cost Common System Infrastructure High Throughput, Low Latency Non Intrusive, Simplified System Integration Open Architecture & Open Standards ForceNet Integration Doc# P RT SOA Services PDR 6

7 Benefits Provides a Common Open Infrastructure to: Enable combat systems to leverage capabilities and information developed across multiple programs with real time messaging These programs may be under control of different ownership domains in the Community of Interest (COI) Decouples Infrastructure Constraints Decouples location, protocol, interface, hardware and software interoperability constraints between providers and consumers (Service Virtualization) Applications need not be Aware that SOA exists Promotes Loose coupling between Producers and Consumers Simplifies Integration Efforts Provides Transformation Services to allow Providers of data or services to be upgraded without forcing changes to the Consumers RT SOA Approach Promotes Re-Use, Interoperability, Low Cost Integration Doc# P RT SOA Services PDR 7

8 Objective Architecture PEO IWS Rapid PEO IWS Capability 5A APB Improvement 4-Step Process Process Upgrades/ Enhancements System Integration Testing Certification 2 ONR IWS5A / IWS5B APL Technology Assessment Advance Development Environment IWS5 PMS AN/SQQ-89(V) ARCI PMS PMS BYG-1 ARCI PMS Production BYG-1 Production System System Operational Environment Engineering Measurement Programs Improved Modeling, Assessments Requirements Generation Employment Guidelines Development Tactics & Training EMP Performance Measurement Tactical Systems Apples-to-Apples Embedded Data Collection Open Architecture Spiral Capability Improvement Requires An Adaptable Infrastructure Doc# P RT SOA Services PDR 8

9 Objective Architecture (cont.) Doc# P RT SOA Services PDR 9

10 Objective Architecture (cont.) RT SOA Key Requirements Doc# P RT SOA Services PDR 10

11 Technical Approach SOA Centralized Messaging JMS XML Data Structures XML-based Throughput and Loading XML Mediation XSLT, XQuery XML-based Content Routing XML Rules Enterprise QoS JMS Durability and Queuing RT SOA - All SOA Features PLUS Peer-to-Peer Messaging DDS Binary Data Structures Binary and XML Converted to Binary Binary Mediation Object. Memory Binary-based Content Routing DDS Rules Real Time QoS DDS Latency, Reliability RT SOA Builds Upon SOA XML/Enterprise Plus Real-Time Doc# P RT SOA Services PDR 11

12 Architecture Approach Applications Interfaces Applications can be AWARE or UNAWARE of the SOA Unaware applications will not need to change, the architecture will handle the message transformation necessary to move services/data from Producer to Consumer Producers will not force Consumers to change Lowers integration costs, increases portability, reduces capability enhancement cycle time Provides Real Time messaging to support tactical systems Unaware of SOA Producer Application e.g. CORBA IDL V.2 Legacy I/F Gateway (On Ramp) ESB I/F Core Services RT ESB ESB I/F Router (Off Ramp) Legacy I/F Consumer Application e.g. CORBA IDL V.1 Registry/Discovery Simplifies Integration Costs No Changes To Producer or Consumer Code Doc# P RT SOA Services PDR 12

13 Architecture Approach (cont.) Initial Development/Integration O O O O JBoss ESB with Open DDS (Real Time ESB) and Protocol Mediation JBoss SOA with Registry (Registration/Discovery), Data Mediation, Routing, and Workflow support Value-Added Services Q89 Data/Services (Tracks, Mission Planning Data) System Applications Track Display, Data Manager RT SOA Stack Red Hat JBoss SOA Core Services Management Discovery Registry Rules Workflow Data Mediation Value-Added Services Q89 AIS Radar VNE Service Definitions Registration Execution Process Consumers Producers System App Definitions Management Registry Application Definition Process Rules Workflow Data Mediation Enterprise Service Bus JBossESB Protocol Mediation Web services, Socket, JMS, CORBA, FTP, , File, Specialized Pluggable Real-Time Messaging System (RT ESB) OMG Data Distribution Service (DDS) and future Advanced Message Queuing Protocol (AMQP) Doc# P RT SOA Services PDR 13

14 Project Team Brett Steadman Navy Chief Engineer Mike MacKay Technical Director Fred Vignovich Chief Engineer Gary Sikora Program Manager Matt Fisher Software Manager Brian Samuels AM Contract Manager Data Manager Test Mike Hunter AAC Contract Manager Tap Point Manager Test DDS Development Steve Kruse AM Technical Lead David Battista AAC Technical Lead Malcolm D. Spence OCI Technical Director Steve Totten OCI Technical Lead Doc# P RT SOA Services PDR 14

15 Roles and Responsibilities Doc# P RT SOA Services PDR 15

16 Schedule Doc# P RT SOA Services PDR 16

17 Schedule (cont.) December 5 RT-SOA SDK Review Refine Experimentation Definitions and Milestones Progeny Systems RT SOA Test Harness, January Architecture CDR Adaptive Methods (AM) Undersea Warfare Decision Support System (USW-DSS) Data Manager, February Services CDR Advanced Acoustic Concepts (AAC) Mission Package Services (MPS) Tap Point Manager (TPM), February Services CDR OpenDDS January delivery Service Level Agreement (SLA) initial draft next report CV-TSC Alignment AM met with CV-TSC, setup meeting before year end AMOD Alignment meet with Leslie Madden in January USMC Alignment Charlestown/LTE Alignment Captain Davis Briefing Doc# P RT SOA Services PDR 17

18 Action Items Doc# P RT SOA Services PDR 18

19 CDRLs Delivery Approach Combine AAC and AM reporting and meeting CDRLs into Progeny AAC and AM specific CDRLs are delivered through Progeny e.g. Data Manager Requirements Document Artifact and Schedule Refinement AAC Tap Point Manager Align deliveries across AAC, AM and Progeny Experimentation focus Plan AAC, AM and Progeny meet and provide recommendation Progeny would then modify TIs Doc# P RT SOA Services PDR 19

20 Risk Management Doc# P RT SOA Services PDR 20

21 Risk Management (cont.) Doc# P RT SOA Services PDR 21

22 Agenda 09:30 Welcomes Gary 09:45 Program Overview/Plan Gary/Brett 10:00 Software Development Kit Matt 11:00 Services Overview - Fred 11:30 Lunch 12:00 Adaptive Methods Services 13:00 Advanced Acoustic Concepts Services 14:00 Forward Plan Brett/All 14:15 Wrap-up Doc# P RT SOA Services PDR 22

23 Summary of SDK Meeting December 5, Progeny Attendees Progeny, AAC and AM Technical Team Representatives Purpose Review the RT-SOA Software Development Kit Major Takeaways Overview of JBoss Architecture with Four In-Depth Examples Interactions with Teammates on using and building RT SOA Services Discussed test and timing approach Items to be addressed Monitor, Document and Manage Real time messaging and throughput Provide an end-to-end test case that details endpoints, infrastructure and service workflow Document positive effects on integration, development, deployment and maintenance Doc# P RT SOA Services PDR 23

24 Software Development Kit (SDK) Agenda SDK Overview JBoss Installation Out of Box Examples Subset of SDK Review on 5 December 2008 Doc# P RT SOA Services PDR 24

25 Software Development Kit (SDK) Overview The SDK is the framework being provided by Progeny to allow service developers to plug into and interact with the RT SOA application The intended audience consists of developers and engineers There will most likely be other tutorial sessions as the framework continues to be refined throughout the program lifecycle Doc# P RT SOA Services PDR 25

26 Running the JBoss ESB Server To start the JBoss ESB Server on Linux: Open a terminal window Change the current directory to INSTALL_DIR/jboss-soa-p -standalone.4.3.0/jboss-esb/bin Execute./run.sh INSTALL_DIR corresponds to the directory where the file standalone -soa ga.zip was unzipped INSTALL_DIR will be used throughout this presentation To stop the JBoss ESB Server, type CTRL-C in the same terminal Doc# P RT SOA Services PDR 26

27 SDK Examples Hello World Covers the basics of SOA interaction using gateways, routers, listeners, action lists and services Data Mediation Details how message data could be transformed using Smooks Content-Based Routing Discusses the use of rules to affect message routing and possibly message data mediation based on JBoss Rules/Drools Workflow Covers the use of service chaining/composition using jbpm Registry Outlines the role and use of the registry within JBoss s ESB Doc# P RT SOA Services PDR 27

28 Hello World Goal To explain the concepts and framework of the JBoss ESB through a simple example Operations Deploys a service to the running ESB server Sends a message to the service which triggers it to print Hello World to the server console Outline Create the IDE Project Start the JBoss ESB server Run the tutorial Doc# P RT SOA Services PDR 28

29 Running the Tutorial: Start the JBoss Server Enter JBoss server runtime directory INSTALL_DIR/jboss-soa-p-standalone.4.3.0/jboss-esb/bin Start the JBoss server./run.sh Doc# P RT SOA Services PDR 29

30 Deploy the JBoss Hello World Tutorial 1. Open the Project 2. Open the build script 5. Service deployed to ESB server 3. Right click deploy and select Run Target 4. Build successful Doc# P RT SOA Services PDR 30

31 What Happened Under the Hood JBoss Server JMS Provider Queue queue/quickstart_helloworld_request_gw 3. Gateway Listener picks up non-esb JMS message & makes it ESB-aware JMS Provider Queue queue/quickstart_helloworld_request_esb 5. Gateway Listener posts message to the provider for the service EPR 2. Client sends non-esb JMS message to JBoss Server; payload is Hello World (runtest) 6. ESB-aware Listener picks up the message from its configured ESBaware provider Non ESB-Aware Client JBoss ESB GatewayListener ESB-AwareListener 4. Gateway gets the EPR for the Service Action: Print Message Payload Service 7. Listener passes message to the Action Pipeline for processing Service Registry (Embedded) 1. Service registers its ESB-aware EPR (deploy) Doc# P * Diagram Based RT on SOA JBoss Services Getting PDR Started Manual 31

32 Data Mediation Goal Detail how message data could be transformed using Smooks Operations Deploys a service to the running ESB server Runs a driver that creates a structured product order document (XML) Header with purchaser name and id List of items purchased The file is converted by Smooks to a plain old Java object (POJO) A subset of the order info (item_id = 1) is separated and together with the header info (purchaser info) is FTP d to a preconfigured target Outline Create the IDE Project Start the JBoss ESB server Run the tutorial Doc# P RT SOA Services PDR 32

33 Deploy the JBoss Smooks Tutorial 1. Open the Project 2. Open the build script 5. Service deployed to ESB server 3. Right click deploy and select Run Target 4. Build successful Doc# P RT SOA Services PDR 33

34 View the Output 5 Mb Generated File FTP d file fragment in FTP user s Doc# smooks_file_splitter_router/build/dir/output P RT SOA Services PDR home directory 34

35 What Happened Under the Hood After the file name was routed to the ESB-aware listener, and inserted into the Action Pipeline, the following occurred: 1. The file data was prepared for the Smooks transform 2. The file data was transformed by Smooks 3. The data fragment file was FTP d to the targeted recipient We Will Focus on How a Smooks Transformation is Configured Doc# P RT SOA Services PDR 35

36 Smooks Document Transformation <?xml version="1.0"?> <smooks-resource-list xmlns=" <resource-config selector="global-parameters"> <param name="stream.filter.type">sax</param> </resource-config> <resource-config selector="order"> <resource>org.milyn.javabean.beanpopulator</resource> <param name="beanid">order</param> <param name="beanclass">java.util.hashtable</param> </resource-config> <resource-config selector="order-item"> <resource>org.milyn.javabean.beanpopulator</resource> <param name="beanid">orderitem</param> <param name="beanclass">java.util.hashtable</param> </resource-config> <resource-config selector=" order-item "> <resource>org.milyn.routing.file.fileoutputstreamresource</resource> <param name="resourcename">orderitemsplitstream</param> <param name="filenamepattern">pattern</param> <param name="destinationdirectorypattern">/tmp</param> <param name="listfilenamepattern">pattern</param> <param name="highwatermark">-1</param> </resource-config> <order id='332'> <header> <customer number="123">joe</customer> </header> </order> <order-items> <order-item id='1'> <product>1</product> <quantity>2</quantity> <price>8.80</price> </order-item> <order-item id='2'> <product>2</product> <quantity>2</quantity> <price>8.80</price> </order-item> <order-item id='3'> <product>3</product> <quantity>2</quantity> <price>8.80</price> </order-item> <order-items> The Smooks Configuration Provides a Transformation Process for Each Element of a Hierarchical Document <resource-config selector="order-item"> <resource>orderitem-split.ftl</resource> <condition evaluator="org.milyn.javabean.expression.beanmapexpressionevaluator">or der.orderitem.itemid == "1"</condition> <param name="outputstreamresource">orderitemsplitstream</ param> </resource-config> </smooks-resource-list> Doc# P RT SOA Services PDR 36

37 Smooks Document Transformation 1. Input Stream Filter SAX XML Parser 2. XML Stream to POJO Mapping 3a. Specifies File Output Streams & Patterns 3b. for the specified Splitting condition (itemid==1) Doc# P RT SOA Services PDR 37

38 Content-Based Routing (CBR) Goal To teach the basics of content-based routing, defined as the use of rules to examine message payload content and forward that message to the next action/service dynamically based on payload content. Operations Deploy 3 ESB services to the JBoss ESB server 1 CBR Service, 2 Shipping Services Route an order based on total amount of order Initially based shipping on $50, adjusted to $75 and rerouted Outline Create the IDE Project Start the JBoss ESB server Run the tutorial Doc# P RT SOA Services PDR 38

39 Deploy the Simple CBR Project 1. Open the Project 2. Open the build script 3. Right click deploy and select Run Target 5. Service deployed to ESB server 4. Build successful Doc# P RT SOA Services PDR 39

40 Run the Test Sample movie order is sent to the CBR service 1. Right click runtest and select Run Target 2. View the sent order, notice totalamount is over $50 Doc# P RT SOA Services PDR 40

41 Edit the rules No current editor for NetBeans; Eclipse is the editor of choice Change rules from 50.0 to 75.0 Drools rules Action that specifies rule set and CBR action class Doc# P RT SOA Services PDR 41

42 Details of CBR SDK Action Classes org.jboss.soa.esb.actions.contentbasedrouter Implements the Content Based Routing pattern. It routes a message to one or more destination services based on the message content and the rule set it is evaluating it against. The CBR throws an exception when no destinations are matched for a given rule set/message combination. This action will terminate any further pipeline processing, so it should be the last action of your pipeline. org.jboss.soa.esb.actions.contentbasedwiretap Implements the WireTap pattern. The WireTap is an Enterprise Integration Pattern (EIP) where a copy of the message is sent to a control channel. The CBR-WT is identical in functionality to the ContentBasedRouter, however it does not terminate the pipeline which makes it suitable to be used as a WireTap. org.jboss.soa.esb.actions.messagefilter Implements the Message-Filter pattern. The Message Filter pattern represents the case where messages can simply be dropped if certain content requirements are not met. The CBR-MF is identical in functionality to the ContentBasedRouter, but it does not throw an exception if the rule set does not match any destinations. In this case the message is simply filtered out. December 11, 2008, Doc# P RT SOA Services PDR 42

43 Workflow Tutorial Goal To teach the basics of service workflow, chaining (or composing) services together in order to achieve some objective Operations Deploy 5 ESB services to the JBoss ESB server 1 Starter Service, 3 Sample Services, 1 Result Services jbpm, JBoss s BPM solution, pulls services together Groovy does the work of printing process steps to JBoss console Outline Create the IDE Project Start the JBoss ESB server Run the tutorial Groovy is an OO language that runs in a JVM Doc# P RT SOA Services PDR 43

44 Deploy the BPM Orchestration Project 1. Open the Project 2. Open the build script 3. Right click deploy and select Run Target 5. Service deployed to ESB server 4. Build successful Doc# P RT SOA Services PDR 44

45 Workflow Process Definition using jpdl../bpm_orchestration1/processdefinition/ processdefintion.xml <?xml version="1.0" encoding="utf-8"?> <process-definition name="processdefinition2"> <start-state name="start"> <event type="node-leave"> <action name="action1" class="org.jboss.soa.esb.samples... </event> <transition to="node1"></transition> </start-state> <node name="node1"> <action name="action2" class="org.jboss.soa.esb.services.jbpm.actionhandlers.esbactionhandler"> <esbcategoryname>bpm_orchestration_service1</esbcategoryname> <esbservicename>service1</esbservicename> <bpmtoesbvars> <mapping bpm="thebody" esb="body_content" /> </bpmtoesbvars> <esbtobpmvars> <mapping esb="body_content" bpm="thebody" /> </esbtobpmvars> </action> <transition to="node2"></transition> </node> Doc# P </process-definition> RT SOA Services PDR 45

46 Registry Supports the use of endpoint references (EPRs) for service resolution Use of JAXR and UDDI Apache Scout: Java implementation of JAXR, standard API for accessing XML-based metadata registries juddi: Java implementation of UDDI, Universal Description Discovery and Integration Doc# P RT SOA Services PDR 46

48 RT SOA Service Definitions Services ESB Service Provided by the System developer implemented within the ESB Executes one or more Value Added Services or Core Services Defined in ESB Configuration File Value Added Service Provided by the System developer A single request and response that can be bound to synchronous or asynchronously Defined in ESB Registry Core Service Provided by the SDK Provides listeners and routers for various protocol types A single request and response that can be bound to synchronous or asynchronously Defined in ESB Registry Doc# P RT SOA Services PDR 48

49 Generic Workflow Producer Application Track Producer Track Consumer (Display) Consumer Application Message Legacy I/F Gateway (On Ramp) Java ESB I/F Work Flow ESB I/F Router (Off Ramp) Java Legacy I/F Message Message ESB I/F ESB Service A ESB I/F ESB I/F ESB Service B ESB I/F ESB I/F ESB Service C ESB I/F RT ESB Message RT ESB Message Action List Action 1 Action 2 Action N Actions can call Core Services, Value Added Services, or user defined classes Doc# P RT SOA Services PDR 49

50 ESB Service Message Driven Input to a service is a Message Listeners encapsulate the endpoint of the service input When developing services Determine the input Message and the response Message (if any) that will be generated. Structured from one or more Actions Actions can be chained together to process an incoming Message An Action itself is implementation specific An Action understands where the data resides within a Message. An Action earlier in the chain may modify the original input Message, or replaces it entirely. Doc# P RT SOA Services PDR 50

51 ESB Services In keeping with SOA principles, everything within the ESB is considered to be either a service or a message. Services encapsulate the business logic or points of integration with legacy systems. Messages are the way in which clients and services communicate with each other. An ESB Service is a list of Action classes that process a Message in a sequential manner. This list of Action classes is referred to as an Action Pipeline. An ESB Service can also define a list of Listeners. Listeners act like inbound routers for the Service, routing messages to the Action Pipeline. An ESB Service has category and name attributes. When the JBoss ESB deploys the ESB Service it uses these attributes to register the ESB Service's listeners as endpoints in the Service Registry. Doc# P RT SOA Services PDR 51

52 ESB Service (cont.) Message Routing Listeners Message Listeners act as inbound message routers that listen for messages (e.g. on a JMS Queue/Topic) and present the message to a message processing pipeline that filters the message and routes it ( outbound router) to another message endpoint. JBoss ESB supports two forms of listener configuration: Gateway Listeners Gateways link services and applications that are ESB-Unaware to the ESB - Gateways receive messages from non ESB services (Protocol Mediation) and send them to the ESB for processing - Provide a Gateway Startpoint/Endpoint that is used as a point of entry for messages from outside of your JBoss ESB deployment. - Have the responsibility for normalizing the message payload by wrapping it into an ESB Message before shipping it to the Service's Action Pipeline. ESB Aware Listeners These listener configurations provide an ESB Aware Endpoint. These Endpoint types are used to exchange ESB Messages between ESB Aware components. Doc# P RT SOA Services PDR 52

53 ESB Service (cont.) Routers off the ESB Routers send the ESB processed data (messages) off the ESB to ESB-Unaware Consumers Routers receive messages from the ESB via Listeners and send the message to Consumers on the transport mechanism needed by the consumer (Protocol Mediation) A good place for technical JBoss details: /html/programmers_guide/ Doc# P RT SOA Services PDR 53

54 Test Generator Producer Application Consumer Application Message Integrated Test App for Timing Legacy I/F Gateway (On Ramp) Java ESB I/F Work Flow ESB I/F Router (Off Ramp) Java Legacy I/F Message Message ESB I/F ESB Service A ESB I/F ESB I/F ESB Service B ESB I/F ESB I/F ESB Service C ESB I/F RT ESB Message RT ESB Message Action List Action 1 Action 2 Action N Actions can call Core Services, Value Added Services, or user defined classes Doc# P RT SOA Services PDR 54

59 Forward Tasking

60 Forward Tasking RT SOA Architecture Development Critical Test Items January Architecture CDR Progeny Expand on PDR Elements ESB Integration Approach Start with JBoss ESB Out-of-the-Box Switch over to RT-SOA February Common API and Configuration Files Doc# P RT SOA Services PDR 60

62 Backup Doc# P RT SOA Services PDR 62

63 OCI Phase I Schedule M1: Bootstrap (11/7/2008) JMX configuration, JCA connector, QoS configuration, DCPSInfoRepo wrapper, ConnectionFactory, Destination configuration, various OpenDDS and JNI wrapper enhancements/fixes M2: Simple Messages (11/21/2008) Initial implementation of end-to-end JMS messaging over OpenDDS: Connection and Session implementation, Message Producer, Message Consumer, Message IDL definition and implementation M3: Code-complete (12/16/2008) Reply-to and Temp Topics, Durable subscriptions, Message and Exception listeners, integration testing, documentation Basic demonstration of OpenDDS JMS Provider implementation integrated with JBoss ESB Doc# P RT SOA Services PDR 63