Presentation at JavaOne 2009

1. 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
Walt Melo and Wen Zhu
Model Driven Solutions
www.modeldriven.com

2. Agenda
> Context
> Case Studies
 Definitions
 The Service Registry Experience
 The JBI ESB Experience
> Advanced topics
2

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. 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. New Administration, Open Government
Government should be
… Transparent
… Participatory
… Collaborative
-- President Obama
SOA is a key enabler
5

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. 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. 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. More Definitions
> Unified Modeling Language (UML)™
“provides a key foundation for OMG's, 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. Agenda
> Context
> Case Studies
 The Service Registry Experience
 The ESB JBI Experience
> Advanced topics
10

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. 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. Service Registry:
High Level Architecture
Source: OASIS,ebXML Registry Service, 2007
13

14. SOA Standards:
Where the Service Registry Fits In
Service
Registry / Repository
Source: SUN, 2007
14

15. The Agency As An Intermediary in the
Federal 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. Enterprise Use Scenario
source: Sun
16

17. The Role of Federal Enterprise
Architecture (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. 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. 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 Validation
Find services with Policies
Process Flow Service Logic
e.g., WS-Reliable Messaging
Retrieve service
Service Registry description &
policies
Policy Service
Metadata Developer
Publish Services
Publish Government Policies
Gov Policy
19

20. Usage Scenario: The Agency as a
Service Broker
Business Business Business
Customer 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. 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. 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
Interface
Configuration Mgmt
Eclipse
Subversion
Tortoise
Green = Existing Open Source
22

23. Agenda
> Context
> Case Studies
 The Service Registry Experience
 The JBI ESB Experience
> Advanced topics
23

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. Java Business Integration
source: Apache
> Apache ServiceMix
 Deployed: IONA Fuse ESB Version 3.3.1.1
> OpenESB
 Deployed: Sun Java Application Server 9.1
Update 2
25

26. Why JBI?
Business Process
Supply 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. 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. 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. Approach: Separating Infrastructure
Concerns 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. 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. 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. Comparing JBI Containers
Component Ruse
OpenESB 2.0 ServiceMix 3.3 Across ESB
Web Service Through Metro Through Apache CXF
JMS Sun Java MQ (Default) Apache ActiveMQ
Transaction Support Through Glassfish AS
Tooling (Easy of use) Integrated with NetBeans IDE Fully support Maven and Spring
Framework, and interceptors
Policy Support Support WS-Policy WS-Policy support is weak
Enterprise Integration Enterprise Integration Patterns Enterprise Integration Patterns
through Camel SE through EIP Engine, Camel
Registry
Business Process BPEL SE Apache ODE
Business Rules DROOLS
Clustering Through AS and Protocol Clustering Through ActiveMQ Clustering
WS-* Support WS-Security, WS-Reliable WS-Security, WS-Notification
Messaging, WS-Coordination, WS-
AtomicTransaction, WS-
SecureConverstation
32

33. Porting JBI Components
•Standardized
component interface:
Based on WSDL 2.0
33

34. Agenda
> Context
> Case Studies
 Definitions
 The Service Registry Experience
 The JBI ESB Experience
> Advanced topics
34

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. SoaML: Modeling Business Services
A services architecture describes how participants
A participant represents some party
work 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. 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. 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 is
modeled as a UML node.
38

39. ModelPro™ Project: The Open Source
Provisioning Engine OMG SoaML
s
ent UML Profile
lem
Imp
ModelPro (ModelDriven.org)
Open Source MDA Tools Uses
Users SOA
SoaML Cartridge Automates Model
ModelPro for
Uses
Provisioning 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. ModelDriven.org
The Open Source Model Driven Community
> Current Projects
 The ModelPro™ Project
 ModelPro™ Cartridge Projects
 Foundational UML Reference
Implementation
> Get Involved!
40

41. Walt Melo
Wen Zhu
{walt-m, wen-z}@modeldriven.com
41

42. Enterprise Knowledge Base:
The Future is Here
42