1. United States
Department of Justice
Service Orientation
and the
Justice Reference Architecture
Scott Fairholm, GISWG, GSWG
John Ruegg, GISWG, GSWG
GJXDM Users Conference
9/7/2006

2. United States
Department of Justice
After this session, you will
• Know the history of Global’s SOA Initiative
• Know what SOA is
• Understand what we mean by Architecture – the
Justice Reference Architecture
• Understand what Services are, and
• How Services interact with each other

3. United States
Department of Justice
Global’s SOA Initiative
• On Sept 29, 2004 Global adopted the
recommendations found in the report: A Framework
for Justice Information Sharing: Service Oriented
Architecture (SOA)
– Recognize SOA as the recommended framework for
development of justice information sharing systems
– Promote the utility of SOA for the justice community
– Urge members of the justice community to take corollary
steps in the development of their own system

4. United States
Department of Justice
Global’s SOA Vision
Any member of the justice community can
access the information they need to do their
job, at the time they need it, in a form that is
useful, regardless of the location of the data

5. United States
Department of Justice
What is SOA?

6. United States
Department of Justice
Service Oriented Architecture is not…
• SOA is not Web Services
• SOA is not about BPEL
• SOA is not about ESB
• SOA is not about XML or the GJXDM or NIEM
• SOA is not about Technology
• Not driven by the “How”
SOA is a fundamental change in the way we think
about “What” our business is

7. United States
Department of Justice
SOA …
• Is architecture – a set of best practices for the
organization and use of IT
• Abstracts software functionality as loosely-
coupled, business-oriented Services
• Composes services into business processes (which
are also Services) in a declarative manner
• Is about Change
• Helps IT respond to change and enable innovation
Source: Zapthink

8. United States
Department of Justice
SOA Characteristics
• Reusability – Logic is divided into
services with the intention of
promoting reuse.
• Contracts – Services adhere to a
communications agreement, as
defined collectively by one or more
service description documents.
• Loose coupling – Services maintain
a relationship that minimizes
dependencies and only requires that
they maintain an awareness of each
other.
• Abstraction – Beyond what is
described in the service contract,
services hide logic from the outside
world and define explicit
boundaries.
• Composability – Collections of
services can be coordinated and
assembled to form composite
services which are inherently
integrated without the need for
additional layers of middleware.
• Autonomy – Services have control
over the logic they encapsulate.
• Statelessness – Services minimize
retaining information specific to an
activity.
• Discoverability – Services are
designed to be outwardly descriptive
so that they can be found and
assessed via available discovery
mechanisms.

9. United States
Department of Justice
SOA Implications
Rather than dealing with isolated systems that
must be integrated after the fact, Service
Orientation provides business users with
understandable Services they can call upon and
compose into business processes as needed –
building systems that can adapt as the business
changes.
Source: Zapthink

10. United States
Department of Justice
•Orchestrated solutions
•Loosely coupled
•Message oriented (Metadata)
•Architecture makes it work
•Favors Heterogeneous Technology
•Implementation abstraction
SOA: Changing Thinking and Technology
•Function oriented
•Build to last
•Prolonged development cycles
•Cost centered
From To
•Application silos
•Tightly coupled
•Component/Object oriented
•Middleware makes it work
•Favors homogeneous Technology
•Known implementation
•Process oriented
•Build to change
•Incrementally built and deployed
•Business centered
Source: IBM, Microsoft, Zapthink

11. United States
Department of Justice
Benefits of SOA
Agility
Speed
Efficiency
Services
Revenue
Accountability
Costs
Risk
Develop flexible business models enabled by granular IT
processes, called “Services”
Combine and reuse prebuilt services for rapid application
development and deployment in response to changing needs
Integrate historically separate systems, reduce cycle times
and costs, fosters incremental implementation
Offer new services to customers without having to worry
about the underlying IT infrastructure
Create new value from existing systems
Eliminate duplicate system, build once and leverage, reduced
cost for integration
Improve visibility into business operations, decrease
dependency proprietary technologies/vendor lock-in
Greater visibility for governance and compliance

