IBM's Approach to SOA Governance

1

Founding Sponsors

This Presentation Courtesy of the

International SOA Symposium

October 7-8, 2008 Amsterdam Arena

www.soasymposium.com

[email protected]

Gold Sponsors

Platinum Sponsors

Silver Sponsors

© 2008 IBM Corporation

SOA Symposium

October 7-8, 2008, Amsterdam

Implementing Service Models with Java

André Tost ([email protected])

Senior Technical Staff Member, SOA TechnologyIBM Software Services for WebSphere

2

SOA Symposium

Implementing Service Models in Java © 2008 IBM Corporation3

Agenda

Service Models

– Utility Services

– Entity Services

– Task Services

Service Composition

Backup: Service Orientation Principles with Java Web Services

– If time permits

Summary

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 doesn‟t 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 didn‟t 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.

3

SOA Symposium


Service Models

SOA 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 be leveraged 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

4

SOA Symposium


Service Models

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 Java

5

SOA Symposium


Service Models:Utility Services

SOA 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 the SOA 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

6

SOA Symposium


Utility Services – Architectural Considerations

Various ways exist for invoking Utility Services

– 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

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 façade

– 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 services

7

SOA Symposium


Utility Services – Design and Implementation

Utility Services are highly reusable across many business domains

– Should have generic interfaces

– XML: <xsd:any/> or <xsd:anyType/>

– 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

– …

SOA Symposium


Utility Services – Design and Implementation

Utility Services as Web Services

– Don‟t use <xsd:string> as type for XML documents

– Will be encoded, thus increasing the size of the message

– Use <xsd:any/> 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<javax.xml.soap.SOAPMessage> {

public SOAPMessage invoke(SOAPMessage message) {

// read and process SOAPMessage...

}

}

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

SOA Symposium


Service Models:Entity Services

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 activities within the process

– Offer a “shallow” view of the enterprise data

Require Data Aggregation

– Encapsulated by the Implementation

– Must consider ownership

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

http://www.osoa.org/display/Main/Service+Data+Objects+Specifications

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

SOA Symposium



Message entities can be viewed as shallow wrappers around domain entities

– Carry only the attributes that are relevant to the consumer

– Don‟t include full object graph

For consumers with widely differing requirements for attributes, use generic types

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, create stateless session bean as façade over Entity beans

11

SOA Symposium



Entity Services are most likely always exposed as Web services

– High degree of reuse across business domains

– Single access point for information

Data model can start out as XML Schema or as Java

– Tooling (wsgen, wsimport, ….) can generate one from the other

– Full XML Schema set now supported by JAXB

Testing

– Entity services can be used in different contexts, all of which have to be tested

– Synchronous, “online”

– Asynchronous, “batch”

– High degree of concurrency

– Test optimistic locking

– Performance-critical

– Especially when aggregating from multiple sources

Packaging

– Domain entities and message entities go into different packages

– Put domain entities into Utility JAR for reuse

– In Java EE, one enterprise application per Entity service

SOA Symposium


Service Models:Task Services

12

SOA Symposium


Task Services – Architectural Considerations

Task Services stem from decomposition of business processes into activities

– Often domain-specific or even process-specific

– Less reusable

“Top-down” design

They often use Entity Services

– Entity Services are often “bottom-up”

Contain pure business logic

– Technology agnostic

Act as controllers

– Expose coarse grained interface

– Invoke finer grained (Entity) service interfaces

– Might be co-located with these services to improve performance

SOA Symposium


Task Services – Architectural Considerations

Task service versus Process service

– Task service invokes a sequence of lower level services

– In plain Java

– A task service represents an activity within a business process

– The business process is implemented as an orchestration, using a higher level of abstraction, like WS-BPEL

– Task services are short running, process services are long running

– Task services have no human interaction

Task services are stateless

– But they may have to retain state across invocations of aggregated services

– Can usually use local heap space

13

SOA Symposium


Task Services – Design and Implementation

Task service identification through process decomposition often leads to one operation per service

Try to group similar operations and reduce number of distinct services

– Services are governed, maintained and versioned as a unit

Use namespaces as a way to distinguish between services in different layers

Messages are specific to the context of the business process

– May not always follow canonical model

Implementation has to catch exceptions and error conditions from lower level technology and translate them into business level faults

– Pay as much attention to modeling faults as to modeling the rest of the messages

Implementation should not directly use low level Java APIs

– Should use Entity and Utility services

– For example, do not use JavaMail, use the “Email” service

– Might lead to the need for additional services

SOA Symposium


Task Services – Design and Implementation

Implementation as stateless session EJB allows access from a variety of clients

– Note that WS clients do not automatically carry context, like an EJB client does

– Security, transactions

– Might have to leverage advanced WS-* specifications

Task services have many dependencies on other services

– Challenging for unit testing

– Create stubs for all invoked services

– Might want to replace service proxies with local objects

14

SOA Symposium


Service Composition

SOA Symposium


Service Composition – Terminology

Service Composition (or Aggregation) means that a service invokes other, existing services to implement its logic

The ability of services to be composed into a new service is one of the core principles of SOA

– Allows building solutions quickly

