Best Practices for Designing and Building the Services of an SOA

(1)

Best Practices for Designing and

Building the Services of an SOA

Guido Schmutz

Technology Manager, Oracle ACE

Director for FMW & SOA

(2)

Abstract

This session will present best practices for designing

and building the services of an SOA. Different ways

of implementing services in different environments

and languages are presented and the pros and cons

of each approach will be discussed. The session will

cover how to ensure service versioning, why

contract-first is the preferred approach, and under

which circumstances a contract-last approach might

be valid and useful.

(3)

Guido Schmutz

Working for Trivadis for more than 14 years

Oracle ACE Director for Fusion Middleware and SOA

Co-Author of different books

Consultant, Trainer Software Architect for Java, Oracle,

SOA and EDA

Member of Trivadis Architecture Board

Technology Manager @ Trivadis

More than 20 years of software development

experience

Contact: [email protected]

Blog: http://guidoschmutz.wordpress.com

(4)

~350 employees ~180 employees ~20 employees

Trivadis Facts & Figures

11 Trivadis locations with more than 550

employees

Financially independent and sustainably

profitable

Key figures 2010

● Revenue CHF 101 / EUR 73 mio.

● Services for more than 700 clients in over

1‘800 projects

● Over 170 Service Level Agreements

● More than 5'000 training participants

● Research and development budget:

(5)

Agenda

Principles of Service Design

Service Design

Service Model and Implementation

Service Versioning

(6)

(7)

Service Design Principles

Standardized Contract – Implement a

standardized contract

Loose Coupling – Minimize dependencies

Abstraction – Minimize the availability of meta information

Reusability – implement generic and reusable logic and contract

Autonomy – implement independent functional boundary and

runtime environment

Composability – Maximize composability

Statelessness – Implement adaptive and state

management-free logic

(8)

Agenda

Service Design

Service Implementation

Service Versioning

(9)

Development Approaches

Bottom up

Top Down

Meet in the

middle (agile)

DB Files _Applications API Components Domain Produktio n Verkauf

F&E Rohstoffeingang Produktgenehmigung

Service Service Service Service Service Service T o p -D o w n B o tt o m -U p

(10)

Contract-First Web Service Design

Important for

service-orientation is the

standardizing

and

decoupling

of the

technical contract of

each service

Service-oriented design

therefore should be

based on a

contract

first approach

●

avoid the use of

(11)

Contract-First is

fine …..

But isn‘t it just too hard to get … ?

Most SOA platforms

do not make a

contract-first service design easy

● Creation of WSDL and XSD is too

much effort

There is build-in support in the IDE to

graphically implement WSDL and

XSD

● Platform specific, no standard for

(12)

“I like Contract First design, BUT “

Lot of repetition

● Very talkative

● More options than

(often) necessary => RPC/literal

How to ensure Design

guidelines ● WS-I compliance ● Asynchronous Interface ● Service versioning Ensure naming conventions ● Name of messages

● Name of port types

● Name of bindings <wsdl:definitions xmlns:tns="http://trivadis.com/service/credit-card/v1" ... name="CreditCardValidation-v1"> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name="validateCardRequest"> <wsdl:part name="request" element="tns:validateCreditCardPaymentRequest"/> </wsdl:message> <wsdl:message name="validateCardResponse"> <wsdl:part name="reply" element="tns:validateCreditCardPaymentResponse"/> </wsdl:message> <wsdl:message name="invalidCreditCardNumberFault"> <wsdl:part name="error„ element="tns:invalidCreditCardNumberFault"/> </wsdl:message> <wsdl:portType name="CreditCardValidationPT"> <wsdl:operation name="validateCard"> <wsdl:input message="tns:validateCardRequest"/> <wsdl:output message="tns:validateCardResponse"/> <wsdl:fault name="InvalidCreditCardNumberFault" message="tns:invalidCreditCardNumberFault"/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...> </wsdl:definitions> <xs:schema xmlns:xs=„..." xmlns:tns="http://www.trivadis.com/cdm/credit-card/v1" targetNamespace=„http://www.trivadis.com/cdm/credit-card/v1“ elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">

<xs:element name="creditCard" type="tns:CreditCardT"/> <xs:complexType name="CreditCardT">

<xs:sequence>

<xs:element name="creditCardKind" type="tns:CreditCardKindT"/>

<xs:element name="cardNumber" type="xs:string"/> <xs:element name="cardholderFirstName" type="xs:string" minOccurs="0"/> <xs:element name="cardholderLastName" type="xs:string"/> <xs:element name="expirationMonth" type="tns:MonthT"/> <xs:element name="expirationYear" type="tns:YearT"/> </xs:sequence>

