Best Practices for Designing and Building the Services of an SOA

Best Practices for Designing and Building the Services of an SOA Guido Schmutz Technology Manager, Oracle ACE Director for FMW & SOA Trivadis 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_address]
Blog: http://guidoschmutz.wordpress.com
Twitter: gschmutz

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
~350 employees ~180 employees ~20 employees

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
Service Design
Service Implementation
Service Versioning
Summary

Development Approaches
Bottom up
Top Down
Meet in the middle (agile)
Bottom-Up DB Files Applications API Components Domain Produktion Verkauf F&E Rohstoffeingang Produktgenehmigung Service Service Service Service Service Service Top-Down

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 to graphically implement WSDL and XSD
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 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>

Alternative: UML with “WS profile”
Enterprise Architect has a special profile for WSDL and XSD modelling

CBDI-SAE UML Profile for SOA http://everware-cbdi.com Service Implementation Architecture Showing Services and Automation Units Business Type Model Showing Domains Service Deloyment Architecture Showing Deployments

Using DSL to simplify WSDL generation <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] } 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 }

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

Prototype based on Eclipse XText available

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

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
Web Service 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, 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

SOA Logical Architecture – Service Categorization Source: Oracle

Agenda
Service Design
Service Implementation
Service Versioning
Summary

PL/SQL in the database holds logic
Java holds business logic, data access is implemented in PL/SQL
Java holds business logic and data access (JDBC or O/R Mapper), no PL/SQL in database
What type of applications do we find today? Application C Application A 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 ?
Service-enable applications directly Application C Application A 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 Interface for 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
Service Enablement of DB logic using Oracle Service Bus (OSB) OSB OSB 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

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
Service Enablement of Java using Oracle Service Bus (OSB OSB 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

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

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
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 SOA Platform Mediation Adapter 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 Design
Service Versioning
Summary

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

Service Versioning
WSDL Version 1.0

Service Versioning
WSDL 1.1

Agenda
Service Design
Service Versioning
Summary

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 Schmutz Technology Manager, Oracle ACE Director for FMW & SOA Trivadis AG, Switzerland Feedback-URL: http://ezsession.com/kscope

http://fahmisatrio.blogspot.com	94
http://www.techgig.com	3
http://www.fahmisatrio.blogspot.com	2
http://fahmisatrio.blogspot.fr	1

Best Practices for Designing and Building the Services of an SOA

by Guido Schmutz

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 100

Statistics

Best Practices for Designing and Building the Services of an SOA Presentation Transcript