12. United States
Department of Justice
The Best Technology….
• Is complex on the inside yet simple on the outside
• The secret is the abstraction layer
Source: Zapthink

13. United States
Department of Justice
Business
logic
Focus on the Business– Process and Services
Application
a
Application
c
Application
b
Application
logic
Source: Service-Oriented Architecture, Thomas Erl

14. United States
Department of Justice
Application
layer
Services
interface
layer
Business
process
layer
.NET J2EE Legacy
Source: Service-Oriented Architecture, Thomas Erl
orchestration service
layer
business service layer
application service layer

15. United States
Department of Justice
SOA is Fractal
• Works equally well
– At the applications level
– At the enterprise level
– Across enterprises
• SOA supports the kind of
complex, heterogeneous,
distributed, environments we
face in Justice

16. United States
Department of Justice
SOA and the Natural World
• The Human Body is a complex system of
autonomous systems that “roll up” into a
large scale collaborative system
– The Circulatory System, for example
• Heart
• Blood Cells
• Arteries
• Etc.
– These discrete systems work together to
keep the body alive and support other
critical processes, like respiration,
speech, movement.
• In SOA we would call that Composability

17. United States
Department of Justice
SOA and the Natural World (Cont.)
• Each system functions independently
• Lower level functions are ubiquitous and exposed to
higher-level functions through a common interface
• The heart doesn’t worry about what the lungs do or
how they do it
• When you run or lift something heavy, the muscles
“ask” for more oxygen from a service (the
pulmonary-respiratory system).
– Your muscles don’t need to bother with how the
lungs absorb oxygen or what causes the heart to
beat faster.
• In the natural world this all makes sense. That’s how
it works.
• We are just catching up in the software world.

18. United States
Department of Justice
The Justice Reference Architecture…
An abstract framework for understanding
the significant concepts and components of
Service-Oriented implementations within
the justice and public safety communities
and for identifying where governance and
technical standards are needed to support
greater interoperability and information
sharing.

19. United States
Department of Justice
Levels of Abstraction
• A Reference Model
– Minimal set of unifying concepts, axioms and relationships that provides a
framework for understanding significant relationships among the entities of some
environment, independent of specific standards, technologies, implementations, or
other concrete details
– In the housing domain a “Food Preparation Area” is a reference model concept.
• A Conceptual Reference Architecture
– Provides abstract implementation solutions for the common concepts of the
reference model and allow for mapping across different implementation
architectures
– A “Kitchen” is an Conceptual RA version of the RM “Food Preparation Area”;
• Domain Reference Architecture(s)
– Provides an actual set of implementation standards that enables interoperability
– A specific kitchen design
• Large apartment complex- compact kitchen
• Suburban single family home – large kitchen
• House boat – galley kitchen
• An Implementation Architecture
– Your kitchen.

20. United States
Department of Justice
OASIS SOA Reference Model
Service
Contracts
& Policy
Service
Description
Execution
Context
Visibility
Interaction
Real World
Effect
About Services
•Service Descriptions
•Policies and Contracts
•Execution Context
Services
Dynamics of Services
•Visibility
•Interacting with Services
•Real World Effects

21. United States
Department of Justice
Global’s “Draft’ Justice Reference Architecture
Service Interaction
Profile Guidelines
Service Interaction
Profiles
Service Interaction
Requirements
Message Exchange
Patterns
Messages
Service Interfaces
Services Service Consumers
Real-World Effects
Capabilities
Visibility
Execution Context
Interaction
Orchestrations
produce
provide access to
use
seek
provide
access
to
are the means of
depends
on
leverage
information
contained
in
can
be
supported
by
accomplished
by
exchange
of
is described by
are composed of
Interface
Description
Requirements
Policies and
Contracts
structure
and
content
determined
by
constrain use of or
expected result of using
guide design and
description of
Message Definition
Mechanisms
govern content of
require support for
define
interoperable
implementations
of
define common rules of
enables and determines essential aspects of
describe ways of exchanging
define structure of
can be implemented by
can constrain
act as
Enterprise
Integration Patterns
identify common
types of
can
be
described
by
provider
systems
Repository
defines semantics of
hosts
assists
hosts
implement
consumer
systems
act as
Agreements
can be specified in
Concepts from OASIS SOA-RM
Legend
Conceptual Integration Technical Reference Architecture
Concept Map
establish
some
requirements
for
Service Model
Information Model
Behavior Model
can
contain
some
Domain
Vocabularies
conforms to,
uses
conform
to,
are
assembled
from
Business Process
Models
define
implement
enables
contains
contains
Willingness
Awareness
Reachability
are aspects of
Provisioning
Models
determine responsibility for
Intermediaries
Transformers
Routers
Message Validators
consist
of

