IBM's Approach to SOA Governance

  • View
    281

  • Download
    1

Embed Size (px)

DESCRIPTION

 

Text of IBM's Approach to SOA Governance

  • 1. This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena www.soasymposium.com info@soasymposium.comFounding Sponsors Platinum Sponsors Gold Sponsors Silver SponsorsSOA SymposiumOctober 7-8, 2008, AmsterdamImplementing Service Modelswith Java Andr Tost (andretost@us.ibm.com) Senior Technical Staff Member, SOA Technology IBM Software Services for WebSphere 2008 IBM Corporation1

2. SOA Symposium Agenda Service Models Utility Services Entity Services Task Services Service Composition Backup: Service Orientation Principles with Java WebServices If time permits Summary 3 Implementing Service Models in Java 2008 IBM Corporation SOA Symposium Intro (and shameless plug) The content of this presentation is extracted from content of the forthcoming book SOA in Java, which is part of the Prentice Hall Service-Oriented Computing Series from Thomas Erl It doesnt cover the entire book, but only content that is related to Service Models We assume that your implementation and deployment platform is Java Well, if this surprises you, you obviously didnt read the title of this presentation! We assume Java 5 We used Glassfish for creation of examples However, I will not show a lot of actual Java code. I expect you know how to write Java. We will focus on architectural and design aspects, testing, packaging considerations and other best practices.4 Implementing Service Models in Java 2008 IBM Corporation2 3. SOA Symposium Service Models 5Implementing Service Models in Java 2008 IBM CorporationSOA Symposium Service Models To give structure to our service-oriented environment, we create layers of functionality High level business processes are represented in the Process Layer Traditional IT systems are in the Application Layer The Service Interface Layer allows functionality from the Application Layer to beleveraged in the Process Layer The Service Interface Layer can be further decomposed into three layers Orchestration Service Layer Business Service Layer Application Service Layer All of these layers can be sorted into a service layer stack Shows dependencies and relationships between different parts of a solution These parts can be developed top-down, bottom-up, or both 6Implementing Service Models in Java 2008 IBM Corporation 3 4. SOA Symposium Service Models 7 Implementing Service Models in Java 2008 IBM Corporation SOA Symposium Service Models We can associate different service models with these layers Different types of services exist at different levels in the resulting stack All are part of the service portfolio for an enterprise Service models allow classifying and structuring service portfolio Utility Services In the Application Services layer Offer technical functionality Entity Services In the Business Services layer Offer access to data Task Services In the Business Services layer Represent activities within a business process We will not cover logic existing in the other layers in this session We will focus on aspects of developing these service models in Java8 Implementing Service Models in Java 2008 IBM Corporation4 5. SOA SymposiumService Models:Utility Services 9Implementing Service Models in Java 2008 IBM CorporationSOA Symposium Utility Services Architectural Considerations Utility Services are used by services in the Business Services layer Not the other way around They might be invoked from within an ESB, making them totally transparent to the Business Services They are usually not identified in the process and domain decomposition phase of theSOA analysis and design process Utility service identification is triggered by, for example: Non-functional requirements (NFR) Wrapping of existing non-SOA technology Existing Java standards 10 Implementing Service Models in Java 2008 IBM Corporation 5 6. SOA Symposium Utility Services Architectural Considerations Various ways exist for invoking UtilityServices Local versus remote Call-by-value versus call-by-reference Performance aspects Mainly through serialization Different serialization options exist XML, binary Concurrency aspects Multiple clients accessing the service implementation Must be thread safe Java EE application servers handle this automatically 11Implementing Service Models in Java 2008 IBM Corporation SOA Symposium Utility Services - Types Omni utility services Very generic in nature E.g. eventing, security, logging Typically use JAX-WS Provider Resource utility services Encapsulate resources like messaging, data, network, etc i.e. acts as faade Use existing standard Java APIs May want to add transfer objects to reduce chattiness Micro utility services Fine grained E.g. encryption/decryption, mathematical calculations, transformation Typically not accessed remotely No Web services Wrapper utility services Also called connector services or adapter services JCA is the prime standard leveraged by these services12Implementing Service Models in Java 2008 IBM Corporation6 7. SOA Symposium Utility Services Design and Implementation Utility Services are highly reusable across many business domains Should have generic interfaces XML: or Remote Java: java.io.Serializable, e.g. String Local Java: java.lang.Object Make sure implementation supports multi-threading Use synchronized where appropriate Avoid using instance-level state Use of Java editions Java SE supports several relevant APIs for Utility Services Security (JAAS), Management (JMX), Transformation (JAXP), Logging, Persistence (JDBC) Java EE adds an additional rich set of APIs that are relevant Messaging (JMS), Transformation (JAXB), Transactions (JTA), Registry (JNDI, JAXR), Legacy Integration(JCA) Leveraging EJB ensures high degree of autonomy and scalability Open Source Frameworks can help creating Utility Services Spring Hibernate Commons Logging 13 Implementing Service Models in Java 2008 IBM CorporationSOA Symposium Utility Services Design and Implementation Utility Services as Web Services Dont use as type for XML documents Will be encoded, thus increasing the size of the message Use instead JAX-WS supports provider style service implementation Implement javax.xml.ws.Provider No parsing or serialization XML message is directly passed to the implementation Use SAAJ to parse message content @ServiceMode(value=Service.Mode.MESSAGE) @WebServiceProvider() public class GenericProviderImpl implements javax.xml.ws.Provider { public SOAPMessage invoke(SOAPMessage message) {// read and process SOAPMessage... } } 14 Implementing Service Models in Java 2008 IBM Corporation7 8. SOA Symposium Utility Services Testing and Packaging Testing Use JUnit High degree of reuse requires thorough testing NFR may not always be known in advance Make services as autonomous as possible Packaging Java logic can be packaged in JAR, WAR or EAR Depends on the deployment environment Java EE or Java SE etc 15 Implementing Service Models in Java 2008 IBM CorporationSOA SymposiumService Models:Entity Services 16 Implementing Service Models in Java 2008 IBM Corporation 8 9. SOA Symposium Entity Services Architectural Considerations Entity Services are used by higher-level Task Services and Process Services Typically support an enterprise canonical model Addressing inconsistencies in data used across many applications One version of the truth Provide uniform view of domain-specific views of data Domain entities versus message entities Domain entities represent enterprise data model Message entities are driven by processes needs for information They are the information that flows between activitieswithin the process Offer a shallow view of the enterprise data Require Data Aggregation Encapsulated by the Implementation Must consider ownership 17Implementing Service Models in Java 2008 IBM Corporation SOA Symposium Entity Services Architectural Considerations Access mode Defines whether or not data is accessed exclusively Defines whether data can be accessed by other users/applications while it is being changed Service Data Objects offer disconnected data access in Java Data is retrieved by consumer for work No physical locks are held on the data source Changes are made within a separate transaction Conflicts can be resolved in different ways (raise exception, overwrite, etc) This is also called optimistic locking See http://www.osoa.org/display/Main/Service+Data+Objects+Specifications Change notifications Support notifying clients of updates made to data Not usually supported 18Implementing Service Models in Java 2008 IBM Corporation 9 10. SOA Symposium Entity Services Design and Implementation Do not expose underlying physical data model It may change Exposed is a view of the data driven by business needs Entity Services are stateless Use underlying technology to store the data No operations named load(), save(), etc Avoid technical terms in interface and operation names Should always be business relevant Avoid exposing implementation details (e.g. queryCustomerTable) Use existing persistence frameworks to map domain entities into Java JPA, EJB3 Hibernate Put message entities and domain entities into separate packages 19Implementing Service Models in Java 2008 IBM Corporation SOA Symposium Entity Services Design and Implementation Message entities can be viewed as shallow wrappers around domain entities Carry only the attributes that are relevant to the consumer Dont include full object graph For consumers with widely differing requirements for attributes, use generictypes For Java SE implementation, you can use JDBC But you must handle transactions, scrolling, partial loading, etc Better to use JPA It is the underlying mechanism for EJB3 Entity beans But it works in Java SE, too Also supported (and heavily influenced by) Hibernate For Java EE implementation, createstateless session bean as faadeover Entity beans 20Implementing Servi