1. This Presentation Courtesy of the
International SOA Symposium
October 7-8, 2008 Amsterdam Arena
www.soasymposium.com
info@soasymposium.com
Founding Sponsors
Platinum Sponsors
Gold Sponsors Silver Sponsors
SOA Symposium
October 7-8, 2008, Amsterdam
Implementing Service Models
with Java
André Tost (andretost@us.ibm.com)
Senior Technical Staff Member, SOA Technology
IBM Software Services for WebSphere
© 2008 IBM Corporation
1

2. SOA Symposium
Agenda
 Service Models
– Utility Services
– Entity Services
– Task Services
 Service Composition
 Backup: Service Orientation Principles with Java Web
Services
– 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 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.
4 Implementing Service Models in Java © 2008 IBM Corporation
2

3. SOA Symposium
Service Models
5 Implementing Service Models in Java © 2008 IBM Corporation
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
6 Implementing 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 Java
8 Implementing Service Models in Java © 2008 IBM Corporation
4

5. SOA Symposium
Service Models:
Utility Services
9 Implementing Service Models in Java © 2008 IBM Corporation
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
10 Implementing Service Models in Java © 2008 IBM Corporation
5

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
11 Implementing 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 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
12 Implementing Service Models in Java © 2008 IBM Corporation
6

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
– …
13 Implementing Service Models in Java © 2008 IBM Corporation
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...
}
}
14 Implementing Service Models in Java © 2008 IBM Corporation
7

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 Corporation
SOA Symposium
Service 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 activities
within the process
– Offer a “shallow” view of the enterprise data
 Require Data Aggregation
– Encapsulated by the Implementation
– Must consider ownership
17 Implementing 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
18 Implementing 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
19 Implementing 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
– 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
20 Implementing Service Models in Java © 2008 IBM Corporation
10

11. SOA Symposium
Entity Services – Design and Implementation
 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
21 Implementing Service Models in Java © 2008 IBM Corporation
SOA Symposium
Service Models:
Task Services
22 Implementing Service Models in Java © 2008 IBM Corporation
11

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
23 Implementing Service Models in Java © 2008 IBM Corporation
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
24 Implementing Service Models in Java © 2008 IBM Corporation
12

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
25 Implementing Service Models in Java © 2008 IBM Corporation
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
26 Implementing Service Models in Java © 2008 IBM Corporation
13

14. SOA Symposium
Service Composition
27 Implementing Service Models in Java © 2008 IBM Corporation
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
28 Implementing Service Models in Java © 2008 IBM Corporation
14

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”
29 Implementing Service Models in Java © 2008 IBM Corporation
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
30 Implementing Service Models in Java © 2008 IBM Corporation
15

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
31 Implementing Service Models in Java © 2008 IBM Corporation
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
32 Implementing Service Models in Java © 2008 IBM Corporation
16

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
33 Implementing Service Models in Java © 2008 IBM Corporation
SOA Symposium
Summary
34 Implementing Service Models in Java © 2008 IBM Corporation
17

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
35 Implementing Service Models in Java © 2008 IBM Corporation
SOA Symposium
Thai
Traditional Chinese
Russian
Gracias Spanish
Thank English
You Merci
French
Obrigado
Brazilian Portuguese
Arabic
Grazie Danke
Italian German
Simplified Chinese
Japanese
36
36 Implementing Service Models in Java © 2008 IBM Corporation
18

19. SOA Symposium
Backup:
Service-Orientation
Principles with
Java Web Services
37 Implementing Service Models in Java © 2008 IBM Corporation
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
38 Implementing Service Models in Java © 2008 IBM Corporation
19

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
39 Implementing Service Models in Java © 2008 IBM Corporation
20