tibco designing services wp
TRANSCRIPT
-
8/11/2019 Tibco Designing Services Wp
1/15
C O N S U L T I N G S E R V I C E S
Designing Servicesin an SOA UsingTIBCO BusinessWorks
-
8/11/2019 Tibco Designing Services Wp
2/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 2
HIGHLIGHTS:
The information described hereis part of a series of introductory
best practices reports fordeploying a successful SOA.
Other TIBCO reports in thisseries include:
TIBCO Service-Oriented ITOrganizational Structure Best
Practices: An Introduction
TIBCO SOA Project
Organization, Staffing andFunding Best Practices:An Introduction
TIBCO SOA Governance BestPractices: An Introduction
TIBCO Services Life Cycle BestPractices: An Introduction
This document provides a working definition of service-oriented architecture(SOA), a reference architecture that supports SOA and some example
implementations of SOA concepts using TIBCO products. It is designed
for enterprise software architects and assumes that the reader has a basic
knowledge of integration architecture and Web services principles.
The information in this document is part of an in-depth set of best practices
that supports TIBCOs delivery methodology, the TIBCO Accelerated Value
Framework, which is used by our TIBCO Professional Services Group to help
customers minimize risks, accelerate delivery and achieve a quality integration
and SOA strategy and deployment.
Contact TIBCO Professional Services Group for more details on the topics
presented in this report and to find out how we can help you develop and
deploy an SOA that best meets your unique requirements and environment.
A Definition of SOADefinitions of SOA range from highly technical definitions around software
components and their attributes to high-level business-oriented definitions
that make analogies to the way services are offered in the business world.
If we distill the many SOA definitions down to their common core it would be
something like this:
SOA is an architectural style based on the concept of a service that
enables business agility. Service providers and service consumers interact
in a loosely coupled manner via an independent interface contract.
This implies a number of core properties for an SOA:
Architectural stylemeans that SOA is a way of planning, designing,
implementing and managing IT systems. This encompasses not only
the technology of SOA, but also and probably more fundamentally, the
organizational and IT management principles underlying an SOA.
Business agilitymeans that the key driver of SOA is to provide benefit to
the business in the form of agility in supporting the business requirements.
Agility implies wrap and re-use rather than rip and replace, therefore
SOA must be technology agnostic and able to operate within highly
heterogeneous environments. Business agility also means that the services
-
8/11/2019 Tibco Designing Services Wp
3/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 3
that an SOA exposes must be at sufficiently coarse granularity to be usefulto the business.
Loosely coupledis a core attribute of SOA and it has many
technical implications:
- Service implementation is independent of platform and language.
Providers and consumers are related to each other only via an
independent interface contract.
- Services should be independent, and exhibit coarse granularity and
location-transparency.
- Service interactions take place via a messaging infrastructure
descriptive messages exchanged, ideally, in an asynchronous manner.
- Service providers and their associated interface descriptions and
semantics must be discoverable in some manner.
Beyond the core concept of services compose-ability is regarded as a
key attribute of an SOA. That is, an SOA must support the ability to define
composite servicesand to orchestrate servicesto support business
processes. These properties should be a natural consequence of the loosely
coupled nature of services.
EVENTS IN A SERVICE-ORIENTED ARCHITECTURE
In the real world, asynchronous events are a key operation within any given IT
architecture. Events include technical events such as a user hitting a button
on a web form, a printer running out of paper or a disk drive undergoing
a catastrophic failure. Business events include events such as a customer
calling the helpdesk, a worker completing a task or a stock split on the stock
market. Asynchronous events have causes that may lie outside the realm of the
business or the IT implementation but which have effects within the business or
architecture. A customer call may initiate a workflow. A stock split may initiate
a series of database updates and a disk drive failure may initiate a disaster
recovery process.
Events represented by asynchronous messages are an important part ofany real-time enterprise architecture.
We regard events as first-class citizens in an SOA. They are implemented
via services which emit or consume asynchronous messages using a
standard service endpoint.
-
8/11/2019 Tibco Designing Services Wp
4/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 4
TIBCO views event-driven architecture (EDA) as complementary to SOA. Evenwithin the Web services mainstream, there is increasing acknowledgement
that interactions between service providers and service consumers must
increasingly be asynchronous and move away from purely synchronous
request/response message exchange patterns. TIBCOs view is that events
must be first-class citizens in an SOA.
In TIBCOs approach to SOA, events are exposed as services with the same
underlying infrastructure as for synchronous request/reply services. When it
comes to implementation there should be no fundamental difference between
services that are demand driven (i.e. services accessed via synchronous
request/reply message exchanges) and services that are event driven (i.e.
services as asynchronous message publication). In this document when we referto SOA, we mean SOA+EDA.
SOA AND WEB SERVICES STANDARDS
Web services are a group of related and/or competing standards based on
XML that are intended to facilitate the implementation of SOA for application
development, system integration and business-to-business interoperability.
As implemented, there are a number of problems with Web services standards
when employed for the purposes of an SOA. Web services currently rely too
much on synchronous request/reply interactions. The standards as they exist
are too closely tied to unreliable message transports such as HTTP. These
appear to be faults of implementation rather than design because there isgeneral awareness of these limitations and progress is being made to open
up the Web services standards to more loosely coupled, message oriented,
asynchronous implementations.
The SOA reference architecture presented in this document is independent
of any specific Web services standards. However, it makes sense to refer to
and use some of the Web services standards as they are widely adopted and
consolidated because:
Interoperability is a desired property of many services in an SOA
architecture and the use of public standards, where appropriate,
fosters interoperability.
Some aspects of the Web services standards embody best practices
that have been learned through many years of distributed application
integration solution development. Therefore we want to make use of
-
8/11/2019 Tibco Designing Services Wp
5/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 5
the best design patterns available from the wider Web services andSOA communities.
SOAP envelopeis a useful mechanism for wrapping service invocations
along with associated metadata. Even if you dont use the SOAP envelope
standard schema in an SOA implementation, it is still important to have some
kind of standard message envelope for service interactions. SOAP is generic
enough and extensible enough to support most implementation requirements.
WSDLis a useful mechanism for publishing a service description that
is completely independent of the service implementation. Anyone can
obtain the WSDL for a service and use it to implement a service consumer.
This is a key attribute of SOA the service description must be separable
from and independent of the service implementation.
The concept of a policyas embodied in the emergent WS-Policy
standards is a useful design pattern. The ability to separate out policy-
style behavior into an orthogonal component is very powerful for
implementing extensible and compose-able services.
The use of Web services standards are not required to build an SOA.
Some aspects of the Web services standards are in an SOA to foster
independence of implementation and hence interoperability between
different platforms.
-
8/11/2019 Tibco Designing Services Wp
6/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 6
A Functional View of the SOAReference ArchitectureThis section provides a functional view of the SOA reference architecture. The
overall architecture is broken down into a hierarchical description of the logical
components within the architecture. We also present a description of the
functions that each logical component must support within the architecture.
THE TIBCO REAL-TIME ENTERPRISE PLATFORM
Figure 1 shows a high-level diagram of the TIBCO real-time enterprise
platform. The aim of this reference architecture document is to represent the
components of the TIBCO platform as generic implementation mechanisms.The primary focus will be on the Service Delivery Network layer.
Figure 1. TIBCO Real-TimeEnterprise Platform
Service Delivery
NetworkPeer-to-peer network ofcommon, consistent andreusable services, QOSand objects.
OperationalManagement
EventManagement Security
MetadataManagement
End-UserServicesMeans of accessingand analyzing underlyinginformation and activities
Presentation ServicesAnalytic Services
Portal Dashboard Rich ApplicationsEvent
CorrelationEvent
Analysis KPI
CompositeServicesOrchestration & compositionof services and tasks
Business Process Management
CheckCredit
CheckAccess
ProvisionEmployee Create Customer
CheckPartner
Inventory
EnterpriseApplicationsLegacy, Packaged,and Custom
J2EE/.NETData
Warehouse
PackagedApps
Mainframe
Messaging
Integration Point-to-PointServices
BusinessServices
PartnerManagement Registration
ServiceOrchestration
TradingPartner
-
8/11/2019 Tibco Designing Services Wp
7/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 7
THE HIGH-LEVEL ARCHITECTURE
Figure 2 takes the real-time enterprise platform shown in Figure 1
and abstracts it to the highest level to highlight the main elements of
the architecture.
At the base of the architecture, we have a series of service endpoints that
represent service providers and service consumers within our architecture.
Service endpoints represent demand driven (e.g. request/reply) service providersand consumers as well as asynchronous event-driven service providers and
consumers (e.g. event publishers and subscribers).
The Business Process Management(BPM) layer represents the orchestration
or choreography of interactions with service endpoints to support a business
process or to achieve a business goal. These may include short-lived business
processes such as straight-through processing applications as well as long-
lived processes such as human-oriented workflow applications. This layer also
supports the composition of basic services into more complex services.
Analytic Servicesrepresent those applications that perform some level of
analysis, correlation, aggregation, etc. on groups of events in order to deriveinformation about those events.
Presentation Services represent dashboards, portals or rich clients that support
personalization and aggregation of services data for human user interfaces.
Figure 2. High-Level SOA+EDAEnterprise Architecture
-
8/11/2019 Tibco Designing Services Wp
8/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 8
Service Administrationrepresents the functionality required to support thedevelopment, discovery, deployment, monitoring and life cycle of services.
It also includes the requirements of a policy framework including support for
security authentication, authorization and encryption.
In terms of our reference architecture, the higher-level layers such as analytic
services, presentation services and business process management are usually
special cases of service providers and service consumers. For example, a BPM
engine may expose a subscriber service by which external systems may initiate a
workflow process. The process would execute as a series of calls out to external
service providers. Finally the end of the workflow process could be notified to
interested parties by a publisher service. If the BPM engine does not natively
operate within our SOA implementation, then the BPM engine behavior couldbe wrapped within custom service endpoints. The remainder of this document
will be primarily concerned with the service endpoints and the administration
services components of the architecture.
SERVICE ENDPOINTS
This section describes the functional composition of the service endpoints. If
we zoom in for a detailed look at one of the service endpoints in Figure 2 we
see a layering of components like that shown in Figure 3.
At the bottom of the service endpoint stack is the underlying host system that
implements the business functionality exposed by the service.
At the top of the service endpoint stack we have the service description
that ultimately resides in a registry or repository. The service description is
supported at runtime by the service implementation that comprises a service
interface and a policy implementation.
In the middle we have an adapter layer that supports connectivity between
the host system and the enterprise and performs any semantic mappings
between the external services model and the internal data schema and
application interface.
The following sections go into more detail about the role of each of these
components in the TIBCO SOA reference architecture.
Service Description
The service description is one of the defining characteristics of an SOA service.
This is a machine-readable description of the functionality that the service
-
8/11/2019 Tibco Designing Services Wp
9/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 9
supports and the mechanisms by which this service can be invoked. The servicedescription includes:
A service interface, which is the abstract boundary that the service
exposes. It defines the types of messages and the message exchange
patterns that are involved in interacting with the service, together with any
conditions implied by those messages.
The message transport or details of how the service can be accessed at
the messaging layer.
The semanticsof the service, which is the behavior expected when
interacting with the service. The semantics expresses a contract between
the service provider and the service consumer. It expresses the ef fect ofinvoking the service. Service semantics may be formally described in a
machine-readable form, identified but not formally defined, or informally
defined via an out of band agreement between the provider and the
requester entity.
The service description must be publicly accessible in some way in a
service registry or repository. The description should be both machine and
human readable.
Figure 3.The Service Endpoint Stack
-
8/11/2019 Tibco Designing Services Wp
10/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 10
Service ImplementationThe service implementation is the runtime component that supports the service
functionality as a service. It comprises the following two sub-components.
Service Interface
The service interface is the runtime instantiation of the service description. In
the case of a service provider, this is the component that service consumers
contact in order to invoke the service. In the case of a service consumer, this is
the component that makes a connection to the service provider.
Policy Client
The service implementation must be able to enforce policies associated with
the service. A policy is a constraint or a requirement on the behavior of theservice or the agents that use that service (e.g. service consumers that may
invoke a specific service provider subject to certain policy constraints). Typical
service policies include:
Security(or permission), which describes the conditions under which a
service may be used by an agent. These may include how agents are to
be authenticated before using the service, which agents are authorized
to use the service and how data is to be encrypted in interacting with the
service interface.
Auditpolicies, which describe how interactions with the service are to be
traced either for SLA monitoring or for legal purposes such as the use ofnon-repudiation logs.
Quality of service(QoS) policies, which relate to the service levels that a
service must support for its consumers. How can we be guaranteed that
the service will be available when needed? If the service is not available,
what are the policies relating to resumption of the service? For example,
if an asynchronous message is sent to the service, can we be sure the
message will be processed when the service resumes or must we re-try on
a given interval, etc.
QoS and audit policies are potentially related in the sense that audit policies
may be used to monitor how well a service implementation meets the QoS
requirements. For example, we may use the audit policies to measure a given
SLA or key performance indicator associated with a service Implementation
(and advertised as part of the service description).
-
8/11/2019 Tibco Designing Services Wp
11/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 11
Ideally service policies should be implemented as orthogonal aspects of codethat plug-in to the service implementation code.
The policy client will often perform its functions by contacting one or more
associated policy servers. For example, a security policy client may make
reference to authentication and authorization information in a central security
policy server. Or an audit policy client may send information about the
invocation of a service to a central audit repository.
The Adapter Layer
The adapter layer is the glue between the service implementation and the
host system (that implements the underlying business functionality).
The adapter is responsible for connecting the external enterprise world(mediated by the services standards) with the internal applications that
implement the service functionality. We split the adapter into two further
logical components the semantic adapter and the technical adapter. This split
is necessary because the two components are often implemented by different
software packages.
Semantic Adapter
The semantic adapter supports the semantic mapping between the external
services world and the internal application implementation. Semantic mapping
includes:
Schema Transformation mapping between the external common datamodel embedded in the service definitions and the internal application-
specific data representation.
Operation Mapping mapping external service operations onto internal
application invocations.
Key Mapping mapping external system-independent entity keys into
system-specific entity keys.
Integration Logic executing any logic or process that is necessary to
map the internal behavior of the application to the external behavior of
the service.
The semantic adapter may not always be necessary in the specific case wherethe service interface maps directly to the application interface. However,
in general the semantic adapter is an important part of any integration
-
8/11/2019 Tibco Designing Services Wp
12/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 12
architecture for managing change between the enterprise service model andthe application implementation of the service.
The semantic adapter supports semantic mapping between the
external services world and the internal application implementation.
The semantic adapter is important for managing change between
the enterprise service model and the application implementation of
the service.
Technical Adapter
The technical adapter is responsible for the physical connectivity into theapplication that implements the service functionality. This adapter may operate
against an API or using an integration technology such as COM, CORBA, MQ,
ODBC, a file-based interface, etc. The technical adapter generally does not
perform any semantic transformations, but instead communicates with the
application using its native schemas and operations.
The technical adapter may not always be required or may not always be distinct
from the semantic adapter. But in general there needs to be something that
operates on an application interface on behalf of the service.
Host System
The module labeled functional implementation in Figure 3 represents thesoftware component that actually carries out the function(s) supported by the
service. In an integration environment, this is usually a host application such as
a database, ERP application, etc.
In some cases TIBCO BusinessWorksor BPM software may act as the host
system in the sense that the service functionality is implemented as a
BusinessWorks process or as a BPM workflow.
SERVICE ADMINISTRATION
The service administration component looks after the functions associated with
security, monitoring, service discovery and service life cycle management.
Security
Security includes:
Authentication that a service consumer or service provider are in fact
who they say they are.
-
8/11/2019 Tibco Designing Services Wp
13/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 13
Authorization that a given service consumer is authorized to invokea given service provider and conversely that a given service provider
may be invoked by a given service consumer. In the event-driven model,
authorization assures that a given service provider can publish a given
event and that a given service consumer can subscribe to a given event.
Encryption allows for all or part of a message to be encrypted so that
only authorized service endpoints can read the message.
In an SOA, security is controlled by centrally managed policies associated with
service providers and consumers.
Monitoring
Monitoring provides the infrastructure to track operations on serviceendpoints, the responsiveness of service endpoints with respect to service
level agreements (SLAs) and to signal alarms to system administrators when a
service endpoint fails or its parameters go out of bounds. The main aspects of
monitoring include:
Audit the ability to track significant points in a service invocation along
with metadata.
Performance the ability to measure the performance of a service
endpoint for capacity planning and to determine SLA compliance.
Alarms the ability to notify system administrators and enterprise
management systems of alarm conditions in a service endpoint.
In a distributed SOA it is helpful for the monitoring to be agent-based using
runtime agents associated with each service endpoint. This provides better
scalability and also allows the local agents behavior to correlate with the
service endpoints current state in its life cycle.
Discovery
Service discovery covers the ability for developers to locate and use services
at design time as well as the ability for service consumers to discover and use
services at runtime.
Life Cycle ManagementLife cycle management covers the ability to manage service endpoints through
the following states in their life cycle:
Deployment the ability to deploy a service into a specific environment
(e.g. Development, Test, Production).
-
8/11/2019 Tibco Designing Services Wp
14/15
DES IG N IN G SERVICES IN AN SOA US IN G T IBCO BUS IN ESSWORKS 14
Runtime Life Cycle the ability to start, stop and pause a serviceendpoint once it has been deployed.
Version Management the ability to promote service endpoints from
one version to another to take into account changes in functionality or in
interface definition.
Version Rollback the ability to roll-back a service endpoint from one
version to an earlier version.
A widely-agreed consequence of the loosely coupled nature of services in an
SOA is services can be managed independently of each other. This implies
a very fine-grained level of management at the level of an individual service
rather than the service container.
Dependency Management
In an SOA where service endpoints are loosely coupled and independently
managed, it is important to be able to determine dependencies between
service endpoints.
At runtime we want to be able to discover if changes or failures of a service
endpoint will have adverse effects on other service endpoints or on business
processes that depend on that service endpoint.
At design time, we want to determine if changes in a given message schema or
service description associated with a service endpoint will have an impact on
other service endpoints.
-
8/11/2019 Tibco Designing Services Wp
15/15
For More InformationThis document has presented a definition of SOA along with a description of
the functional components of an SOA. Weve given specific emphasis to the
implementation of service endpoints to support integration architecture.
Contact TIBCO Professional Services Group for more details on the topics
presented in this report and to find out how we can help you develop and
deploy an SOA that best meets your unique requirements and environment.
Global Headquarters
3303 Hillview Avenue
Palo Alto, CA 94304
Tel: +1 650-846-1000
Toll Free: 1 800-420-8450
Fax: +1 650-846-1005 www.tibco.com
2005, TIBCO Software Inc. All rights reserved. TIBCO, the TIBCO logo, The Power of Now, TIBCO Software, and TIBCO BusinessWorks are trademarks or registered trademarks of TIBCO Software Inc. in the United States and/or
other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only. 11/05