<xs:attribute name="id" type="xs:int"/> </xs:complexType> <xs:simpleType name="CreditCardKindT"> <xs:restriction base="xs:string"> <xs:enumeration value="visa"/> <xs:enumeration value="mastercard"/> <xs:enumeration value="amexco"/> </xs:restriction> </xs:simpleType> ... /xs:schema>

(13)

Alternative: UML with “WS profile”

Enterprise Architect has a

special profile for WSDL

and XSD modelling

(14)

«Busi ness Type» Warehouse + name: {i d2} + number: {i d1} + address + capacity «Business Type» Vehicle + registrationNbr: {id2} + manufacturer + model + capacity + fl eetNbr

«Busi ness Type»

Journey + date: {i d1} + number: {i d1} + routeCode + i sScheduled «Business Type» Subcontractor + name: {id1} + address + perform anceRating + ourAccountNbr «Business Type» Subcontractor Location + shortName

+ address «Business Type»

Shipment + tagNbr: {i d1} + desti nationAddress + weight + di mensi on + speci al Needs + desti nationInstructions + charge + contentDescri ption «Business Type» Pick Up Point + shortName: {id1} + address + guidance «Business Type» Inv oice + number: {id1} + issueDate + total Amount + status + discountGiven «Business Type»

Inv oice Item

+ number: {id1} + description + charge

«Busi ness Type»

Account Entry + sequenceNbr: {id1} + amount + isDebit + reference + date «Business Type» Account + number: {i d1} + name + openi ngDate + balance

«Busi ness T ype»

Payment

+ date: {id1} + amount: {i d1}

«Busi ness Type»

Warehouse Position + number: {i d1} + descri ption + typeCode «Business Type» Customer

+ num ber: {id1} + nam e + bill ingAddress + lastYearShi pmentsVal ue + lastQtrShipmentsValue + thisQtrShipmentsValue + contactName1 + contactName2 «Business Type» HazardousShipment

«Busi ness Type»

FoodShipment «Business Type» Handling Procedure + parcelType: string + definition: stri ng + procedure: string + constraints: sting Shipping Finance Customer Relations Suppliers * in response to 0..1 1 is base for * 1 {i d1} makes * 0..1 currently conveying 1 1 {id1} holds shipments at * 0..1 currentl y holds * 1 pai d for by 0..1 *

defines procedures for * 1 origin for * 0..1 recorded i n 1 * visited on * * contains {id1} 0..1 recorded i n 1 0..1 currently stores * 1..* houses {id1} 1 requests 1..* 1 {i d1} ships from 1..* 1 receives 0..1 1 {i d1} makes * 0..* owns 1 * contains {i d1} Parcels System «Technical Interface» Subcontractors «Technical Interface» Shipments

«Techni cal Interface»

Pickup and Deliv er

«T echnical Interface»

Warehouses

«Technical Interface»

Customers

Accounts

«T echnical Interface»

Inv oices

«Technical Interface»

AddressFormatter

Inv oicing «T echnical Interface» Transactions «T echnical Interface» New Accounts Application Process Core Business Utility Underlying «Automation Unit»

Pickup and Deliv er

«Automation Unit»

Shipping Obj ects

«Automation Unit» Inv oices «Automation Unit» Customers «Automation Unit» Accounts «Automation Unit» Prov iderX «Automation Unit» Customer

Relationships «Automation Unit» Accounting System «Automation U... Schedule Pickup «T echnical Interface» Schedule Pickup «Automation U... Obtain Payment «Technical Interface» Obtain Payment

«Required Behavi or»

«Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior» «Required Behavior»

CBDI-SAE UML Profile

for SOA

http://everware-cbdi.com Service Implementation Architecture

Showing Services and Automation Units

Business Type Model

Showing Domains

«Node»

Technology Model::alpha :Sun Serv er

«Node»

Technology Model::beta :Sun Serv er

«Node» Technology Model::r01 : Router «executionEnvironment... :EJB Container (from Technol ogy Model )

«executionEnvironment...

:SOAP Engine (from Technol ogy Model )

«Automation Unit»

Implementation Model:: Customers

«Depl oyed AU» :Customers «Endpoint» :Customers «Servi ce Instance» cust01 :Customers «Servi ce Instance» cust02 :Customers «instanceOf» «Depl oy» «Depl oy» «instanceOf» «Deploy» «Endpoint Implementation» «manifest» «Deploy» «Communication Path» «Communicati on Path»

Service Deloyment Architecture

(15)

Using DSL to simplify WSDL generation

Import common.msgtype

namespace service.credit-card(1.0) using cdm.credit-card(1.0) as cc