22. United States
Department of Justice
Draft Justice Reference Architecture

23. United States
Department of Justice
Business Service Identification
and Design
How do you find the right set of business
services at the right level of granularity to
maximize business agility?

24. United States
Department of Justice
GISWG Services Committee
• Tasked with identifying
– Service Design Principles
– An initial prioritized list of candidate services
for the justice community
– A methodology for identifying Business
Services

25. United States
Department of Justice
SOA Principles
• Reusability – Logic is divided into
services with the intention of promoting
reuse.
• Contracts – Services adhere to a
communications agreement, as defined
collectively by one or more service
description documents.
• Loose coupling – Services maintain a
relationship that minimizes
dependencies and only requires that they
maintain an awareness of each other.
• Abstraction – Beyond what is described
in the service contract, services hide
logic from the outside world and define
explicit boundaries.
• Composability – Collections of
services can be coordinated and
assembled to form composite
services which are inherently
integrated without the need for
additional layers of middleware.
• Autonomy – Services have control
over the logic they encapsulate.
• Statelessness – Services minimize
retaining information specific to an
activity.
• Discoverability – Services are
designed to be outwardly descriptive
so that they can be found and
assessed via available discovery
mechanisms.

26. United States
Department of Justice
Business Service Identification–
Three Approaches
• Application-centric approach
• Business process approach
• Business capabilities approach

27. United States
Department of Justice
Service Interaction?
Service
Contracts
& Policy
Service
Description
Execution
Context
Visibility
Interaction
Real World
Effect
• What is a Service?
• What do you need to make
Services interoperate?

28. United States
Department of Justice
What Is Service Interaction?
Service Interaction
Service Definition Service Delivery
• Deposit Slip—Design
(Banking Domain Specific
IEPD)
• Receipt Slip—Design
(Banking Domain Specific
IEPD)
• ID—Design
Industry standard token
(non-Banking Domain
Specific IEPD);
drivers license, passport,
picture ID
I’d like to make
a deposit
Certainly, may I
see some ID?
Teller requests Deposit
transaction in bank system
Deposit confirmation
displayed in bank system
Receipt
Slip
• Deposit Slip
• Checks
• ID
Request
Message
Network Message Transport = Hand Carried Message
Response
Message

29. United States
Department of Justice
Service Interaction—Example II
Service Interaction
Service Definition Service Delivery
• Smoke Alarm - Design
(Engineering specification
IEPD)
Fire-and-Forget Message
Alarm Sounds
Wake Up (Real World Effect)
Smoke Event Alarm
Message
Network Message Transport = Sound Waves in Air

30. United States
Department of Justice
Does my IEPD define all of my Service
Interaction Requirements?
• You defined what functions your SERVICE performs
and what MESSAGES it Sends/Receives in your
(IEPD).
• You are done, RIGHT?
• NOT QUITE YET ….

31. United States
Department of Justice
Additional Service Interaction
Requirements?
• Do you need to know who is using your service?
• Does your service need to know what role/job function the
requestor represents before granting access?
• Is your message, or parts of your message confidential?

32. United States
Department of Justice
Additional Service Interaction
Requirements? (Continued)
• What message transport protocols will your service
support?
• Does your service need to support transaction processing
(commit/rollback)?
• Does your service rely on a distributed (Federated)
authentication model?

33. United States
Department of Justice
“Common” Service Interaction
Requirements
Most of these questions apply to any SOA
Service, not just the Service you are
developing. These “common” requirements
can be met using a set of Industry Standards &
technologies supported by a Service Interaction
Profile (SIP) in the JRA.

