Design Principles For Process-Driven Architectures Using Oracle BPM and SOA Suite 12c - Sample Chapter
Design Principles For Process-Driven Architectures Using Oracle BPM and SOA Suite 12c - Sample Chapter
P U B L I S H I N G
Hajo Normann
Mark Simpson
$ 69.99 US
45.99 UK
Sa
pl
e
P r o f e s s i o n a l
Sven Bernhardt
Guido Schmutz
Matjaz B. Juric
Danilo Schmiedel
Torsten Winterberg
ee
E x p e r t i s e
D i s t i l l e d
Matjaz B. Juric
Danilo Schmiedel
Torsten Winterberg
Sven Bernhardt
Guido Schmutz
Hajo Normann
Mark Simpson
P U B L I S H I N G
Hajo Normann works at Accenture in the role of an SOA and BPM's community of
practice lead in ASG. Hajo is responsible for the architecture and solution design of
SOA/BPM projects, mostly acting as the interface between the business and IT sides.
He enjoys tackling organizational and technical challenges and motivates solutions
in customer workshops, conferences, and publications. Hajo, together with Torsten
Winterberg, leads the DOAG SIG Middleware; is an Oracle ACE Director; and is
an active member of the global network within Accenture. Hajo is also in regular
contact with SOA/BPM architects from around the world.
Danilo Schmiedel follows his passion to deliver SOA and BPM solutions based
on new technologies and trends. He is one of the leading BPM and SOA architects
at OPITZ CONSULTING Deutschland GmbHa German Oracle Platinum Partner.
He is involved in large integrations, business process automations, and BPM/SOA
development projects, where he has implemented well-accepted solutions for
various customers. Danilo is an Oracle Director (ACE is short for Acknowledged
Community Expert); frequent speaker at IT conferences; and author of numerous
articles in various technical journals. Before joining OPITZ CONSULTING, he
worked as a software engineer in several international projects. The Leipzig
University of Applied Science awarded his outstanding work in 2009.
Guido Schmutz works for Trivadis, an Oracle Platinum Partner. He has more
than 25 years of technology experience, including mainframes, integration, and
SOA technologies in financial services, government, and logistics environments. At
Trivadis, he is responsible for innovation in the areas of SOA, BPM, and application
integration solutions and leads the Trivadis Architecture Board. He has longtime
experience as a developer, coach, trainer, and architect in the areas of building
complex Java EE and SOA-based solutions. Currently, he is focusing on the design
and implementation of SOA and BPM projects using the Oracle SOA stack. A few
other areas of interest for Guido are big data and fast data solutions and how to
combine these emerging technologies into a modern information and software
architecture. Guido is an Oracle ACE Director for Fusion Middleware and SOA and
a regular speaker at international conferences, such as Oracle Open World, ODTUG,
SOA & Cloud Symposium, UKOUG conference, and DOAG. He is also a coauthor
of Oracle Service Bus 11g Development Cookbook, Do More with SOA Integration: Best
of Packt, Service-Oriented Architecture: An Integration Blueprint, Spring 2.0 im Einsatz,
Architecture Blueprints, and Integration Architecture Blueprint.
Preface
The implementation and optimization of business processes have become high
priorities for most enterprises. However, experience has shown that there is a huge
gap between the implementation of a single business process and the definition of
an enterprise-wide process-driven architecture that will be able to accommodate
business processes over time, while ensuring the benefits of concepts and best
practices, including reusability, loose coupling, flexibility, discoverability, and so on.
Experience has shown that only projects based on key design principles and best
practices are successful. This book presents the key design principles for process
architectures in a practical way via examples, using Oracle BPM and SOA Suite 12c.
This book is a design handbook. It provides you with the skills to successfully
design, implement, and optimize business processes on top of SOA. Starting with
business process modeling, it shows design principles to architect sound process
architectures. It presents best practices to model business processes using BPMN,
together with design principles to design and implement services (SOAP and REST)
and extending through to composite applications.
It provides a detailed coverage of how to prepare business processes in BPMN
for execution purposes on process servers and when to use BPEL. An in-depth
explanation of human interactions is given, including different patterns, escalations,
renewals, and other important concepts.
Business rules are covered, including principles and best practices to use rules in
BPMN and BPEL processes. For scenarios where classical human interactions and
rules are not sufficient, the book explains Adaptive Case Management.
Extending the reach of business processes to mobile devices and ensuring
multichannel and omnichannel interactions are covered and explained.
Preface
Preface
Preface
Chapter 6, Process Execution with BPMN and BPEL, outlines a set of guidelines to actually
implement business processes and the associated services. This chapter describes how
to define an implementation roadmap, explains how to implement the Service Facade
and Delegation patterns in BPEL, discusses the right level of variances, highlights
the degrees of coupling between technical components, and sets out a series of best
practices, for example, naming conventions for composite partitions.
Chapter 7, Human Interaction with Business Processes, explains in depth what the
integration of human actors means for process-driven applications, especially
about the challenges from an architectural, conceptual, and technical perspective.
Considerations with reference to UI design principles and user experience during
development of user-centric processes and the corresponding inbox applications are
discussed. The impact of the task-based approach on end users is also considered.
Chapter 8, Business Rules, outlines how a transparent enterprise decision management
can be supported by IT by automating business decisions. It describes the
characteristics of business rules and their relation with BPM; explains how to identify
and assess business rules, that is, business rules candidates; discusses how to design,
organize, and implement business rules; and depicts the Oracle Business Rules
design time as well as the runtime architecture and its concepts. Finally, it discusses
best practice approaches to implement business rules.
Chapter 9, Adaptive Case Management, gives all the overview information that is
needed to fully understand the ideas behind ACM. It explains the characteristics of
ACM, its relation to business analytics, shows how to model a case, how to build
your own UI on top, and presents best practices.
Chapter 10, Mobile and Multichannel, explains the integration of mobile and BPM,
provides best practices to design the architecture to enable multichannel access, accesses
human tasks and BAM from mobile, and explains best practices for multichannel.
Chapter 11, Event Processing and BPM, explains what event processing is, why it is of
interest to combine it with BPM, and how this can be achieved. It answers questions
such as what is fast data and what is event processing, explains key elements of
event processing and the different types of event processing, and compares event
processing with Business Rule Management Systems (BRMS). It provides conceptual
architecture for event processing and explains how event processing fits into a
modern architecture.
Preface
Chapter 12, Business Activity Monitoring, shows how Business Activity Monitoring
(BAM) can help an organization gain insight into business operations and outcomes
in real time, thus enabling optimization, efficiency gain, and ongoing improvement
to the business processes. This chapter defines the capabilities that a BAM platform
should provide and the different types of insights that it delivers. It clarifies the
difference between BAM and traditional Data Warehouse-based reporting solutions
and describes how BAM integrates into SOA and BPM to monitor business processes
and services in real time. It also presents a methodology and best practices to design
and build BAM dashboards and the supporting data objects.
Process-driven
Service Design
Service-oriented architecture (SOA) is a fundamental building block of a successful
business process-driven architecture. To build agility and business alignment into
our processes, we must ensure that the functionality that the processes implement is
also designed in an agile, modular, and business-aligned fashion.
The IT architectures of many organizations have grown in an organic way through
the adoption of new packaged applications (both commodity applications and
industry-specific applications), custom-built applications in areas of differentiation,
and hosted partner or cloud services. Integration of these systems becomes an
increasing challenge with the divergence of the definition of business terms,
technical protocols, and location of the systems. Whether these systems provide
key engagement with customers, partners, and employees or are just a system of
record, they are still required to interact with the organization's business processes.
To give the business the control over the process that they require, the functions as
well as the processes themselves can no longer be embedded within the systems.
This becomes increasingly important as processes cross boundaries of ownership,
for example, across organizational silos, partner organizations, and devices (mobile,
tablet, desktop, and so on).
[ 99 ]
To ensure that business processes are not constrained by the IT architecture that
supports them, a further layer of business functions must be provided for the
business processes to interact withone that speaks the business language, can
interact in a consistent way with all the organizations or partner IT systems, and
can provide information, actions, and functions across multiple devices. This is the
role of the SOA layer. In this role, SOA is more than just a set of standards to allow
systems to interoperate; it is a design approach that, if implemented correctly, will be
a key enabler to a process-driven architecture. The design of the service layer must
ensure that the change in IT systems has limited impact on the process layer and
that business change can be facilitated by the IT systems with similar limited impact.
One of the key drivers of BPM is to accelerate business change without too much IT
involvement; this is only possible with the correct service architecture and approach
in place.
If business process change requires constant IT refactoring of the
services and functions that implement the process, then it will
never truly deliver the business agility desired.
This chapter will outline an approach and a set of guidelines to design your services
in such a way that they facilitate usage by the business process layer. We will do
the following:
Discuss what should come first: the business process design, service design,
or data design
Chapter 4
Consistency in data: SOA allows the enterprise to share data, information, and
knowledge more readily through open standards and common protocols. SOA
supports more effective communication both within an enterprise and between
an organization and its supply chain since communications are not hampered
by incompatible systems. This helps us to implement processes that cut across
data domains and organizational boundaries.
[ 101 ]
Support and maintenance: A good service design will reduce the overhead
in supporting and maintaining business processes. It allows the business
process to track the steps the business is performing and reporting on and
does not dilute that layer with technical and functional details. With a more
direct integration approach, it becomes difficult to trace the downstream
impact of process steps, issues take longer to resolve, and they involve more
teams, thus becoming a costly task.
Chapter 4
A service should be defined based on its external value and not its internal
implementation. This is why services suit BPM so wellthe business process
can concentrate on the outcomes of the service rather than its implementation.
The service contract does not just define the interchange of data, but also its
runtime behavior, activities, and outcomes. A service contract expresses how
interface and data types are defined, and any policies and quality-of-service
factors are attached to the service, but the contract also must communicate
the outcomes expected when invoking these services. That is why a WSDL
itself is often not enough to define the behavioral contract of a servicethis is
where a specification of the services and associated service tests come to the
fore. Service tests are a crucial part of a well-defined service architecture and
build up the trust that is required when reuse is promoted. A process analyst
will be more inclined to leverage and reuse existing services if they can run
simple service tests to validate that a service will give the outcomes required
in the process they are defining.
The focus within the service design stage of any process implementation
is to ensure that the service contracts are optimized at the correct level of
granularity for the business processes and standardized to ensure services
are consistent, reliable, and governable.
[ 104 ]
Chapter 4
The prevalence of SOA and standardized APIs also means that designers
no longer reinvent everything from scratch. The first step now is always to
try to find existing chunks of functionality that can be composed to meet
new requirements. However, the state of the existing implementation will
need to be verified to ensure that it meets quality criteria, and that it is in a
technology that is not currently scheduled for retirement.
Service granularity
Services can be either coarse-grained or fine-grained. A coarse-grained service
performs a big task. To achieve the same outcome, the alternative would be multiple
fine-grained services (with a thin layer of logic to link these invocations together).
The first factor that drives the choice of granularity is why that service is being
made available. If the service is being made available to remote consumers (trading
partners or one of your international data centers), then a coarser granularity will
reduce the time spent on network latency and hence improve overall performance. If
the service is for local consumption, then finer-grained services are more preferable.
By splitting a service into smaller subservices, you increase the likelihood of services
being reused. Also, you reduce coupling (the consumer doesn't have to deal with
parameters that aren't needed in the one bit of the service it wants to use). This can
also improve performance since the consumer may already have some of the data
that the service needs; thus, it can skip the service that would have reread that data
and go straight to the service that uses it.
It is, of course, perfectly acceptable to expose both the inner workings as subservices
and then provide one big service that remote consumers can avail of to execute the
wholegetting the best of both worlds. There is always a tradeoff within a service
architecture between reusability of fine-grained services and the management
overhead added, so the right balance is needed. But within a process-driven
architecture, the granularity that is exposed to the business process should be
defined by the granularity of the business task at hand. The process should not
need to call more than one service for the one business outcome that it requires.
[ 106 ]
Chapter 4
Service categories
As your service architecture evolves and matures, the designers will build up a
catalog of services, with each fulfilling a different purpose and each having different
life cycles. Some will be shared externally with partners, some used directly within
the enterprise business processes, and some intended to be used internally within
one project only. As services get built and published beyond one team, a design
hierarchy of service layers is required, and it is important that each service is
categorized within that hierarchy. A layered architecture helps to assist with meeting
the key SOA goals, such as loose coupling, improved reusability, abstraction, and
improved agility. The layering is a design pattern that will lead to successful SOA
implementations, especially with the introduction of BPM. However, it should not
be mandatory to use all layers in all cases. Breaking a service down into smaller
components adds flexibility if done correctly but also adds an overhead (at design,
development, and runtime), and so must be challenged on each occasion to ensure
that each component adds the right value. If a layer is in place that is serving no
purpose, then it should be removed.
Implementing a reference service architecture and classifying the services into
categories, each with differing roles and rules surrounding their usage, will
ensure consistency throughout your design, development, and operations of the
SOA environment. It will also allow multiple teams to contribute to the service
architecture, allowing teams who know and understand the existing applications to
provide services to teams who know and understand the business processes or user
interface layer.
Without a governed reference service architecture and classification method, your
architecture will deviate away from the structure that allows the benefits of SOA
to be realized. An entangled, unstructured set of services would ensue, resulting
in an architecture where the impact of change is wide and reuse is minimal. The
maintenance of such an architecture will become more difficult than when using
point-to-point integrations, and the business process layer will become tightly
coupled to a chain of services, losing the clarity and simplicity that it would have if it
were built on a well-defined and governed SOA.
Never mix application logic with business logic in a service; they
change at different rates with different stakeholders. Keeping
their life cycles separate minimizes the impact of change and
increases reuse and agility.
[ 107 ]
[ 108 ]
Chapter 4
Presentation services
This service layer is responsible for ensuring that the user of the service can consume
it in their own preferred way from the operations, data, and protocol perspectives.
For instance, a presentation service can publish a REST interface for usage by a
partner who wants to visualize data or present functionality via a mobile device. It
can present an event interface for consumers who want to decouple their application
from the producer's services. It may present a well-secured SOAP interface for a
consumer who requires to access sensitive data or functionality. Presentation services
should not contain any business logic themselves; they should just facilitate access to
business process services or business services to different consumers.
Presentation services enable specific service functionality to be grouped together
to provide ease and efficiency for consumers. The purpose could be to minimize
calls from a portal's browser to the middleware, to minimize the volume of data
returned when providing an interface for a mobile device, or to provide specific
naming, structuring, and protocol translation to ease the integration of your service
into a partner's environment. It is important that these services are named for
public consumers to understand and that the message structure is simplified from
the canonical form. For example, the complex types referenced in a set of publicfacing presentation services should be flattened into one schema definition file,
the consumer should not be responsible for checking whether multiple schema
definitions are imported into their projects, and it should be made as simple as
possible to consume the presentation service.
[ 109 ]
For use across domains within an organization (for example, within a business
process layer or other departmental systems), these services will be implemented on
a service bus, which gives specific protocol support, ease of data translation, caching
benefits, and provision of additional security. For external consumers (for example,
partner APIs or mobile interfaces), Oracle API Gateway will be used to satisfy the
nonfunctional security and reliability requirements associated with public-facing
services, supporting system-to-system, web UI, and mobile interaction protocols.
[ 110 ]
Chapter 4
Business entity services wrap entities from master data sources for a
consistent view and maintenance of key business entities. These services
should be defined against a business definition of the entity (customer,
product, and so on), and it is important to distinguish whether the entity
is within the context of a department, a business domain, the enterprise as
a whole, or even wider than that, such as leveraging an industry standard
canonical model and including partner concerns within the entity.
[ 111 ]
Application services
Application services play a crucial role in ensuring that the logic held within the
business process and enterprise business services is not polluted by logic specific
to an application. These services will change only as the applications they connect
to change their interfaces or when the business services want to leverage more
functionality from the services. These services are responsible for the translation of
data between the application's data representation and the business schemas used by
the process architecture. Application services will have the name of the application
within their name to denote that they are tightly coupled with the applications
interface. If the business functionality is migrated to another application, then the
application services should be replaced too.
Utility services
Utility services are commodity infrastructure services that provide functionality that
is not tied to any business entities, project-specific logic, or applications. These will
include services for error reporting, auditing/logging, PDF generation, and so on.
These should be standardized across business processes and will be used by multiple
business services.
[ 112 ]
Chapter 4
[ 113 ]
The logical data model for SOA is often referred to as a canonical model. The role
of a canonical model is to give an abstraction from the physical data model and
allow the consumer of services to concentrate on the business definitions of entities
without being required to understand the details of data that is proprietary to a
specific application.
In building a canonical model, a general model, such as the OASIS canonical model
or a more industry-specific model can be utilized. If you have a large application
footprint predominately from one vendor, then it is common to base the canonical
model on theirs, such as Oracle's trading community architecture (TCA) model.
Organizations can also build their own canonical model that is closely aligned with
their business modelthis facilitates the use of a common language when multiple
business domains are crossed by a business process.
[ 114 ]
Chapter 4
Objects will be used in service design to model the structure of messages that will
be passed around the service infrastructure. They represent the organization of the
messages that will facilitate the service-oriented architecture. These are hierarchical
in nature and shouldn't be tied to a physical data model. Messages will be used to
define the data passed between the services and processesthese messages will
reference complex types that are grouped together in the object definitions. Both
objects and messages will be defined in the form of XML schema documents (XSDs),
so it important to distinguish between them with naming conventions. It is also
normal to distinguish between an object/message that is tied to the data structures of
a specific application and those that relate to the canonical or business model.
XSLT and XQuery will be the primary tools used to map messages from one service
request to another. XLST is very good at transforming one XML representation
into another representation. It has techniques such as templates, allowing the reuse
of logic across multiple nodes in the XML document. It is very suitable for data
mapping of one structure to another and is very common in integration scenarios.
XQuery's strength lies in extracting sets of nodes, performing processing actions
on those nodes, and building up the new document based on the results of these
actions. Many of the concepts of XQuery will be familiar to an SQL developer, such
as querying hierarchical and tabular datasets, restricting and manipulating these to
form result sets, and so on. If your requirement suits the method of stepping through
each node while mapping the data to a new structure, then XSLT is likely to be the
simplest. If the mapping requirement requires more processing on specific parts of
the document, then XQuery is likely to be more suitable. Within SOA Suite 12c, both
tools are available in BPEL and the service bus, so a mixture can be used for their
best purpose.
[ 115 ]
When designing the service interfaces for process-driven services, the language
represented by messages is crucial. You must ensure that the messages are
understandable to the layer that is consuming the service. Business services should
ensure that the process designer has all the data required to populate the input
message of a service and returns all the data required for subsequent steps.
Remember that all data items included in the interface message
exposed by a business service in the business process catalog are to
be populated by the BPM developer as a part of the composition of
the business process, so make sure they are structured suitably and
in a dialect that the process designer can understand with limited
scope for variance in interpretation.
Service virtualization
SOA promotes loose coupling of components in an attempt to break the dependency
and impact of change. Therefore, we should apply this principle of loose coupling
within the service design of our process architecture. Services and components of
services should not be bound directly to each other. All services should be virtualized
to allow routing to the physical service to be changed at runtime. Any service endpoint
changes should only result in a small configuration change for its consumer rather
than any disruptive redeployment. All public services should be deployed to the
service bus to facilitate the mediation of messages between the consumer and the
provider. The service bus can also allow the same service to support diverse protocols
that a consumer service may require. This virtualization should never incorporate any
business logic but should have knowledge of the different versions of services that can
satisfy the requests. It can also perform the role of caching or throttling data to protect
more complex business service from undesired load.
For routing requests between services within a service domain or between
components in a composite service, the mediator can be used. However, if the service
is used by service domain boundaries or by different teams, then the service bus
should be used. All services should be versioned to ensure backward compatibility
of functionality, that audit trails of previous versions should be stored while the
new service is transitioned, and consumers are allowed more scope to move to new
services at their pace rather than the producer's pace. Services should be versioned
with a major.minor.build structure:
Major changes denote that the service contract has changed. These are
disruptive and effort is required by the consumer to work with the new
version of the service. Previous versions are normally kept operational in
parallel until all consumers have moved across to the next major version.
[ 116 ]
Chapter 4
Build versions are internal iterations of the services and may not be
publically deployed and distributed.
Major changes will affect the service contract and require that the consumers rebind
to the service to take advantage of the new version. It is crucial that the service
deployed on the service bus supports multiple major versions of the service to
allow consumers to use upgraded major versions at the stage in their delivery cycle
that is appropriate for them. However, there is a tradeoff between being customer
focused and offering wide choice and independence to the consumers versus the
maintenance overhead that multiple service versions introduce (regression testing
as well as the resources that each deployed service may consume). Therefore, a clear
and published service decommissioning strategy is required, whereby the consumer
knows how long superseded versions of a service will be supported and at what
stage they would be required to upgrade.
Service decommissioning strategies often relate to the number of versions of the
service deployed (for example, version n-2 always gets retired when version n of the
service gets deployed). This is acceptable for services within a domain, but when
a service is offered to another domain of ownership or external party, then more
planning is needed for the consumer to upgrade to any new version of the service. In
this case, the strategy should focus on supporting previous versions of a service for
a period of time after a new major version is deployed, where the timeline is agreed
with consumers upfront and included in the service contract. The period is intended
to give enough time to allow the consumer to make the changes required bind to
the new version and have confidence that the new version is stable. Typically, with
this approach, public consumers are given 612 months before old major versions of
services are no longer supported.
Ensuring that the correct version is invoked should be the role of the service bus.
The service designer should decide whether service invocations should be routed
to the latest major service (with the consumer not specifying any version), a specific
minor version, or the highest minor version of a service for which the consumer
specifies the major version. This can then be managed operationally at runtime with
consumers given the flexibility of which version of the service they utilize.
[ 117 ]
[ 118 ]
Chapter 4
[ 119 ]
Service design should start at the abstract business process, identifying the
capabilities required to satisfy each process step and the contract that should be
agreed with the service provider to deliver that capability. This contract provides
a demarcation between the process definition and the service implementation.
There may already be a service defined in the service catalog that will satisfy, fully
or partially, the capability required. There may also be an existing application that
delivers a functionality that can satisfy the implementation requirements. The
following diagram outlines the steps to follow when defining services to support
process definitions:
Chapter 4
3. Refine based on the SOA portfolio: Group the service operations into
service contracts that can be packaged together. Operations will be grouped
if they operate on the same objects, perform related activities, or are a part
of the same change life cycle. Review the service contract definition and
requirements against the current and planned services. Identify change
requests to already implemented services that have been initiated by other
projects. Submit a request for the new service if there is no existing or
proposed contract that satisfies the business process step requirements. If an
existing service satisfies the requirement or comes close to the requirements,
then initiate tests against the service and identify gaps for which a change
request can be raised and the impact assessed. Finally, submit any new
service contract or change it from an existing service contract to the catalog
for review and reuse within other processes.
4. Identify implementation details to define the business logic, application
integrations, and mappings required to satisfy the use case and add physical
details to service.
5. Apply service principles to ensure the SOA reference architecture layering
standards are adhered to and identify the composite service required.
Classify these as being within the service categories. Break down the
service functionality into these layers to ensure that the impact of change is
minimized and reuse is maximized.
6. Identify the use of application services and map to the application portfolio,
defining which application services should be grouped together. Wherever
possible, application services should satisfy one outcome, and if multiple calls
are required to the application to meet one outcome, these should be combined
as a BPEL composite service. If APIs are available for applications, then keep
extensions to these at a minimum within the application. If you are building
the application service implementation in the source application, then ensure
that the service principles are adhered to and that each implementation maps
to a specific business outcome in the application, thus minimizing the number
of calls into this application.
[ 121 ]
[ 122 ]
Chapter 4
The two steps for Get customer information and Get customer status are
implemented for the same business outcome in this caseto determine the history
of rentals from the customer, the classification of the customer from a reward
perspective, which will be used when pricing offers, and some general details that
will be used when communicating with the customer. The process designer may
have split these two steps as they know that traditionally, different systems master
the customer contact information, history, and rewards.
However, in the definition of services to support the business process, there should
be no application knowledge involved, so granularity of the business service should
just be determined based on the process requirements. So, you would only split these
steps into two services if the business wanted to report on one step in isolation of the
other, if the business wanted to reuse one of the steps multiple times in the process
with different input and output, or if the business specified that one of these steps
may be owned by a different role in the future.
[ 123 ]
None of these are applicable here, so the service would create the
CalculateCustomerStatus abstract service operation that may be part
of a composite CustomerManagementEBS service, which would take in a
CustomerIdentificationEBM message and return the CustomerDetails,
CustomerHistory, and CustomerStatus complex typesall adhering to the
CustomerEBO model. This business service can then orchestrate the calls to the
customer relationship management and the customer benefits system applications
to retrieve the customer information and customer rewards status before returning
control back to the process. The following diagram shows the layer of services to be
implemented as part of the Rent a Car (calculate customer status) process step:
[ 124 ]
Chapter 4
With this design, the multiple steps of accessing this information from different
application systems is abstracted away from the business process to keep it easy
to understand and simple to change. As application services change, the service
contract for the business process should be kept stable. Only changes that result
in additional functionality that the RYLC business process would like to leverage
(such as a Twitter handle added to customer details) should result in a change to
the business service contract.
This approach of contract-first development of business services is accelerated by
the service bus that allows the creation of abstract services prior to concrete details
being added as the composite service is built to support the functionality. This allows
the creation of service catalog entries and tests for those services to be created in
advance of the service implementations. The Rent A Car service has a key role as it
will be published publically for use in a mobile and web user interface. Therefore,
this is implemented with two service interfaces, SOAP and REST. This is achieved
by creating a service bus pipeline that will expose the interface through two proxy
services, RequestVehiclePS and RequestVehicleRestPS.
The SOAP interface will be represented by a shared WSDL and XSD. The following
code shows this:
<?xml version="1.0" encoding="UTF-8" ?>
<definitions targetNamespace="urn:RentACarBPS"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="urn:RentACarBPS"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:weo="http://www.rylc.org/core/carrental">
<types>
[ 125 ]
The XSD structure is kept as simple as possible for the outward facing consumption,
with all complex types defined inline in the schema. This is a simplified version of
the vehicle rental structure that will be used within the business process itself:
<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.rylc.org/core/carrental"
targetNamespace="http://www.rylc.org/core/carrental"
elementFormDefault="qualified">
<xsd:complexType name="tRequestVehicleInput">
<xsd:sequence>
[ 126 ]
Chapter 4
<xsd:element name="VehicleType" type="xsd:string"/>
<xsd:element name="CustomerName" type="xsd:string"/>
<xsd:element name="StartDate" type="xsd:date"/>
<xsd:element name="EndDate" type="xsd:date"/>
<xsd:element name="Location" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="RequestVehicleInput"
type="tRequestVehicleInput"/>
<xsd:element name="RequestVehicleOutput"
type="tRequestVehicleOutput"/>
<xsd:complexType name="tRequestVehicleOutput">
<xsd:sequence>
<xsd:element name="requestResult" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="RequestVehicleError"
type="tRequestVehicleError"/>
<xsd:complexType name="tRequestVehicleError">
<xsd:sequence>
<xsd:element name="ErrorMessage" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
The REST version of the service still uses the same data structure and offers the same
operation, but its specification is shared in the WADL format, as follows:
<?xml version = '1.0' encoding = 'UTF-8'?>
<application xmlns:soa="http://www.oracle.com/soa/rest"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:weo="http://www.rylc.org/core/carrental"
xmlns="http://wadl.dev.java.net/2009/02">
<doc title="RequestVehicleRestSvce">RestService</doc>
<grammars>
<xsd:schema xmlns:tns="urn:RentACarBPS"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:weo="http://www.rylc.org/core/carrental">
<xsd:import schemaLocation="../XSDs/requestVehicle.xsd"
namespace="http://www.rylc.org/core/carrental"/>
</xsd:schema>
</grammars>
[ 127 ]
The two service interfaces exposed rely on the same service implementation that will
be implemented as a composite of other services from the service catalog.
[ 128 ]
Chapter 4
SOA
Responsibility
Core
Car rental
Core
Product and
marketing
Core
Customer
management
Core
Fleet
management
Core
Repair
domain
[ 129 ]
Business
segment
SOA
Support
Handling and
financials
Responsibility
domain
The role of the finance domain owner of SOA is to ensure that
the Rent A Car process utilizes the financial services in the
correct way to expedite any invoice processing and to ensure
accuracy and minimize faults in the financial processes.
Very often, invoice errors will be down to data issues in the
upstream process, so it is imperative that there is a finance
input into the RYLC Rent A Car process and services.
We will package the business services together into the web services listed in the
following table. However, we will leave the application services finer-grained as
the rate of change of these services is dictated by the source legacy systems that
they operate on, where JCA adapters or APIs from these source systems will be
encapsulated in a service that will be invoked from the more coarse-grained
business services.
Taking fleet management as one of the key business services and expanding the
hierarchy of services within it, we can define the following service catalog. The
business service contract should be base-lined early with the SOA developer and
SOA testers, so it is imperative that a collaborative review of these definitions is done
with the team. However, the more granular layers of the service will be expanded
by the SOA developer, and you are likely to see extra services and components
added purely for implementation reasons, such as error and compensation handlers,
delegators and audit components. These services should not appear within the
business catalog and, therefore, would be invisible to the process designer as they
extend existing processes or make use of the business services in new processes.
The following table represents an extract from service catalog for fleet management:
Catalog SOA
domain
Service operation
Service
category
Service description
WSDL
Fleet management
requestVehicle
Human task
service
This requests a
rental on the entered
vehicle and date
criteria
RentACarBPS.
wsdl
Fleet management
findAvailable
VehicleTypes
Human task
service
FleetManagement
EBS.wsdl
Fleet management
findAvailable
VehiclesAndPrices
Business
decision service
This retrieves a
list of vehicles and
calculates the rental
price for each based
on the terms of input
given to the service
FleetManagement
EBS.wsdl
[ 130 ]
Chapter 4
Catalog SOA
domain
Service operation
Service
category
Service description
WSDL
Fleet management
bookVehicle
Business activity
service
FleetManagement
EBS.wsdl
Fleet management
undoBookVehicle
Business activity
service
FleetManagement
EBS.wsdl
Fleet management
checkoutVehicle
Business activity
service
This gives a
notification that the
vehicle has been
handed out to the
customer
FleetManagement
EBS.wsdl
Fleet management
checkinVehicle
Business activity
service
This gives a
notification that the
vehicle has been
returned from the
customer
FleetManagement
EBS.wsdl
Fleet management
releaseVehicle
ForRental
Business activity
service
FleetManagement
EBS.wsdl
Fleet management
evaluateVehicle
Condition
Business
decision service
This is a rule-based
service to evaluate
the vehicle condition
FleetManagement
EBS.wsdl
Fleet management
bookVehicleCBS
Application
service
Booking
Information
CbsReqABCS.wsdl
Fleet management
updateFleetData
Application
service
updateFleet
Data.wsdl
The service identification process would continue to observe each step in the abstract
business process, allocate it to the correct SOA domain, and discuss the purpose
of the service with the owner of that domain to make sure the service reflects the
business capability required and not just the immediate use case instance of that
service. This role is often fulfilled by the SOA architect as the organization's SOA
matures, but even in these early stages, involvement should be sought from the
relevant business stakeholders in the definition of the enterprise business services
and their allocation to domains. Once the service architecture is defined and each
business service has its operations, types, and messages defined, these can be
exposed in the business catalog and added as implementation details to the process.
The specification of these business services and the supporting application services
can then be passed over to the SOA developers for implementing.
[ 131 ]
[ 132 ]
Chapter 4
Summary
In this chapter, we introduced the importance of defining your services based on the
business architecture as abstract services and adding the implementation details in a
layer of services subsequently. The role of data in an SOA that will support business
processes has been understood with a critical success factor being the definition of
the business data model that, along with services, will form the connection between
the process layer, user interface layer, and the service layer. We have understood
how important it is to separate application logic from service logic and process logic
to ensure that the benefits of a process-driven architecture are realized.
There are a number of key takeaways from this chapter, the first among them being
to ensure that the design of the services is considered in the business context to
ensure that the service layer does not become a one-to-one mapping of each process
step. Then, public services should be designed with the customers in mind, ensuring
that the service granularity, protocols, data structures, and naming approach are
simple and intuitive to consume. Finally, a service versioning strategy should be
defined and communicated with service consumers, with minor service changes not
impacting the public service interface and major service changes adhering to a clear
rollout and decommissioning strategy.
A service catalog that publishes a list of services with a defined capability in business
terms is critical to the success of a consistent process-driven architecture.
[ 133 ]
www.PacktPub.com
Stay Connected: