Best Practices for Designing and Building the Services of ... · PDF fileBest Practices for Designing and Building the ... This session will present best practices for designing and

Best Practices for Designing and Building the Services of an SOA

Guido SchmutzTechnology Manager, Oracle ACE Director for FMW & SOATrivadis AG, Switzerland

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.

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� Twitter: gschmutz

~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: CHF 5.0 / EUR 3.6 mio

Agenda

� Principles of Service Design� Service Design� Service Model and Implementation� Service Versioning� Summary

Principles of Service -Orientation

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� Discoverability – implement communicative meta information

Agenda

� Principles of Service Design� Service Design� Service Implementation� Service Versioning� Summary

Development Approaches

� Bottom up� Top Down� Meet in the

middle (agile)

DBFiles Applications

API Components

Domain

Produktion

Verkauf

F&E Rohstoffeingang Produktgenehmigung

Service

Service Service

Service

Service

Service

Top-

Dow

n

Bot

tom

-Up

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 auto-

generation tools Source: Thomas Erl, Principles of Service Design

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 tographically implement WSDL andXSD● Platform specific, no standard for

look-and-feel

“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 namingconventions● 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>

Alternative: UML with “WS profile”

� Enterprise Architect has a special profile for WSDL and XSD modelling

«Business Type»Warehouse

+ name: {id2}+ number: {id1}+ address+ capacity

«Business Type»Vehicle

+ registrationNbr: {id2}+ manufacturer+ model+ capacity+ fleetNbr

«Business Type»Journey

+ date: {id1}+ number: {id1}+ routeCode+ isScheduled

«Business Type»Subcontractor

+ name: {id1}+ address+ performanceRating+ ourAccountNbr

«Business Type»Subcontractor

Location

+ shortName+ address

«Business Type»Shipment

+ tagNbr: {id1}+ destinationAddress+ weight+ dimension+ specialNeeds+ destinationInstructions+ charge+ contentDescription

«Business Type»Pick Up Point

+ shortName: {id1}+ address+ guidance

«Business Type»Inv oice

+ number: {id1}+ issueDate+ totalAmount+ status+ discountGiven

«Business Type»Invoice Item

+ number: {id1}+ description+ charge

«Business Type»Account Entry

+ sequenceNbr: {id1}+ amount+ isDebit+ reference+ date

«Business Type»Account

+ number: {id1}+ name+ openingDate+ balance

«Business Type»Payment

+ date: {id1}+ amount: {id1}

«Business Type»Warehouse Position

+ number: {id1}+ description+ typeCode

«Business Type»Customer

+ number: {id1}+ name+ bill ingAddress+ lastYearShipmentsValue+ lastQtrShipmentsValue+ thisQtrShipmentsValue+ contactName1+ contactName2

«Business Type»HazardousShipment

«Business Type»FoodShipment

«Business Type»Handling Procedure

+ parcelType: string+ definition: string+ procedure: string+ constraints: sting

Shipping

Finance

Customer Relations

Suppliers

*

in responseto

0..1

1

is base for

*

1{id1}makes

*

0..1

currentlyconveying

1

1{id1}

holdsshipmentsat*

0..1 currently holds

*

1

paid for by0..1

*

defines procedures for

*

1

origin for

*

0..1

recorded in

1

*

visited on

**

contains

{id1}0..1

recorded in

1

0..1

currentlystores

*

1..*

houses

{id1}

1

requests

1..*

1{id1}

ships from

1..*

1

receives

0..1

1{id1}

makes

*

0..*

owns

1

*

contains

{id1}

Parcels System

«Technical Interface»

Subcontractors


Shipments


Pickup and Deliver


Warehouses


Customers


Accounts


Invoices


AddressFormatter


Invoicing


Transactions


New Accounts

Application

Process

Core Business

Utility

Underlying

«Automation Unit»Pickup and Deliver

«Automation Unit»Shipping Objects

«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


Schedule Pickup

«Automation U...Obtain Payment


Obtain Payment

«Required Behavior»










«Required Behavior»«Required Behavior»








CBDI-SAE UML Profile for SOA

http://everware-cbdi.comService Implementation ArchitectureShowing Services and Automation Units

Business Type ModelShowing Domains

«Node»Technology Model::alpha :Sun Server

«Node»Technology Model::beta :Sun Serv er

«Node»Technology Model::r01 :

Router

«executionEnvironment...:EJB Container

(from Technology Model)

«executionEnvironment...:SOAP Engine

(from Technology Model)

«Automation Unit»Implementation Model::

Customers

«Deployed AU»:Customers

«Endpoint»:Customers

«Service Instance»cust01 :Customers

«Service Instance»cust02 :Customers

«instanceOf»

«Deploy»

«Deploy»

«instanceOf»

«Deploy»

«Endpoint Implementation»

«manifest»

«Deploy»

«Communication Path»«Communication Path»

Service Deloyment ArchitectureShowing Deployments

Using DSL to simplify WSDL generation

