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: guido.schmutz@trivadis.com 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. ~180 employees 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 ~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 managementfree 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) Top-Down Domain Produktio n Verkauf F&E Rohstoffeingang Produktgenehmigung Service Service Service Service Service Service Bottom-Up Files API DB Components Applications
Contract-First Web Service Design Important for serviceorientation 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 autogeneration 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"> <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"> <wsdl:part name="request" <xs:element name="creditcard" type="tns:creditcardt"/> element="tns:validatecreditcardpaymentrequest"/> <xs:complextype name="creditcardt"> </wsdl:message> <xs:sequence> <wsdl:message name="validatecardresponse"> <xs:element name="creditcardkind" <wsdl:part name="reply" type="tns:creditcardkindt"/> element="tns:validatecreditcardpaymentresponse"/> <xs:element name="cardnumber" type="xs:string"/> </wsdl:message> <xs:element name="cardholderfirstname" <wsdl:message name="invalidcreditcardnumberfault"> type="xs:string" minoccurs="0"/> <wsdl:part name="error <xs:element name="cardholderlastname" type="xs:string"/> element="tns:invalidcreditcardnumberfault"/> <xs:element name="expirationmonth" </wsdl:message> type="tns:montht"/> <wsdl:porttype name="creditcardvalidationpt"> <xs:element name="expirationyear" <wsdl:operation name="validatecard"> type="tns:yeart"/> <wsdl:input message="tns:validatecardrequest"/> </xs:sequence> <wsdl:output message="tns:validatecardresponse"/> <xs:attribute name="id" type="xs:int"/> <wsdl:fault name="invalidcreditcardnumberfault" </xs:complextype> message="tns:invalidcreditcardnumberfault"/> <xs:simpletype name="creditcardkindt"> </wsdl:operation> </wsdl:porttype> <wsdl:binding...> <wsdl:service...> </wsdl:definitions> <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» CBDI-SAE UML Profile for SOA Customer Relations «Business Type» Customer + number: {id1} + name + billingaddress 0..* + lastyearshipmentsvalue + lastqtrshipmentsvalue + thisqtrshipmentsvalue + contactname1 + contactname2 1 1 1 1 {id1} {id1} Service Deloyment Architecture Showing Deployments «Endpoint» :Customers «Deploy» «Node» Technology Model::alpha :Sun Server «executionenvironment... :SOAP Engine (from Technology Model) «Endpoint Implementation» «Communication Path» «Node» Technology Model::beta :Sun Serv er «executionenvironment... :EJB Container «Communication Path» «Automation Unit» Implementation Model:: Customers «manifest» «Deployed AU» :Customers «Deploy» (from Technology Model) «instanceof» «instanceof» «Deploy» «Deploy» «Service Instance» cust01 :Customers Application Process «Service Instance» cust02 :Customers Utility Core Business «Required Behavior» «Technical Interface» Subcontractors «Automation Unit» Shipping Objects «Automation Unit» Prov iderx «Technical Interface» Schedule Pickup «Automation U... Schedule Pickup «Required Behavior» «Required Behavior» «Required Behavior» «Technical Interface» Shipments «Required Behavior» «Technical Interface» Warehouses «Required Behavior» Suppliers «Required Behavior» «Technical Interface» «Required Behavior» «Technical Interface» AddressFormatter Shipping Warehouse «Business Type» Vehicle is base for + name: {id2} + registrationnbr: {id2} + number: {id1} 1 * + manufacturer + address + model + capacity + capacity + fleetnbr requests {id1} * 1 «Business Type» visited on {id1} Subcontractor Parcels System makes houses + name: {id1} * + address + performancerating * «Business Type» + ouraccountnbr 1..* Journey «Required Behavior» «Required Behavior» 1 + date: {id1} «Business Type» {id1} + number: {id1} Warehouse Position + routecode holds + isscheduled + number: {id1} shipments + description at 0..1 0..1 * + typecode «Technical Interface» «Technical Interface» currently Pickup and Deliver currently conveying «Business Type» Obtain Payment stores Subcontractor Location 1 1..* «Automation Unit» + shortname 0..1 «Automation U... currently holds «Business Type» * Pickup and Deliver + address Obtain Payment * Shipment «Required Behavior» Customers «Automation Unit» Customers «Required Behavior» «Required Behavior» «Required Behavior» «Business Type» Handling Procedure «Required Behavior» + parceltype: string + definition: string + procedure: string + constraints: sting + tagnbr: {id1} * + destinationaddress + weight + dimension + specialneeds defines procedures for + destinationinstructions * * + charge + contentdescription «Technical Interface» Inv oices «Automation Unit» Inv oices «Business Type» HazardousShipment «Required Behavior» «Required Behavior» «Technical Interface» Accounts «Automation Unit» Accounts «Required Behavior» «Required Behavior» 1 ships from «Business Type» Pick Up Point + shortname: {id1} + address + guidance 1 origin for «Business Type» FoodShipment 1..* receives paid for by makes 0..1 0..1 * «Business Type» Inv oice + number: {id1} + issuedate + totalamount + status + discountgiven «Business Type» Invoice Item + number: {id1} + description + charge Finance «Business Type» Payment + date: {id1} + amount: {id1} 0..1 * owns {id1} * contains in response to recorded in 0..1 0..1 1 1 «Business Type» Account + number: {id1} + name + openingdate + balance recorded in 1 * {id1} contains «Business Type» Account Entry + sequencenbr: {id1} + amount + isdebit + reference + date Business Type Model Showing Domains «Node» Technology Model::r01 : Router Underlying «Automation Unit» Customer Relationships Transactions «Technical Interface» Inv oicing «Technical Interface» «Automation Unit» Accounting System «Technical Interface» New Accounts Service Implementation Architecture Showing Services and Automation Units http://everware-cbdi.com
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 Notification Application Web Service Request/Response Solicit Response One-Way Application 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
Standardized Service Data Models Canonical Data Model Source: Enterprise Integration Patterns (www.eaipatterns.com)
Standardized Service Data Models Canonical Data Model
Service Usage Scope Scope Typical WS-Attribute: Cross Organisational Within Organization Within Department Document style, industry standard data formats Document style, enterprise data formats Document or RPC style, LOB data representations Function call, RPC or RMI Inside Application Granularity Tight Level of coupling Loose
SOA Logical Architecture Service Categorization Source: Oracle
Agenda Principles of Service Design Service Design Service Implementation Service Versioning Summary
What type of applications do we find today? 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 A Application B Application C Business Logic PL/SQL Java Java Data Access PL/SQL PL/SQL ORM Storage Tables Tables Tables
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
Service-enable applications directly For B and C a Java Web Service Facade can be written How can deploy existing PL/SQL logic as a Web Service? Application A Application B Application C Web Service Facade???? Java Java Business Logic PL/SQL Java Java Data Access PL/SQL PL/SQL ORM Resource Tables Tables Tables
Service Interface for Use Case
JAX-WS WSDL First
JAX-WS WSDL First JAX-WS Annotations JAXB Annotations EJB Annotations Transformation
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)
Service Enablement of DB logic using Oracle Service Bus (OSB) OSB adds a layer of indirection (virtualization) Mediation: Transformation, Filtering, Enrichment, Routing Adapter: supports integration of existing applications OSB OSB OSB SOA Platform Mediation Mediation Adapter Mediation Adapter Application A Application A Application A Web Service Facade DB Servlet Business Logic PL/SQL PL/SQL Data Access PL/SQL PL/SQL Resource Tables Tables Tables
OSB and DB Adapter for requestdriven 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
Service Enablement of Java using Oracle Service Bus (OSB OSB adds a layer of indirection (virtualization) Mediation: Transformation, Filtering, Enrichment, Routing Adapter: supports integration of existing applications SOA Platform OSB Mediation Transport OSB Mediation Adapter Web Service Facade Business Logic Application B Java Java Application C Java Data Access PL/SQL ORM Resource Tables Tables
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 Transform from/to canonical model SOAP Webservice
OSB HTTP Transport to wrap JAX- WS Code First service Proxy Service Business Service HTTP Transport XQuery Transformation 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 BPEL and BPMN Orchestration SOA Platform Mediation Adapter OSB Mediation Mediation Application A Application B Application C Web Service Facade Java Java Business Logic PL/SQL Java Java Data Access PL/SQL PL/SQL ORM Resource Tables Tables Tables
Automatic Build & Deployment Goals Tools Automate everything WLS Domain creation Schema repository creation OSB & SOA artifacts build & deployment soapui integration testing Hudson Integration Continuous Integration Hudson Maven soapui Subversion Nexus Maven Repository
Agenda Principles of Service Design Service Design Service Model and Implementation 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 Principles of Service Design Service Design Service Model and Implementation 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