Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enhancing The Role Of A Large Us Federal Agency As An Intermediary In The Federal Supply Chain Via A Service Registry And A Jbi Based ESB


Published on

Presentation at JavaOne 2009

  • Be the first to comment

  • Be the first to like this

Enhancing The Role Of A Large Us Federal Agency As An Intermediary In The Federal Supply Chain Via A Service Registry And A Jbi Based ESB

  1. 1. Enhancing the Role of a LargeUS Federal Agency as anIntermediary in the FederalSupply Chain via a ServiceRegistry and a JBI-based ESBWalt Melo and Wen ZhuModel Driven
  2. 2. Agenda> Context> Case Studies  Definitions  The Service Registry Experience  The JBI ESB Experience> Advanced topics 2
  3. 3. Environment> Work was performed at a large US federal agency that acts as an intermediary in the federal supply chain> Model Driven Solutions is a leading provider of professional services and products that leverage Enterprise Service Oriented Architecture (SOA), Model Driven Architecture (MDA) and the Semantic Web techniques and standards. 3
  4. 4. Challenges> Business Challenges > Technical Challenges  Improve the way its  Improve integration of new services and legacy Suppliers, Vendors, and applications Consumers publish and  Improve the visibility of discover services planned and existing services  Enhance Enterprise  Better manage the impact of Architecture Maturity change  Improve SOA Governance to  Improve the life-cycle better manage its service management of SOA portfolio assets, e.g., service descriptions  Respond better and faster to  Enhance its understanding change of all its services  Improve the enforcement of  Purpose and behavior / Business processes government policies  Service level agreements  Low TCO and High ROI  Dependencies 4
  5. 5. New Administration, Open Government Government should be … Transparent … Participatory … Collaborative -- President Obama SOA is a key enabler 5
  6. 6. Enterprise SOA as a Solution Approach Service Service Service Orchestration Governance BPMS Registry & Workflow Solution Lifecycle Service Integration Model Driven Architecture JBI- based ESB 6
  7. 7. Definition: Service Registry> What is SOA?  An architectural style for a community of providers & consumers of services to achieve mutual value.  Business and Technology Levels> What is a technology service?  “a service is a modular piece of software (a service provider) with a well-described interface that can be activated by another modular piece of software (a service consumer).” (Gartner, 2005)> What is a Service Registry?  A service registry is a software component which allows an organization to catalog and reference SOA assets required to support the deployment and use of services. 7
  8. 8. Definition: Java Business Integration(JBI) > JBI JBI  Defined with in Java Community Process (JCP) as JSR 208  JBI Specification 1.0 published in Is a Standard for 2005 ESB  Standard basis for a Java based ESB > ESB Is an Architectural Pattern for  A pattern of middleware that unifies SOA and connects services, applications and resources 8
  9. 9. More Definitions> Unified Modeling Language (UML)™ “provides a key foundation for OMGs, which unifies every step of development and integration from business modeling, through architectural and application modeling, to development, deployment, maintenance, and evolution.”> Model Driven Architecture (MDA) ® “[t]he three primary goals of MDA are portability, interoperability and reusability through architectural separation of concerns.”> Service Oriented Modeling Language (SoaML) “support the activities of service modeling and design and to fit into an overall model-driven development approach.”> Semantic Web “provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries.” 9
  10. 10. Agenda> Context> Case Studies  The Service Registry Experience  The ESB JBI Experience> Advanced topics 10
  11. 11. Service Registry Experience> Product: Sun Service Registry  Product selected by OCIO  Bundle with Sun Java Enterprise System  Based on freebXML (ebXML Registry)  ebXML centric  Partial support for UDDI 11
  12. 12. Features> Standards  Provides standards-based way to manage information assets> Classification and affiliation  Manages user-defined organization of and relationships among content and metadata> Validation and cataloging  Enforces conformance of content to user-defined standards> Lifecycles  Governance capabilities for managing information asset lifecycles> Query  Provides flexible mechanisms for content discovery > Encourage> Security reuse  Manages secure access to information assets> Event notification >Enhance  Facilitates event-based delivery of information to appropriate Governance personnel or systems> Federation •Lower TCO  Enables integration of information assets across organizational •Higher ROI boundaries 12
  13. 13. Service Registry:High Level Architecture Source: OASIS,ebXML Registry Service, 2007 13
  14. 14. SOA Standards:Where the Service Registry Fits In ServiceRegistry / Repository Source: SUN, 2007 14
  15. 15. The Agency As An Intermediary in theFederal Supply Chain> The agency is both a provider and a consumer of services Service Providers> This agency as a Service Broker (Vendors, Suppliers, etc.)  Eases Access to Services Performance Service  Accounting, Measurement across Based Delivery Services Contract  Unified Face to the Customer The Agency  Drives Reuse “Service Broker”  Increases Security  Improves Policy Management and Service Service Enforcement Request Delivery  Enhances SLA Management & Service Consumers Administration  Allows Shared Services Financing (Federal Agencies, DoD, etc.) 15
  16. 16. Enterprise Use Scenario source: Sun 16
  17. 17. The Role of Federal EnterpriseArchitecture (FEA)> FEA aligns Federal business functions and IT via a set of common (reference) models> FEA Reference Models provide a foundation for SOA> FEA Service Component Reference Model (SRM) provides service definition and decomposition for a SOA Performance Reference Model Requirements Business Reference Model Requirements Service Component Service Definition & Service Oriented Reference Model Decomposition Architecture (SRM) Data Access Needs Data Reference Model Implementation Standards & Technologies Technical Reference Model 17
  18. 18. Enterprise Scenario: Using FEA> FEA SRM Model is used for service classification. The Agency OCIO 1. FEA SRM taxonomy is published in the Service Registry 1) Publish FEA 3. Services are published in the Service SCM Taxonomy Registry 4) Discover services which comply 5. Services are classified against FEA with FEA SCM SRM Taxonomy classification Service 3) Classify Registry The Agency 7. Service Consumers discover services by 2) Publish Services querying the Service Registry using FEA Financial against Taxonomy as search criteria Services FEA SCM Descriptions 9. Service Consumers bind to the Services which match the query criteria 5) Bind & Invoke Services 11. Service Consumers invoke the appropriate services Service Consumer: Service Provider: 18
  19. 19. Government Policy Publication,Discovery, and Enforcement Service Provider Customer JBI Composite Application Binding Component Binding Component Invoke Service Security File Customer App Reliable Messaging Email WS Transaction FTP WSDL & JBI-based ESB WS-Policy Service Engine Service Engine Service Engine Transactional Transactional ValidationFind services with Policies Process Flow Service Logice.g., WS-Reliable Messaging Retrieve service Service Registry description & policies Policy Service Metadata Developer Publish Services Publish Government Policies Gov Policy 19
  20. 20. Usage Scenario: The Agency as a Service Broker Business Business BusinessCustomer Services Rules Process 5) Invoke Vendor 3) Invoke Create Price Quote Service Federal ESB DoD Requisition Agencies Service Service A Service B Web- COBOL J2EE Services App 4) Discover Service meta-data 2) Discover services for creation of requisitions 1) Publish Price Quote Service Service Registry Policy Metadata 20
  21. 21. Status> Current > Future  Operational prototype  What would like to do deployed  Provide a semantic-based  Registry populated with service registry / financial services repository  Include adequate semantics to support validation and reasoning  Provide capabilities to support service assets categorization, provenance, dependencies 21
  22. 22. Enterprise Knowledge Base:High Level Architecture Enterprise Knowledge Base Eclipse IDE EMF Adapter* Semantic Web Interface UDDI / ebXML Web-UI Knowledge Base XML “Rest” User Views Interface Transformation Forms Inference & Rules Browse Query Shared Concepts Sesame RDF KB File Get/Put Orbeon XForms Server Artifact / KB Integration Artifact Repository Subversion InterfaceConfiguration Mgmt Eclipse Subversion Tortoise Green = Existing Open Source 22
  23. 23. Agenda> Context> Case Studies  The Service Registry Experience  The JBI ESB Experience> Advanced topics 23
  24. 24. JBI ESB Experience> Focus on Java EE 5 and JBI infrastructures  Open source, open standard based ESB  Glassfish ESB  Apache ServiceMix (IONA FUSE ESB)  Products selected by OCIO  Refactor existing application (J2EE/WS) for JEE5/JBI  Open Source JBI platform comparison and assessment> Outcomes  Principles and patterns for reuse, interoperability, and agility  Alignment with SOA Reference Architecture  Elaborate the relationship of ESB and BPMS 24
  25. 25. Java Business Integration source: Apache > Apache ServiceMix  Deployed: IONA Fuse ESB Version > OpenESB  Deployed: Sun Java Application Server 9.1 Update 2 25
  26. 26. Why JBI? Business ProcessSupply Chain Vendor Customer The Agency Services Services Service Services On-Line Order RFQ Capture ESB ESB Normalized Message Router Other Organizations n Fe de Supplier e ratio ratio Fed n ESB NMR NMR ESB Services Order Services Processing Other Services Services Services “Traditional” ESB Challenges: > Reusability • JMS dependency? • Span? > Interoperability / Portability • Organizational buy in? • Scaling? • Reuse? 26
  27. 27. Why JBI?> Reusability  Reuse existing business service implementation:  Service engines support standard programming models: EJB, JAX-WS, XSLT, BPEL, etc. JBI Exclusive!  Reuse ESB component:  Standardized component interface: Based on WSDL 2.0 •Standard-based  No vendor lock-in. No open source community lock- approach in either> Loosely Coupled Services •Commercially  Message oriented: Normalized Message defined by JBI supported open  Contract driven: Interfaces described using WSDL JBI Exclusive! source> Interoperability •Foster reuse of  ESB Federation via standard protocol such as HTTP solutions and> Agility JBI Exclusive! components  Enable continuous business process improvement> Maintainability •Lower TCO  Metadata driven •Higher ROI 27
  28. 28. As-is J2EE Application The Federal Agency Under Study Customer J2EE Enterprise Application 2. SOAP/HTTPS Web Container Customer Legacy J2EE Application 1. HTML/HTTP 3.JDBC 28
  29. 29. Approach: Separating InfrastructureConcerns Infrastructure Concern: Transport Binding  “Can I receive the request via FTP instead?” Process SOAP Request Infrastructure Concern: Security Authenticate  “Can I use LDAP?” Partner  “Can I share credentials among applications?” Infrastructure Concern: Transaction Management Validate Request  “What if I need to access a JMS queue and a database in the same transaction?”  “How do I pass transaction through web service?” Process Request Persist Request Infrastructure Concern: Reliable Messaging  “I got an HTTP acknowledgement. But did my client really get my response?” Send SOAP Response Infrastructure Concern: Metadata and Policy  “How is metadata managed?” “ Can I publish my QoS requirements in a registry?” 29
  30. 30. Refactored JBI Application Customer The Federal Agency Under Study 2. SOAP/HTTPS JBI Composite Application No code change Binding Component Binding Component Security File Reliable Messaging Email Customer WS Transaction FTP Policy Application JBI-based ESB Metadata Service Engine Service Engine Service Engine 1. HTML/HTTP Transactional Transactional Validation Process Flow Service Logic WSDL 3.JDBC 30
  31. 31. Standards Addressing Infrastructure Concerns WS- QoS WS-Security WS-Transaction WS-Policy ReliableMessaging Metadata Messaging SOAP WS-Addressing WSDL Transport HTTP JMS FTP SMTP> JBI messaging model is based on abstract WSDL  Transport binding is specified the WSDL> Web Service Specifications (WS-*) address many QoS concerns  WS-* support can be specified in the WSDL  WS-* are leveraged in the refactored technical architecture 31
  32. 32. Comparing JBI Containers Component Ruse OpenESB 2.0 ServiceMix 3.3 Across ESBWeb Service Through Metro Through Apache CXFJMS Sun Java MQ (Default) Apache ActiveMQTransaction Support Through Glassfish ASTooling (Easy of use) Integrated with NetBeans IDE Fully support Maven and Spring Framework, and interceptorsPolicy Support Support WS-Policy WS-Policy support is weakEnterprise Integration Enterprise Integration Patterns Enterprise Integration Patterns through Camel SE through EIP Engine, CamelRegistryBusiness Process BPEL SE Apache ODEBusiness Rules DROOLSClustering Through AS and Protocol Clustering Through ActiveMQ ClusteringWS-* Support WS-Security, WS-Reliable WS-Security, WS-Notification Messaging, WS-Coordination, WS- AtomicTransaction, WS- SecureConverstation 32
  33. 33. Porting JBI Components •Standardized component interface: Based on WSDL 2.0 33
  34. 34. Agenda> Context> Case Studies  Definitions  The Service Registry Experience  The JBI ESB Experience> Advanced topics 34
  35. 35. SoaML and Model Driven Architecture(MDA) Computation Independent Model Stakeholders Business Drivers Business Context As-Is Business Service Architecture Develop Provide Plan and Design and Deliver After Care Processes Service ArchitectureInformation Model Mission-Critical Value Chain Value Chains Development of Government-wide Policy Marketing Acquisition Support Services Value Chains Financial Management Services Platform Independent Model Service Interface I.T. Services Human Capital Services Shared Services Value Chains As-Is Systems Service Contract Data Model Platform Specific Model/Implementation Open Source <wsdl:porttype Service Provisioning eGov Reference > … Architecture </wsdl:portype Web Services > Components 35
  36. 36. SoaML: Modeling Business ServicesA services architecture describes how participants A participant represents some partywork together for a purpose by providing and using that provides and/or consumes services expressed as service contracts. It is services. Participants may represent modeled as a UML collaboration. people, organizations or systems. A service contract is the specification of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will flow between them. It specifies the service without regard for realization, capabilities or implementation. 36
  37. 37. SoaML: Platform Independent Models A service contract is the specification of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will flow between them. It specifies the service without regard for realization, capabilities or implementation. It is modeled as a UML collaboration. A service interface defines the interface and responsibilities required for a participant to play a role in a service contract. It is the means for specifying how a participant is to interact to provide or consume a service according to the contract. It is modeled as a UML class. The Information model (not part of of SoaML) specifies the data classes used by the services 37
  38. 38. Provisioning for Technology Platforms Service connections across tiers are modeled as UML assembly dependencies. A components can be deployed on a specific physical tier. A tier ismodeled as a UML node. 38
  39. 39. ModelPro™ Project: The Open SourceProvisioning Engine OMG SoaML s ent UML Profile lem Imp ModelPro ( Open Source MDA Tools Uses Users SOA SoaML Cartridge Automates Model ModelPro for UsesProvisioning Java EE Provisioning Model Engine UML Tool Provisioning Profile Uses Manual Automated Platform Platform Application Deploy Application Application & IDE Artifacts Artifacts Platform & Tools (E.G. Eclipse/Netbeans/.NET) 39
  40. 40. ModelDriven.orgThe Open Source Model Driven Community> Current Projects  The ModelPro™ Project  ModelPro™ Cartridge Projects  Foundational UML Reference Implementation> Get Involved! 40
  41. 41. Walt MeloWen Zhu{walt-m, wen-z} 41
  42. 42. Enterprise Knowledge Base:The Future is Here 42