• Save
Best Practices for Designing and Building the Services of an SOA
Upcoming SlideShare
Loading in...5
×
 

Best Practices for Designing and Building the Services of an SOA

on

  • 1,993 views

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

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.

Statistics

Views

Total Views
1,993
Views on SlideShare
1,882
Embed Views
111

Actions

Likes
6
Downloads
0
Comments
0

6 Embeds 111

http://fahmisatrio.blogspot.com 100
http://www.linkedin.com 4
http://www.techgig.com 3
http://www.fahmisatrio.blogspot.com 2
http://fahmisatrio.blogspot.fr 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • This is your opening slide.
  • Use this template for all your content slides. There are also other layout slides you can feel free to use.
  • Use this template for all your content slides. There are also other layout slides you can feel free to use.
  • Use this template for all your content slides. There are also other layout slides you can feel free to use.
  • Use this template for all your content slides. There are also other layout slides you can feel free to use.
  • Use this template for all your content slides. There are also other layout slides you can feel free to use.
  • This is the final slide of the presentation.

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

  • 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
    • Principles of Service Design
    • 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=&quot;http://trivadis.com/service/credit-card/v1&quot; ... name=&quot;CreditCardValidation-v1&quot;> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name=&quot;validateCardRequest&quot;> <wsdl:part name=&quot;request&quot; element=&quot;tns:validateCreditCardPaymentRequest&quot;/> </wsdl:message> <wsdl:message name=&quot;validateCardResponse&quot;> <wsdl:part name=&quot;reply&quot; element=&quot;tns:validateCreditCardPaymentResponse&quot;/> </wsdl:message> <wsdl:message name=&quot;invalidCreditCardNumberFault&quot;> <wsdl:part name=&quot;error„ element=&quot;tns:invalidCreditCardNumberFault&quot;/> </wsdl:message> <wsdl:portType name=&quot;CreditCardValidationPT&quot;> <wsdl:operation name=&quot;validateCard&quot;> <wsdl:input message=&quot;tns:validateCardRequest&quot;/> <wsdl:output message=&quot;tns:validateCardResponse&quot;/> <wsdl:fault name=&quot;InvalidCreditCardNumberFault&quot; message=&quot;tns:invalidCreditCardNumberFault&quot;/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...> </wsdl:definitions> <xs:schema xmlns:xs=„...&quot; xmlns:tns=&quot;http://www.trivadis.com/cdm/credit-card/v1&quot; targetNamespace= „http://www.trivadis.com/cdm/credit-card/v1 “ elementFormDefault=&quot;qualified&quot; attributeFormDefault=&quot;unqualified&quot; version=&quot;1.0&quot;> <xs:element name=&quot;creditCard&quot; type=&quot;tns:CreditCardT&quot;/> <xs:complexType name=&quot;CreditCardT&quot;> <xs:sequence> <xs:element name=&quot;creditCardKind&quot; type=&quot;tns:CreditCardKindT&quot;/> <xs:element name=&quot;cardNumber&quot; type=&quot;xs:string&quot;/> <xs:element name=&quot;cardholderFirstName&quot; type=&quot;xs:string&quot; minOccurs=&quot;0&quot;/> <xs:element name=&quot;cardholderLastName&quot; type=&quot;xs:string&quot;/> <xs:element name=&quot;expirationMonth&quot; type=&quot;tns:MonthT&quot;/> <xs:element name=&quot;expirationYear&quot; type=&quot;tns:YearT&quot;/> </xs:sequence> <xs:attribute name=&quot;id&quot; type=&quot;xs:int&quot;/> </xs:complexType> <xs:simpleType name=&quot;CreditCardKindT&quot;> <xs:restriction base=&quot;xs:string&quot;> <xs:enumeration value=&quot;visa&quot;/> <xs:enumeration value=&quot;mastercard&quot;/> <xs:enumeration value=&quot;amexco&quot;/> </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=&quot;http://trivadis.com/service/credit-card/v1&quot; ... name=&quot;CreditCardValidation-v1&quot;> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name=&quot;validateCardRequest&quot;> <wsdl:part name=&quot;request&quot; element=&quot;tns:validateCreditCardPaymentRequest&quot;/> </wsdl:message> <wsdl:message name=&quot;validateCardResponse&quot;> <wsdl:part name=&quot;reply&quot; element=&quot;tns:validateCreditCardPaymentResponse&quot;/> </wsdl:message> <wsdl:message name=&quot;invalidCreditCardNumberFault&quot;> <wsdl:part name=&quot;error„ element=&quot;tns:invalidCreditCardNumberFault&quot;/> </wsdl:message> <wsdl:portType name=&quot;CreditCardValidationPT&quot;> <wsdl:operation name=&quot;validateCard&quot;> <wsdl:input message=&quot;tns:validateCardRequest&quot;/> <wsdl:output message=&quot;tns:validateCardResponse&quot;/> <wsdl:fault name=&quot;InvalidCreditCardNumberFault&quot; message=&quot;tns:invalidCreditCardNumberFault&quot;/> </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
    • Principles of Service Design
    • 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
      • 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 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
    • 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