34. United States
Department of Justice
OASIS, W3C and WS-I Standards
These Standards Bodies Define Non-Domain
Specific, Vendor Neutral, Sets of Open
Standards for Addressing “Common” SOA
Service Requirements
GLOBAL Justice Reference Architecture
(JRA) modeled after the OASIS SOA
Reference Model

35. United States
Department of Justice
“Common” Security Controls for a SOA
Service
• Transport-level Firewalls, basic authentication,
encryption (https, ftps)
• Message Level Authentication and Authorization
Tokens
• Data Level Encryption and Digital Signature
for non-repudiation
• Environment Level Logging, auditing and
management

36. United States
Department of Justice
Web Services Security Framework
Message Confidentiality
XML Encryption
Message Integrity
(Non-Repudiation)
XML Digital Signature
Authentication Profiles
X.509
Username/Password
Kerberos
Subject Authorization
SAML Assertions
Core Web Services Security Specifications

37. United States
Department of Justice
Other “Common” Web Services Standards
for SOA Services
• Metadata Management WS-Addressing, WS-
MessageDelivery, WS-Policy, Web Services Policy
Language (XACML), WS-MetadataExchange
• Messaging Reliability WS-Reliability, WS-
ReliableMessaging
• Composite Message Level Security WS-SecurityPolicy,
WS-Trust, WS-SecureConversation, WS-Federation