message validateCardRequest extends common { creditCard : cc.CreditCard forAmount : Double } message validateCardResponse { requestNr : String[1:1] reservationNumber : String } fault invalidCreditCardNumber { code : String creditCard : cc.CreditCard } service CreditCardValidation { sync operation validateCard throws invalidCreditCardNumber input validateCardRequest output validateCardResponse } <wsdl:definitions xmlns:tns="http://trivadis.com/service/credit-card/v1" ... name="CreditCardValidation-v1"> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name="validateCardRequest"> <wsdl:part name="request" element="tns:validateCreditCardPaymentRequest"/> </wsdl:message> <wsdl:message name="validateCardResponse"> <wsdl:part name="reply" element="tns:validateCreditCardPaymentResponse"/> </wsdl:message> <wsdl:message name="invalidCreditCardNumberFault"> <wsdl:part name="error„ element="tns:invalidCreditCardNumberFault"/> </wsdl:message> <wsdl:portType name="CreditCardValidationPT"> <wsdl:operation name="validateCard"> <wsdl:input message="tns:validateCardRequest"/> <wsdl:output message="tns:validateCardResponse"/> <wsdl:fault name="InvalidCreditCardNumberFault" message="tns:invalidCreditCardNumberFault"/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...> </wsdl:definitions>

abstract message common {

requestNr : String [1:1] }

(16)

Domain Specific Language (DSL)

A Domain Specific Language (DSL) is

● A small programming language, which focuses on a particular domain

● The right tool for the right job

The opposite is a General Purpose Language (GPL)

● A language such as Java or C#

● A general purpose modeling language such as UML

A DSL can be a visual diagramming, programatic abstractions or

textual languages

● Text based DSL are more and more common

Examples of existing DSL‘s

● SQL, Ant, XML, BPEL, BPMN

Define you own custom DSL according to the problem

(17)

Prototype based on Eclipse XText

available

(18)

Service Contract Template => DSL

service CreditCardValidation { version : 1.0 namespace : CreditCard business-properties { name: Kreditkarten-Validierung purpose: domain: CreditCard technical-properties { owner: xxxx

service-type: BAS, BES

execution-frequency: 100 per day

operation validate-card

throws InvalidCreditCardNumber, ServiceFault { operation-group: read-only updating: true resultCache: true atomicTx: true idempotent: true can-particpate-in-tx: true

pattern: one-way | request-response input-message { RequestNr : ct.Text[1:1] CreditCard : cc.CreditCard } output-message ValidateCardResponse { RequestNr : core.Text CreditCard : cc.CreditCard

(19)

WS-I: check your contracts!

An open industry effort promoting Web Services interoperability

● ~130 member organizations (2004)

Deliverables …

● Profiles

● Sample applications

● Test tools and supporting materials

Current profiles …

● Basic Profile 1.1, 1.2 (in work)

● SOAP, WSDL, WS-Addressing, MTOM

● Basic Security Profile (in work)

● WS-Security and security token formats

Use these tools to check your contracts

(20)

Message Exchange Patterns (MEP)

There are four basic message exchange patterns (MEPs) used in Web

services

● One-Way - A message comes to the service and the service produces nothing in

response (Fire-and-Forget).

● Request/Response - A message comes to the service, and the service produces a

message in response (main program & subroutine architecture style).

● Solicit Response - The service sends a message and gets a response back

(Reverse Request / Response).

● Notification - The service sends a message and receives nothing in response

(Broadcast, Publish-Subscribe)

Solicit Response and Notification are not supported by the WS-I Basic

Profile Web Service Application Application One-Way Notification Request/Response Solicit Response

(21)

Standardized Service Data Models –

Canonical Data Model

(22)

Standardized Service Data Models –

Canonical Data Model

(23)

Service Usage Scope

Level of coupling

Typical WS-Attribute:

Granularity Scope Cross Organisational

Document or RPC style, LOB data representations

Function call, RPC or RMI Within Department

Inside Application

Tight

Loose

Within Organization

Document style, industry standard data formats

Document style, enterprise data formats

(24)

SOA Logical Architecture – Service

Categorization

(25)

Agenda

Service Design

Service Implementation

Service Versioning

(26)

a)

PL/SQL in the database holds logic

b)

Java holds business logic, data access is implemented in

PL/SQL

c)

Java holds business logic and data access (JDBC or O/R

Mapper), no PL/SQL in database

Application C Application A

What type of applications do we find

today?

Tables PL/SQL PL/SQL Tables ORM Java Application B Tables PL/SQL Java Storage Data Access Business Logic

(27)

PL/SQL Implementation of Use Case

PL/SQL Package specification

(28)

Java Implementation for Use Case

Customer Service Interface in Java

(29)

For B and C a Java Web Service Facade can be written

How can deploy existing PL/SQL logic as a Web Service ?

Application C Application A

Service-enable applications directly

Tables PL/SQL PL/SQL Tables ORM Java Application B Tables PL/SQL Java Resource Data Access Business Logic ???? Web Service

(30)

Service Interface

for Use Case

(31)

(32)

JAX-WS – WSDL First

Transformation

JAXB Annotations JAX-WS Annotations

(33)

Java with JAX-WS - Code First

Determines XSD

(34)

Native Database Web Service (11g)

A servlet in the database (DBWS) acts as a gateway to:

● SQL Statements

● XQuery

(35)

(36)

OSB adds a layer of indirection (virtualization)

● Mediation: Transformation, Filtering, Enrichment, Routing

● Adapter: supports integration of existing applications

OSB OSB

OSB

Service Enablement of DB logic

using Oracle Service Bus (OSB)

Application A Tables PL/SQL PL/SQL Resource Data Access Business Logic Mediation Web Service Facade Adapter Application A Tables Mediation Adapter Application A Tables PL/SQL PL/SQL Mediation DB Servlet SOA Platform

(37)

OSB and DB Adapter for

request-driven access to information

Problem

● Want to directly access data from DB of an existing Java application

Solution

● Use the DB Adapter on the OSB to implement CRUD DB operations

● Provide it as a contract-first SOAP web service on OSB

(38)

(39)

OSB adds a layer of indirection (virtualization)

● Mediation: Transformation, Filtering, Enrichment, Routing

● Adapter: supports integration of existing applications

OSB OSB

Service Enablement of Java using

Oracle Service Bus (OSB

Resource Data Access Business Logic Mediation Web Service Facade Transport Mediation Adapter SOA Platform Application C Tables ORM Java Application B Tables PL/SQL Java Java

(40)

OSB HTTP Transport to wrap JAX-WS

service

Problem

● Want to offer a contract-first SOAP-based Web Service to consumers

and not the JAX-WS service

Solution

● Use OSB HTTP Transport to wrap the JAX-WS Code-First service

SOAP Webservice Transform from/to canonical model

(41)

OSB HTTP Transport to wrap

JAX-WS Code First service

Proxy Service

XQuery Transformation

Business Service HTTP Transport

(42)

OSB EJB Transport to call EJB

Problem

● Want to use an EJB session bean directly without having to service

enable it first

Solution

● Use OSB EJB Transport to access the existing EJB session bean

RMI / IIOP Transaction propagation

(43)

OSB EJB Transport to call EJB

(44)

Service Enablement in BPEL/BPMN

Application A Tables PL/SQL PL/SQL Resource Data Access Business Logic OSB Web Service Facade BPEL and BPMN Application C Tables ORM Java Application B Tables PL/SQL Java Java Java SOA Platform Mediation Adapter Mediation Mediation Orchestration

(45)

Automatic Build &

Deployment

Goals

● Automate everything

● WLS Domain creation

● Schema repository creation

● OSB & SOA artifacts build

& deployment

● soapUI integration testing

● Hudson Integration ● Continuous Integration Tools ● Hudson ● Maven ● soapUI ● Subversion

(46)

Agenda

Service Design

Service Versioning

(47)

Service Versioning

Services once deployed can never be

changed

●

Stable endpoints, don‘t necessarly know our

consumers

WS-* specs have

no versioning

concept in place

(48)

Service Versioning

In software, major-minor versioning is used to accommodate

two levels of change

A

major change

indicates a large update that creates an

incompatibility with existing deployments

● Typically indicates large scale revisions of the product with

significant new features or bug fixes

● Change to the first digit

A

minor change

indicates an update that is backward

compatible with existing deployments of the software that share

the same major version

● Typically contain a number of small new features, bug fixes and

issues resolutions that do not break compatibility

(49)

Implementing Versioning on ESB

Common Endpoint for all versions

One Endpoint per Major Version

with Version in Message

(50)

Service Versioning

(51)

Service Versioning

(52)

Agenda

Service Design

Service Versioning

(53)

Summary

Standardized Service Contract => use contract-first

design => wrap contract-last services

Service Categories

●

Make sure to categorize your services

Implement minimal Service Governance

●

Service Versioning

(54)

My other sessions @ Kscope11

Reusing Existing Java EE Applications

from Oracle SOA Suite 11g, Tuesday 1:45

– 2:45 Room 203C

Fault Handling in Oracle SOA Suite 11g,

(55)

Best Practices for Designing and

Building the Services of an SOA

Please Fill Out Your Evaluations

Guido Schmutz

Technology Manager, Oracle ACE

Director for FMW & SOA

Trivadis AG, Switzerland