What is a reusable Service?
Gabriel Bechara's Blog |
March 2, 2008 11:21 AM
|
Comments (0)
Reusable Services
What is a reusable Service?
SOA architectural patterns as Mediation, Canonical
Data Domain Model, Categorization of services in different specialized
layers (Presentation Services, Shared Business Services, Information
Access Services...) and Web
Services versioning are important best practices. But
those patterns will not be efficient if fundamental SOA principles are not
applied. If I had to choose only one pattern, I would be
Mediating between consumers and producers of services, since Mediation will
enforce loose-coupling and enhance autonomy, both being fundamental SOA principles .
Service principles are the foundations of
any SOA architecture, without those principles any SOA approach will not be
successful. A principle must be applied,
patterns and best-practices can; and may have multiple adaptations.
Therefore one way of defining a service is by the principles it must adhere to.
The SOA principles are the foundations for
all SOA architectures. These concepts are related to high-level architectures, meaning
that they are independent of the implementations, protocols, standards and
technology usage, thus I should not be talking about WS-* or using Document/Literal
in SOAP Web Services: using standards is important for reuse (thru interoperability),
but reuse is not about just using standards.
Those principles have been
adopted/recognized broadly, and for some time now, but it's good to go thru
them again (and again). The success of your SOA approach will depend in
how far goes your adherence to those principles, and adherence to each
principle has become easier and stronger using SOA mature infrastructures available
today in the marketplace.
SOA fundamental principles
Business purpose, identification and
business reusability, with in a governed environment
Service identification may be done using
different approaches, top-down, bottom-up or meet-in-the-middle. Each approach
has its advantages,
take a top-down
approach if you want to have a better reuse and ROI in the
medium/long term. A top-down approach is business driven and should be supported
by a strong sponsor. A tactical approach, mixing top-down and bottom-up, may be
used as a start. In all cases a service must be related to a business
purpose/process, and should provide a measurable business value at some
point. The design time contract, or specifications, is done after
identifying the service. Then you will need to define run-time contracts
(QoS, SLA, availability, throughput), the interfaces (the WSDL for SOAP Web
Service), the policies (security, usages) and the implementations (code).
A service must be also visible across the entire
organization, it needs to be prescribed to avoid redundancy and avoid
duplication. It should be associated with the business and governed from design
time to run-time. Its reuse need to be measured, and it should always be
related to the business value that was the driver for providing the
service and reusing it. Reuse might be done on an enterprise level or cross-enterprise.
The logic behind the service should not be limited to individual concerns of
an activity with in one business process; it should address multiple
activities within multiple enterprise wide processes.
Loose coupling
Loose coupling between consumers of services and producers of services is one of the most important principles, if
not the most. A means for loose coupling is using the service interface (the
WSDL for SOAP Web Service) to limit this dependency; the consumer does not
know about the implementation of the service, thus have a limited dependency with the service.
Therefore encapsulating functionalities in services in such a way that implementations
changes on those services should have the least impact on their interface is one way of addressing loose coupling,
but at some point you will need to change the interface and manage
versioning
without impacting clients, manage multiple security constraints, multiple transports etc.
The mediation pattern, using an ESB,
will help achieving this. Mediation will take loose coupling to a highest
level. It will render the consumers/producers independent on all levels
including message formats, message types (SOAP, REST, XML, binary...) and transport protocols
(HTTP, HTTPS, JMS ...). This level of de-coupling will promote reuse
broadening the scope of SOA so it can be extended beyond an enterprise.
The same service being reused with different security constraints
and different formats. Exposing services to external partners is an additional way of
promoting reuse; this exposure may consist of having different messages,
different transports or different security policies, for the same business
service.
Autonomy
Autonomy is an enabler of service reuse. The
more services are independent from one another, having their own resources
(database, legacies etc.), the more reuse and composition will be possible on
those services. This will also facilitate services adaptation to changing
constraints in terms of availability, QoS, SLA, scalability etc. This will also
prepare the services to take advantage of what virtualization has to offer in
terms of dynamic resources allocations. On the other hand complete autonomy for
each service may not make sense in some contexts. For instance, services that
access legacies will share resource with existing legacy
clients. Thereafter autonomy cannot be complete for all services
but can be achieved at some level. Autonomy can be achieved,
on the functional level, for all services belonging to the same functional
building block; those services can and should be completely autonomous relatively
to other services belonging to other functional building blocks. I have
defined the functional building blocks in the article An
Introduction to Enterprise Architecture.
A reusable service must be Stateless
A reusable service should be
stateless, it may have a context with in its stateless execution, but it will not
have an intermediary state waiting for an event or a call-back. The retention
of state-related data must not extend more than a request/response on a service.
State management consumes a lot of resources, and is not in adequacy with
scalability and availability that are required for a reusable service.
In some cases you may need to deal with state
informations for conversational services, or for business long running
processes. Long running processes will have a state and can be invoked as
services, but they should be considered as special cases, and should rather be
called composite applications rather than reusable services (I will get back to this point later in this blog).
Long running processes should be related to
business processes, and they need to change at the same speed as the business,
promoting agility. Thereafter long running processes should not be reused within a
composition; on the other hand they can be invoked/activated using SOAP Web Services. If you
reuse a long running process within a composition you diminish your capacity of adapting it quickly to
your business.
Same reasoning can be done for presentation
services, a presentation service should be stateless and autonomous, a portlet is
autonomous, and it can be composed and reused in multiple portals. But the
portal doing the federations or mashups of presentation services may have a dependency in such a way that it would not be
considered as a reusable service.
Granularity
Finding the correct granularity has been a
primary concern for architects since the beginning of distributed information
systems. This is still the case and will continue to be. Within J2EE architectures,
and EJBs, DTO (Data Transfer Object) patterns where considered for populating
multiple entities, with one call, as value objects. But we still needed the
stubs on the client side to deal with un-marshalling the objects. With SOAP we
have a looser coupling, thus rendering reuse agnostic of the technical stubs,
then again we still need to deal with finding the correct granularity that will promote
reuse.
A reusable service must be composable
Composition represents aggregation of services
that offers composite applications or composite services. Composite
applications consist in composite enterprise portals or enterprise processes. Composite
services consist of defining a service that aggregates other to form another
reusable service. It's like having to compose electronic components into a
computer motherboard, the reusable composite, that itself is a component of a
personal computer, the composite application. SCA offers a model for creating
services components. A service component exposes services, references other
services and has properties common to all services in a component. SCA defines
a service based model for assembling services to compose other reusable composite
services. The composite also exposes services, references other services and has
a set of properties. SCA also defines a way to deploy those assemblies, on multiple
runtimes, and define the wiring within a service assembly, between the
services components.
SCA composites may have components running in one or more java VM instances on one or more machines. Composition may be done using an ESB that exposes the composite as service used by enterprise business processes or composite portals.
Composition of services is necessary for
reuse since it provides a way for architects to better reuse existing services to
compose the adequate services that can be used by new or augmented business
requirements, and can augment the capabilities of reorganizing the services
into new compositions required by new composite applications (enterprise
processes and composite portals).
A reusable service
must be discoverable
Promoting the reuse of a service thru prescription can be achieved using an enterprise repository;
prescribing a service is a way of encouraging service reuse during design time. At runtime, making the services
discoverable can be obtained using a services registry, with UDDI capabilities.
Applying those principles to a Data Access Service
I have chosen to present a data service, a
CRUD (Create, Read, Update, Delete) service. Identification of CRUD services may lead into confusion, because
it should not be compared to ordinary CRUD operations we use to do on simple
entities. A CRUD service should be autonomous, stateless, reusable etc. Its
granularity should be considered with attention. What does this imply? Well one
of the implication may be that it should not be participating in a global JTA
transaction, started by another service within a composition. Why shouldn't it? The use of JTA transaction will diminish its
autonomy and its reusability, remember SOAP does not (yet) support transactions
(WS-Transaction is still a specification), and distributed JTA transactions may
be complex and should be confined with in one service.
The CRUD service is exposed thru an ESB, the ESB offering the isolation necessary for the evolution of the CRUD service without impacting the consumers. In terms of SCA the service exposed by the ESB is the reusable composite. And the boundary of the JTA transaction is confined within the CRUD service.
The composite service should be governed centrally
and prescribed for reuse, with access to the contracts (design, run time and
usages), and its reuse must be measurable... Measuring reuse is important, at
some point of your SOA you might need to understand why reuse could not be
achieved one some assets, and what are the success factors of assets that are
better reused...
Conclusion
SO...whAt is a reusable Service? It is an autonomous, reusable and
discoverable, stateless functionality that have the adequate granularity necessary
for reuse, and can be part of a composition, either an application or composite service.
It should be identified with a business purpose, resulting in specifications (design
time contract), it may have multiple run-time contracts defining it's constraints,
such as security, QoS, SLA, usage policies, multiple interfaces (the WSDL if
using SOAP), and multiple implementations (the code). It should
be governed on the enterprise level within its design
time life cycle and its runtime
lifecycle promoting reuse thru prescription and measurement or reuse.
All principles should be considered for any SOA approach; the more you adhere to those principles the more your
services will be reusable and your SOA will be successful.
The mediation pattern, using an ESB, will enhance service reuse, autonomy, loose coupling,
service access control, etc., giving a stronger adherence to the SOA principles. Using an ESB offers services
virtualization, that is complementary to applications virtualization, using appliances,
on the top of machines virtualization; all the three enabling dynamic SOA.
Related blogs and articles
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
|
