Service Orientation and the Justice Reference Architecture

United StatesDepartment of Justice

Service Orientationand the

Justice Reference Architecture

Scott Fairholm, GISWG, GSWGJohn Ruegg, GISWG, GSWG

GJXDM Users Conference 9/7/2006


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


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


Global’s SOA VisionAny 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


What is SOA?


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


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


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.


SOA ImplicationsRather 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


•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


Benefits of SOAAgility

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 needsIntegrate historically separate systems, reduce cycle times and costs, fosters incremental implementationOffer new services to customers without having to worry about the underlying IT infrastructureCreate new value from existing systems

Eliminate duplicate system, build once and leverage, reduced cost for integrationImprove visibility into business operations, decrease dependency proprietary technologies/vendor lock-in

Greater visibility for governance and compliance


The Best Technology….• Is complex on the inside yet simple on the outside

• The secret is the abstraction layer

Source: Zapthink


Bu

sin

ess

lo

gic

Focus on the Business– Process and Services

Applicationa

Applicationc

Applicationb

Ap

plic

atio

nlo

gic

Source: Service-Oriented Architecture, Thomas Erl


Ap

plic

atio

n la

yer

Se

rvic

es

inte

rfa

ce la

yer

Bu

sin

ess

p

roce

ss la

yer

.NET J2EE Legacy

Source: Service-Oriented Architecture, Thomas Erl

orchestration service layer

business service layer

application service layer


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


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


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.


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.


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.


OASIS SOA Reference Model

Service

Contracts & Policy

ServiceDescription

ExecutionContext

Visibility

InteractionReal World

Effect

About Services•Service Descriptions•Policies and Contracts•Execution Context

Services

Dynamics of Services•Visibility•Interacting with Services•Real World Effects


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 EffectsCapabilities

Visibility

Execution Context

Interaction

Orchestrations

produce

provide access to

use

seek

pro

vide

acc

ess

to

are the means of

dep

en

ds o

n

leve

rag

e in

form

atio

n co

nta

ine

d in

can

be

su

ppo

rted

by

acc

om

plis

he

d b

y ex

cha

ng

e o

f

is described by

are composed of

Interface Description

Requirements

Policies and Contracts

stru

ctu

re a

nd

con

ten

t de

term

ine

d b

y

constrain use of orexpected result of using

guide design anddescription of

Message Definition Mechanisms

govern content of

require support for

def

ine

inte

rop

era

ble

imp

lem

ent

atio

ns

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 commontypes of

can

be

de

scri

bed

by

providersystems

Repository

defines semantics of

hosts

ass

ists

hos

ts

implement

consumersystems

act as

Agreementscan be specified in

Concepts from OASIS SOA-RM

Concepts particular to the TRA

LegendConceptual Integration Technical Reference ArchitectureConcept Map

est

ablis

h s

om

e re

qui

rem

ents

for

Service Model

Information Model

Behavior Model

can

co

nta

in s

ome

Domain Vocabularies

conforms to,uses

con

form

to

, are

ass

em

ble

d fr

om

Business Process Models

define

implement

enables

containscontains

Willingness

Awareness

Reachability

are aspects of

Provisioning Models

determine responsibility for

Intermediaries

Transformers

Routers

Message Validators

con

sist

of


Draft Justice Reference Architecture


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?


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


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.


Business Service Identification– Three Approaches

• Application-centric approach• Business process approach• Business capabilities approach


Service Interaction?

Service

Contracts & Policy

ServiceDescription

ExecutionContext

Visibility

InteractionReal World

Effect

• What is a Service?

• What do you need to make Services interoperate?


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

ReceiptSlip

• Deposit Slip• Checks• ID

Request Message

Network Message Transport = Hand Carried Message

Response Message


Service Interaction—Example IIService Interaction

Service Definition Service Delivery

• Smoke Alarm - Design (Engineering specification IEPD)

Fire-and-Forget MessageAlarm SoundsWake Up (Real World Effect)

Smoke Event AlarmMessage

Network Message Transport = Sound Waves in Air


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 ….


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?


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?


“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.


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


“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


Web Services Security Framework

Message ConfidentialityXML Encryption

Message Integrity(Non-Repudiation)

XML Digital Signature

Authentication ProfilesX.509

Username/PasswordKerberos

Subject AuthorizationSAML Assertions

Core Web Services Security Specifications


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


Other “Common” Web Services Standards for SOA Services• Notification (Publish/Subscribe)

WS-Eventing, WS-Notification (WS-BaseNotification, WS-Topics, WS-BrokeredNotification

• TransactionsWS-Transactions (WS-AtomicTransactions, WS-BusinessActivity, WS-Coordination) WS-Composite Application Framework (WS-Context, WS-CoordinationFramework,WS-TransactionManagement)


Wide Industry Support for Web Services Standards

• Web Services standards are numerous and supported by major vendors including:

• IBM, ORACLE, SUN, SAP and Microsoft


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)


Service Interaction Profile (SIP) Promotes Service Interoperability• Message Transport Level Interoperability