– Allows adapting existing solutions to new market demands quickly

In our definition, Composition is different than Orchestration

– Orchestration is one way of composing services among others

– Orchestration is often done to implement a business process

– Orchestration often uses BPEL

– We will focus on Java-based composition here

15

SOA Symposium


Service Composition - Terminology

Services play different roles in compositions

Composition Controller invokes other services

– Controller acts as „parent‟

– May have to store state across invocations

– Utilizes different message exchange patterns for invocations

Composition Member is invoked as part of a composition

– Member acts as „child‟

– Completely decoupled from controller‟s consumer

– Can be controller for its own composition

– Called “sub-controllers”

SOA Symposium


Service Composition and Service Models

Task Services are typical Composition Controllers

– Can be members, too

Task Services are typical Composition Sub-controllers

Entity Services are typical Composition Members

– Can be controllers, too

Utility Services are Composition Members

16

SOA Symposium


Service Composition – Design and Implementation

Members are not aware of their controllers

– This would create an unwanted degree of coupling

Controllers are aware of their members, of course

– Identifying suitable members is part of the design process for a service

Usage of a service as a composition member must be subject to appropriate governance processes

– SLAs must be put in place

Used protocols imply certain Qualities of Service

– HTTP is not reliable

– JMS supports transactional message delivery

May require support for additional standards

– WS-ReliableMessaging

– WS-AtomicTransaction

– These are supported by the underlying runtime and do not have any impact on the service logic

SOA Symposium


Service Composition – Design and Implementation

Endpoint lookup

– Composition member endpoints should not be hardcoded into the controller

– javax.xml.ws.Service interface offers various ways of resolving this at runtime

– addPort() creates a new port with new address

– create() creates a Service instance from existing WSDL (including endpoint address)

– Use createDispatch() method to implement completely dynamic invocation

– Addresses should be looked up in a registry

– Controller should cache member endpoint addresses

Error handling

– Controllers should not copy all Fault messages from members into its own contract

– Again, unwanted coupling and exposure of implementation details

– Catch all exceptions in downstream invocations and convert to exceptions that are appropriate to the functional context of the controller

– Including “unmodeled” faults, i.e. RuntimeException or WebServiceException (JAX-WS)

– i.e. avoid relying on unmodeled fault handling

– Propagates implementation details to consumer that it cannot handle

Tracing

– Add „correlators‟ to each message to allow identifying it across member invocations

– Do not make this part of the service contract

– Use JAX-WS handlers instead

17

SOA Symposium


Service Composition - Packaging

If members are Web services, use wsimport to generate client packages for each composition member

– Creates required utility classes and interfaces

– Can easily be packaged into a utility JAR file

If members are Java EE services (i.e. remote EJB), use client EJB bindings

– Can also be packaged as utility JAR file

– Use annotations in implementation logic to reference remote EJB

Package utility JAR files with EAR for composition controller

Very fine grained composition members (Utility services) may directly be included with controller logic

– Cannot be called efficiently over a network

– Creates a coupling between controller and member, e.g. member implementation cannot be changed without impacting the controller

SOA Symposium


Summary

18

SOA Symposium


Summary

Service Models allow structuring services into different categories, according to their characteristics

– Utility Services are highly reusable, often technical in nature

– Entity Services offer consistent access to data, are also reusable

– Task Services represent activities within a business process, coarse grained, less reusable

Java and especially Java EE offer predefined APIs and mechanisms to implement these services

– JAXB to describe XML-based data

– JAX-WS has a statically defined and a generic programming model to provide and invoke Web services

– Many lower level APIs for Utility Services, e.g. JavaMail

– JDBC, JPA and EJB3 for Entity Services

Composition is a core capability of SOA

– Includes orchestration, which is done in BPEL

– Introduces new roles: composition controller and composition member

– Different Service Models apply to different composition roles

SOA Symposium


Thank YouMerci

Grazie

Gracias

Obrigado

Danke

Japanese

English

French

Russian

GermanItalian

Spanish

Brazilian PortugueseArabic

Traditional Chinese

Simplified Chinese

Thai

19

SOA Symposium


Backup:Service-Orientation Principles withJava Web Services

SOA Symposium


Service-Orientation Principles with Java Web Services

Service Reusability

– Agnostic functional context

– Highly generic service logic

– Generic and extensible contract

– Concurrent access to service logic

Standardized Service Contract Design

– Top-down versus bottom-up design

– Java2WSDL and WSDL2Java mapping

– Use of industry standards

Service Loose Coupling

– Separation of contract and implementation

– Functional context with no dependency on outside

– Minimal requirements for consumer

Service Abstraction

– Abstracting technology details

– Hiding service details

– Document constraints

20

SOA Symposium


Service-Orientation Principles with Java Web Services

Service Composability

– Composition of members versus composition of controllers

– Highly efficient runtime environment

– Flexible service contract

– Standards-based runtime

Service Autonomy

– Well-defined functional boundary

– Control over runtime environment

– High concurrency

Service Statelessness

Service Discoverability

– Design time discoverability

– Runtime discoverability

– Service registries

Documents

IBM's Approach to SOA Governance