United States Department of Justice Service Orientation and

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

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

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

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

United States Department of Justice What is SOA?

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

United States Department of Justice SOA … • Is architecture – a set of best practices for the organization and use of IT • Abstracts software functionality as looselycoupled, 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

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 assessed via available discovery mechanisms.

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

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

United States Department of Justice Benefits of SOA Agility Speed Efficiency Services Revenue 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 Accountability Greater visibility for governance and compliance Costs Eliminate duplicate system, build once and leverage, reduced cost for integration Improve visibility into business operations, decrease dependency proprietary technologies/vendor lock-in Risk

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

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

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

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

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

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.

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.

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.

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

United States Department of Justice Global’s “Draft’ Justice Reference Architecture

United States Department of Justice Draft Justice Reference Architecture

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?

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

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 assessed via available discovery mechanisms.

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

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

United States Department of Justice What Is Service Interaction? I’d like to make a deposit Service Interaction Certainly, may I see some ID? Service Delivery Service Definition • 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 • Deposit Slip • Checks • ID Receipt Slip Request Message Response Message Network Message Transport = Hand Carried Message Teller requests Deposit transaction in bank system Deposit confirmation displayed in bank system

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

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

Additional Service Interaction Requirements? United States Department of Justice • 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) United States Department of Justice • 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 United States Department of Justice 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.

United States Department of Justice OASIS, W 3 C 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

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

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

United States Department of Justice Other “Common” Web Services Standards for SOA Services • Metadata Management WS-Addressing, WSMessage. Delivery, WS-Policy, Web Services Policy Language (XACML), WS-Metadata. Exchange • Messaging Reliability WS-Reliability, WSReliable. Messaging • Composite Message Level Security WS-Security. Policy, WS-Trust, WS-Secure. Conversation, WS-Federation

United States Department of Justice Other “Common” Web Services Standards for SOA Services • Notification (Publish/Subscribe) WS-Eventing, WS-Notification (WS-Base. Notification, WS-Topics, WS-Brokered. Notification • Transactions WS-Transactions (WS-Atomic. Transactions, WSBusiness. Activity, WS-Coordination) WS-Composite Application Framework (WS-Context, WSCoordination. Framework, WS-Transaction. Management)

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

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)

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 • Message Structure Level Interoperability SOAP-SOAP, MQmessage-MQmessage, REST-REST • Message Content Level Interoperability GJXDM-GJXDM, NIEM-NIEM, HIPPA-HIPPA, HL 7 -HL 7, UBL-UBL

United States Department of Justice WS-I & OASIS “Common” Profiles for Interoperability • WS-I Basic Profile • WS-I Attachment Profile (SOAP, WSDL, Bindings) (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 United States Department of Justice • 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

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

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 + eb. XML extensions + xml = eb. XML 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

United States Department of Justice All Service Interaction Occurs via Messages Capabilities 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 Interface Message Network Message Service Consumers Interaction Messages contain XML and non. XML data conforming to the Service Definition

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

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

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

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

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

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

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

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

JRA Concept Map Components and Service Definition Design United States Department of Justice Service Design Service Model Defines Non-Domain Specific Service Interaction Requirements (Security, Reliability, Transactions) Behavior Model Defines Domain Specific Functions and Actions the Service Needs to Perform (IEPD) Information Model Domain Vocabularies (NIEM / GJXDM) 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 United States Department of Justice Implementable Service Specifications Service Interaction Requirements Interface Description Requirements Message Exchange Patterns Message Definition Mechanisms Service Interaction Guidelines Service Interaction Profiles Domain and Non-Domain Service Specifications Supported by Service Interaction Profile (SIP) Service Interface(s) Specifications Message(s) Specifications Services Specifications

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

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

United States Department of Justice JRA Concept Map Components and Service Interaction Capabilities 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 Interface Message Network Message Service Consumers Interaction Messages contain XML and non. XML data conforming to the Service Definition

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

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

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

United States Department of Justice Questions? ? ?