http-http,https-https, ftp-ftp, jms-jms,MQseries-MQseries

• Message Structure Level InteroperabilitySOAP-SOAP, MQmessage-MQmessage,REST-

REST • Message Content Level Interoperability

GJXDM-GJXDM, NIEM-NIEM, HIPPA-HIPPA, HL7-HL7, UBL-UBL


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


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


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


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


All Service Interaction Occurs via Messages

Service Interface

Capabilities

ServiceConsumers

NetworkNetwork

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


Service Interface

Query Response Service



Service Interface

Federated QueryService

Federated Query ServiceOrganization A

Service Consumer

Service Interface

Organization B Organization C

Service Interface

Organization X

MessageMessage

Message

Message

Message


MAINFRAME APPLICATION

Legacy Adapter

Validate ClientAddress Service

Service Enabling Legacy Systems

Service Consumers

Message

3270

Validate ClientAddress Transaction

3270 32703270

NetworkNetwork

Message


Multi-Channel Delivery of a Service

Service Interface

Bank Deposit Service

Service Consumer Service Consumer

ATMRemote Bank Office Banking on the Web

LAN

Web BrowserApplication

Service Provider

Service Consumer

MessageMessage

Message


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

United StatesDepartment of JusticeSOA 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 AExecution Environment

ESB / IntegrationBroker

Enterprise Internal Facing Services (EAI)

REST, JMS, MQ-SERIES INTEGRATION


VB

Mainframe COBOL

j2EE

.net

Fusion Centers

MSMQ

IBM MQ Series

SQL

ESB

c#

CICS

TIBCO

Packaged Software


Enterprise BExecution Environment

SOA for Inter-Enterprise Services

VB

Mainframe COBOL

j2EE

.net

Fusion Centers

MSMQ

IBM MQ Series

SQL

ESB

c#

CICS

TIBCO

Packaged Software


Enterprise AExecution Environment

HTTP, SOAP, WSDL

Partner Facing External SOA Services

Message

Message


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


Policies & Contracts

JRA Concept Map Components and Service Definition Requirements

AgreementsBusiness Process

Model

Business Requirements Analysis

Define Service(s) Required


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 ModelService 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)


JRA Concept Map Components and Service Definition Specifications

ServicesSpecifications

Service Interface(s)Specifications

Service InteractionProfiles

Message(s)Specifications

ImplementableService Specifications

Interface DescriptionRequirements

Service InteractionRequirements

Message ExchangePatterns

Message DefinitionMechanisms

Service InteractionGuidelines

Domain and Non-DomainService Specifications

Supported by Service Interaction Profile (SIP)


JRA Concept Map Components Service Definition Summary

SOA Service Definition:

A set of Implementable XML Specifications and Service Description Artifacts and Narrative(s)


JRA Concept Map Components and Service Discovery Interaction

Service Interface

Service Model

RepositoryWillingness

Awareness

Reachability

Visibility

ServiceConsumers

NetworkNetwork

Network Interaction

1) Search list of available services2) Request service definition3) Receive authorized service

definitionA variety of service repository interfaces might be used, such as UDDI, GUI-Web application search tool, proprietary service-registry interface


JRA Concept Map Components and Service Interaction

Service Interface

Capabilities

ServiceConsumers

NetworkNetwork

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


Intermediaries

JRA Concept Map Components and Service Delivery

Interceptors

Services

Capabilities

Execution Context

Real World Effects

Provisioning Model

TransformersRouters

Orchestrations

MessageValidators

Service Provider technologies used to implement Domain and Non-Domain Specific Service

Specifications

Service Interfaces


JRA Concept Map Components and Execution Context

Services

Capabilities

SampleExecution Context(s)

Service Provider technologies used to implement Domain and Non-Domain Specific Service

Specifications

Service Interfaces

Service Provider

USES

TO CODE & TESTPROGRAMS TO IMPLEMENT

AND

J2EE

Websphere

.NET

Integration BrokerSuites

ESB Tools

C#, C++

Portal Technology

ORACLE ApplicationServer Tools

SAP


JRA Concept Map Execution ContextsService Interaction

Service Definition

SERVICE

Service InteractionExecution Environment

Service Delivery

ServiceConsumers

Service ProviderSystems

I NTERFACE

SERVICE

Messages

Loose coupling, Business Agility, Re-Use, Technology-Neutral, Application Independent, Middleware Agnostic

Messages

GJXDM

NIEM

XML

UBLSOAP

ServiceInteractionProfiles

REST

UML

WS-Security

Web Services

ebXML

UDDI

WSDL

j2EE

.net

Fusion Centers

MSMQ

IBM MQ Series

SQL

ESB

c#

CICS

VBTIBCO

Mainframe COBOL

Packaged Software


Service DeliveryExecution Environment


Questions???

Date post:	23-Dec-2014
Category:	Documents
Upload:	zubin67
View:	462 times
Download:	0 times

Service Orientation and the Justice Reference Architecture

Documents