38. United States
Department of Justice
Other “Common” Web Services
Standards for SOA Services
• Notification (Publish/Subscribe)
WS-Eventing, WS-Notification (WS-BaseNotification,
WS-Topics, WS-BrokeredNotification
• Transactions
WS-Transactions (WS-AtomicTransactions, WS-
BusinessActivity, WS-Coordination) WS-Composite
Application Framework (WS-Context, WS-
CoordinationFramework,WS-TransactionManagement)

39. United States
Department of Justice
Wide Industry Support for Web
Services Standards
• Web Services standards are numerous and supported by
major vendors including:
• IBM, ORACLE, SUN, SAP and Microsoft

40. United States
Department of Justice
What is a Service Interaction Profile
(SIP)?
• A SIP supports both your Domain Specific Service
Requirements (IEPD) and one or more of the
“Common” Non-Domain Specific Requirements your
Service needs to Implement (eg. Security Controls)

41. United States
Department of Justice
Service Interaction Profile (SIP)
Promotes Service Interoperability
• Message Transport Level Interoperability
http-http,https-https, ftp-ftp, jms-jms,MQseries-
MQseries
• Message Structure Level Interoperability
SOAP-SOAP, MQmessage-MQmessage,REST-REST
• Message Content Level Interoperability
GJXDM-GJXDM, NIEM-NIEM, HIPPA-HIPPA,
HL7-HL7, UBL-UBL

42. United States
Department of Justice
WS-I & OASIS “Common” Profiles
for Interoperability
• WS-I Basic Profile (SOAP,WSDL,Bindings)
• WS-I Attachment Profile(SOAP with Attachments)
• OASIS WS-Security Profile(s) (SOAP with Security)
– Username/Password Profile
– X.509 Profile
– Kerberos Profile
– SAML Profile
– Security Rights Expression Language Profile

43. United States
Department of Justice
SOAP for Interoperable Message
Structure
• Only SOAP provides an interoperable message container
for all of the Web Services standards
• SOAP requires an interoperable message transport
protocol such as HTTP to move messages between Service
Consumer and Service Provider

44. United States
Department of Justice
Communications Protocol Envelope (HTTP, SMTP,…)
SOAP With Attachments MIME Envelope
MIME Part
SOAP-ENV: Envelope
SOAP-ENV: Header
wsse: Security
wsr:Reliability /
wsrm:ReliableMessaging
SOAP-ENV: Body
Payload(s) IEPD XML Message
Non-Domain Specific IEPD Requirements
-- Industry Standard Profile Specifications for Subject
Authentication, Message Integrity, Confidentiality, etc.
-- Reliable Messaging Specifications
Domain Specific IEPD Requirements
-- Input/Output Message(s)
Internet Message Transport Protocols
-- (http, https, ftp, ftps, smtp)—Ubiquitous, Available On
All Service Consumer Platforms
Alternative Message Transport Protocols
-- (JMS, IBM MQ Series, TIBCO)—Service Consumer Must
Support Alternative Transport Protocol
Domain Specific IEPD Requirements
-- XML and non-XML Attachments Including Binary Files
Payload(s) IEPD Attachments
MIME Part(s)
Interoperable Message Container—SOAP

45. United States
Department of Justice
What about other SIP’s
• http + URI + xml = Simple Web Services(REST)
• http + SOAP + xml + wsdl = Simple Web Services
• http + SOAP + WS* SOAP extensions + xml + wsdl = Robust Web
Services
• http + SOAP + ebXML extensions + xml = ebXML style Web
Services
• SOA (proprietary – SIP) – COM/DCOM, CICS/IMS, Message
Oriented Middleware(MSMQ, JMS, IBM MQ-Series, TIBCO)
• Eg. Simple Web Services Amazon.com publishes REST/Web
Services and SOAP/Web Services

46. United States
Department of Justice
All Service Interaction Occurs via Messages
Service Interface
Capabilities
Service
Consumers
Network
Service Definition
A set of XML specifications and
narrative retrieved from the
Repository.
Specifications define the
Message(s), Message Exchange
Patterns, Security Requirements,
Service Model, Service Interface,
SLA,…
Service
Interaction
Messages contain XML and non-
XML data conforming to the Service
Definition
Message
Message

47. United States
Department of Justice
Service Interface
Query Response
Service
Query Response
Service
Query Response
Service
Service Interface
Federated Query
Service
Federated Query Service
Organization A
Service Consumer
Service Interface
Organization B Organization C
Service Interface
Organization X
Message
Message
Message
Message
Message

48. United States
Department of Justice
MAINFRAME
APPLICATION
Legacy Adapter
Validate Client
Address
Service
Service Enabling Legacy Systems
Service
Consumers
Message
3270
Validate Client
Address Transaction
3270 3270
3270
Network
Message

49. United States
Department of Justice
Multi-Channel Delivery of a Service
Service Interface
Bank Deposit Service
Service Consumer Service Consumer
ATM
Remote Bank Office Banking on the Web
LAN
Web Browser
Application
Service Provider
Service Consumer
Message
Message
Message

50. United States
Department of Justice
Fusion Center
Subscriber
Service
Fusion Center
Notification
Service
Fusion Center
Query/Response
Service
Fusion Center
Aggregation
Service
Information
Providers
Fusion Center Services
FUSION
CENTER
Information
Consumers
Information
Providers
Information
Subscribers
Message
Message
Message
Message
Message

51. United States
Department of Justice
SOA For Enterprise Application
Integration (EAI)
j2EE
.net
Fusion Centers
MSMQ
IBM MQ Series
SQL
c#
CICS
VB
TIBCO
Mainframe
COBOL
Packaged
Software
Business
Intelligence
Tools
Enterprise A
Execution Environment
ESB / Integration
Broker
Enterprise Internal Facing Services (EAI)
REST, JMS, MQ-SERIES
INTEGRATION

52. United States
Department of Justice
VB
Mainframe
COBOL
j2EE
.net
Fusion Centers
MSMQ
IBM MQ Series
SQL
ESB
c#
CICS
TIBCO
Packaged
Software
Business
Intelligence
Tools
Enterprise B
Execution Environment
SOA for Inter-Enterprise Services
VB
Mainframe
COBOL
j2EE
.net
Fusion Centers
MSMQ
IBM MQ Series
SQL
ESB
c#
CICS
TIBCO
Packaged
Software
Business
Intelligence
Tools
Enterprise A
Execution Environment
HTTP, SOAP, WSDL
Partner Facing External SOA Services
Message
Message

53. United States
Department of Justice
JRA Concept Map Components
Summary
Service Definition: Identify and Design your Service
Service Interaction: Describe your Service Interface(s)
Service Delivery: Code, Test, Deploy and Manage
your Service

54. United States
Department of Justice
Policies & Contracts
JRA Concept Map Components and
Service Definition Requirements
Agreements
Business Process
Model
Business Requirements
Analysis
Define Service(s) Required

55. United States
Department of Justice
Defines Non-Domain
Specific Service Interaction
Requirements
(Security,Reliability,Transactions)
Defines Domain Specific
Functions and Actions the Service
Needs to Perform (IEPD)
JRA Concept Map Components and
Service Definition Design
Behavior Model
Service Model Information Model
Domain Vocabularies
(NIEM / GJXDM)
Service Design
Defines Domain Specific
Information the Service Needs to
Provide and Inputs Required to
Activate the Service (IEPD)

56. United States
Department of Justice
JRA Concept Map Components and
Service Definition Specifications
Services
Specifications
Service Interface(s)
Specifications
Service Interaction
Profiles
Message(s)
Specifications
Implementable
Service Specifications
Interface Description
Requirements
Service Interaction
Requirements
Message Exchange
Patterns
Message Definition
Mechanisms
Service Interaction
Guidelines
Domain and Non-Domain
Service Specifications
Supported by
Service Interaction Profile (SIP)

57. United States
Department of Justice
JRA Concept Map Components
Service Definition Summary
SOA Service Definition:
A set of Implementable XML Specifications and Service Description
Artifacts and Narrative(s)

58. United States
Department of Justice
JRA Concept Map Components and
Service Discovery Interaction
Service Interface
Service Model
Repository
Willingness
Awareness
Reachability
Visibility
Service
Consumers
Network
Network Interaction
1) Search list of available services
2) Request service definition
3) Receive authorized service
definition
A variety of service repository
interfaces might be used, such as
UDDI, GUI-Web application search
tool, proprietary service-registry
interface