Import common.msgtypenamespace service.credit-card(1.0)using cdm.credit-card(1.0) as cc

message validateCardRequest extends common {creditCard : cc.CreditCardforAmount : Double

}message validateCardResponse {

requestNr : String[1:1]reservationNumber : String

}

fault invalidCreditCardNumber {code : StringcreditCard : cc.CreditCard

}

service CreditCardValidation {sync operation validateCard throws invalidCreditCardNumber

input validateCardRequestoutput 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]

}

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 ortextual 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● Service interface in our case

Prototype based on Eclipse XText available

Service Contract Template => DSLservice CreditCardValidation {

version : 1.0namespace : CreditCard

business-properties {name: Kreditkarten-Validierungpurpose:domain: CreditCard

technical-properties {owner: xxxxservice-type: BAS, BESexecution-frequency: 100 per day

operation validate-card throws InvalidCreditCardNumber, ServiceFault {

operation-group: read-onlyupdating: trueresultCache: trueatomicTx: trueidempotent: truecan-particpate-in-tx: truepattern: one-way | request-response

input-message {RequestNr : ct.Text[1:1]CreditCard : cc.CreditCard

}

output-message ValidateCardResponse {RequestNr : core.TextCreditCard : cc.CreditCard

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● Command line, soapUI, Maven plugin

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

WebService

Application Application

One-Way

Notification

Request/Response

Solicit Response

Standardized Service Data Models –Canonical Data Model

Source: Enterprise Integration Patterns (www.eaipatterns.com)

Standardized Service Data Models –Canonical Data Model

Service Usage Scope

Level of coupling

Typical WS-Attribute:

Granularity

Scope

Cross Organisational

Document or RPC style, LOBdata representations

Function call, RPC or RMIWithin Department

Inside Application

Tight Loose

Within Organization

Document style, industry standard data formats

Document style, enterprise data formats

SOA Logical Architecture – Service Categorization

Source: Oracle

Agenda

� Principles of Service Design� Service Design� Service Implementation� Service Versioning� Summary

a) PL/SQL in the database holds logicb) Java holds business logic, data access is implemented in

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

Mapper), no PL/SQL in database

Application CApplication 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

PL/SQL Implementation of Use Case

� PL/SQL Package specification

� Object types

Java Implementation for Use Case

� Customer Service Interface in Java

� Customer and Address DTO

� For B and C a Java Web Service Facade can be written� How can deploy existing PL/SQL logic as a Web Service ?

Application CApplication 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 Facade

Java Java

Service Interfacefor Use Case

JAX-WS – WSDL First

JAX-WS – WSDL First

Transformation

JAXB Annotations

JAX-WS Annotations

EJB Annotations

Java with JAX -WS - Code First

Determines XSD

Determines WSDL

Native Database Web Service (11g)

� A servlet in the database (DBWS) acts as a gateway to:● SQL Statements● XQuery● PL/SQL

Native Database Web Service (11g)

OSB adds a layer of indirection (virtualization)● Mediation: Transformation, Filtering, Enrichment, Routing● Adapter: supports integration of existing applications

OSB OSBOSB

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

MediationAdapter

Application A

Tables

PL/SQL

PL/SQL

Mediation

DB Servlet

SOA Platform

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

SQL

Demo: Database Adapter on OSB

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

TransportMediationAdapterSOA Platform

Application C

Tables

ORM

Java

Application B

Tables

PL/SQL

Java

Java

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● Provide it as a contract-first SOAP web service on OSB

SOAP Webservice

Transform from/to canonical model

OSB HTTP Transport to wrap JAX -WS Code First service

Proxy Service

XQuery Transformation

Business Service HTTP Transport

Transformation

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● Provide it as a contract-first SOAP web service on OSB

RMI / IIOP

Transaction propagation

OSB EJB Transport to call EJB

Proxy Service Business Service EJB Transport

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

SOAPlatform

MediationAdapter

Mediation Mediation

Orchestration

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● Nexus Maven Repository

Agenda


Service Versioning

� Services once deployed can never bechanged● Stable endpoints, don‘t necessarly know our

consumers

� WS-* specs haveno versioningconcept in place

The ripple effects of changes

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● Change to the second or subsequent digit

Implementing Versioning on ESB

Common Endpoint for all versions

One Endpoint per Major Version with Version in Message

One Endpoint per Major Version One Endpoint per Vers ion

Service Versioning

WSDL Version 1.0

Service Versioning

WSDL 1.1

Agenda


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● SLA Management and Monitoring

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 , Wednesday 8:30 – 9:30 Room 203C

Best Practices for Designing and Building the Services of an SOA

Please Fill Out Your Evaluations

Guido SchmutzTechnology Manager, Oracle ACE Director for FMW & SOATrivadis AG, Switzerland

Feedback-URL: http://ezsession.com/kscope

Documents

Best Practices for Designing and Building the Services of ... · PDF fileBest Practices for Designing and Building the ... This session will present best practices for designing and