59. United States
Department of Justice
JRA Concept Map Components and
Service Interaction
Service Interface
Capabilities
Service
Consumers
Network
Service Definition
A set of XML specifications and
narrative retrieved from the
Repository.
Specifications define the
Message(s), Message Exchange
Patterns, Security Requirements,
Service Model, Service Interface,
SLA,…
Service
Interaction
Messages contain XML and non-
XML data conforming to the Service
Definition
Message
Message

60. United States
Department of Justice
Intermediaries
JRA Concept Map Components and
Service Delivery
Interceptors
Services
Capabilities
Execution Context
Real World Effects
Provisioning Model
Transformers
Routers
Orchestrations
Message
Validators
Service Provider technologies
used to implement Domain and
Non-Domain Specific Service
Specifications
Service Interfaces

61. United States
Department of Justice
JRA Concept Map Components and
Execution Context
Services
Capabilities
Sample
Execution Context(s)
Service Provider technologies
used to implement Domain and
Non-Domain Specific Service
Specifications
Service Interfaces
Service Provider
USES
TO CODE & TEST
PROGRAMS TO IMPLEMENT
AND
J2EE
Websphere
.NET
Integration Broker
Suites
ESB Tools
C#, C++
Portal Technology
ORACLE Application
Server Tools
SAP

62. United States
Department of Justice
JRA Concept Map Execution Contexts
Service Interaction
Service Definition
S
E
R
V
I
C
E
Service Interaction
Execution Environment
Service Delivery
Service
Consumers
Service Provider
Systems
I
N
T
E
R
F
A
C
E
S
E
R
V
I
C
E
Messages
Loose coupling, Business Agility, Re-
Use, Technology-Neutral, Application
Independent, Middleware Agnostic
Messages
GJXDM
NIEM
XML
UBL
SOAP
Service
Interaction
Profiles
REST
UML
WS-Security
Web Services
ebXML
UDDI
WSDL
j2EE
.net
Fusion Centers
MSMQ
IBM MQ Series
SQL
ESB
c#
CICS
VB
TIBCO
Mainframe
COBOL
Packaged
Software
Business
Intelligence
Tools
Service Delivery
Execution Environment

63. United States
Department of Justice
Questions???