What does SOA mean to you?
This page is published under the terms of the licence summarized in the footnote.
This paper discusses things to think about if you want a successful SOA.
A headline thought is this: architecture is more than defining building materials and building regulations; it requires actually making an effort to architect systems.
And if you want to reuse specific services, then architects ought to help designers to understand when and how new/changed applications should use those services.
(This paper was inspired in part by a paper by Gregg O’Reilly, who drew on his experience of managing two software development teams in remote locations.
His paper advised that to succeed with software reuse, considerable the management effort is needed not only to create and maintain a library of reusable components, but also to make sure those components are in fact used when appropriate.)
Contents
Service–Oriented
Architecture (reprise)
Things
enterprise SOA ought to mean
Getting
started with SOA in an agile way
Data
models and message dictionaries associated with SOA
Challenges
that make SOA difficult
Some
relevant terms and concepts
All architects (from software architects to enterprise architects) face the same questions.
· What is the right size and scope of a module?
· How to avoid or minimise duplication between modules?
· How to separate or distribute modules?
· How integrate modules?
Initially, SOA was a reaction against “distributed objects” using object request brokers like DCOM.
SOA evangelists advocated a more loosely-coupled kind of modular design and integration style, with opposing features:
SOA terms and concepts, like “shared services”, have seeped into business architecture also.
An enterprise may define a business function by an interface, in the form of an SLA, and then outsource it to a remote service provider.
However, SOA is more commonly used as label for promotion of Web Services and/or EAI middleware.
Web Services
A web service is a logical module described in WSDL that can be accessed over a network.
(It is an interface in the BCS reference model sense.)
A web service operation is a discretely invocable action in that interface.
(It is a discrete service in the BCS reference model sense.)
Modules in remote systems interact with a web service in the manner prescribed by its description in WSDL:
· WSDL1: assumed invocation of web service operations via SOAP, conveying XML messages over HTTP (or perhaps SMTP).
· WSDL2: allows direct invocation of web service operations via HTTP (so, no SOAP).
EAI middleware
EAI middleware is a platform technology designed to handle messages passing between the modules of distributed applications.
It has the ability to store, route and transform messages; it can support the definition of workflows that orchestrate modules, and has other features.
It has advantages where a module communicates with many other remote modules.
And where the modules at either endpoint of a network are volatile (they appear, disappear or are replaced).
EAI middleware can be a sledgehammer to crack a nut; it can make the integration of modules harder than point-to-point integration.
Some agile development gurus, after bad experiences of middleware deployment, have led to promote REST as an alternative.
When asked “What
does SOA mean?” solution architects give me a range of remarkably different
answers.
Below are some of
the answers,
1. reusing remotely invokable services - using some kind of module catalogue or library.
2. designing workflows to integrate applications (perhaps using EAI middleware).
3. using message passing (rather than RPC or RMI) to invoke remote modules
4. using Web Services to wrap up remotely invokable software of any kind
5. a strategy for deployment of EAI middleware.
Overuse of the term SOA has made it close to meaningless.
If you are interested in my view, I’ll give it after reviewing three possible views of SOA
Builders’ view –
about technologies and standards
Some define SOA in terms of building materials, such as use of Web Services standards.
Certainly, WSDL, SOAP and XML are useful tools to use in an SOA implementation.
But a catalogue of Web Services is not a catalogue of services likely to be reused; it is just a catalogue of Web Services.
Regulators’ view –
about design principles
Some define SOA in
terms of regulations and design principles.
Say for example that client/sender and server/receiver components should be loosely coupled.
This view is plausible and reasonable, and historically justifiable.
But it doesn’t speak directly to the point of how to optimise modular design through reuse
Architects’ view –
about optimisation through reuse
Some say SOA means enabling, directing and managing reuse of services.
For this, architects need guidance on how to populate and govern the content of a cross-enterprise service catalogue.
The guidance is more methodological than technological (how to use an enterprise service bus or other EAI middleware).
Architects want a cross-enterprise service catalogue with reader-friendly service contracts.
A plain text document can be more helpful than what middleware technology provides by way of a service directory – with perhaps thousands of Web Services.
Architects wants help with the politics, with managing the ownership, funding, performance and version control of shared services.
SOA implies designing a system for flexibility by creating and/or using remotely requestable services.
Beyond that, SOA may involve some or all of the following features:
· maintaining some kind of module catalogue or library of remotely invokable services
· using a shared canonical data model to simplify integration by standardising the data types used in service contracts.
· designing workflows to integrate services provided by distinct applications
· using design patterns that relate services of different types (e.g. in a hierarchically layered client-server architecture).
· using message passing (rather than RPC or RMI) to invoke remote modules Stateless services (or stateful rather than stateless interfaces and components).
· using a publish-subscribe communication mechanism (to decouple message senders and receivers in an event-driven architecture).
EAI middleware is often used; it can help in a variety of ways; but it does not seem to me to be essential to the concept of a SOA.
If your SOA is to be an ‘architecture’ rather than only a set of regulations and mechanisms for connecting components, then you need to think about the following.
A services catalogue encourages
reuse to accelerate building new applications
Each service should be catalogued with contract: including not only the signature and rules but also its non-functional service levels and commercial constraints on use.
The service catalogue must be managed and governed by nominated architects.
They need not be programmers – but must be able to read and write the service catalogue at design time.
(A service directory that is unreadable by non-programmers is not usable as a service catalogue.)
The scope of the service catalogue is limited to an enterprise with architecture governance in place.
(Ad hoc linking of systems via Web Services is not an SOA.)
A canonical data model standardises
the data types in service contracts
The service catalogue is built on agreements about the data types (or media types) sent to and received from the services.
With no agreement about data types (say email number), different services will reply with different versions of the same data type.
This hinders interoperability – it represents a failure of governance and a failure to build the best SOA you could.
The service
providing a service should be scalable.
It should be
stateless; it should be asynchronous (non blocking) in response to client invocations.
Note that for maximum flexibility, you might do better to define single-operation interfaces (or Web Services).
Since any kind of grouping of services into an interface ties some clients to structure that is not designed for their needs.
And remember: every network hop prompts questions about latency, availability and security.
"Every
extra tier is a performance hit, extra documentation, extra skills and
knowledge to acquire, and extra complexity over time."
(A correspondent commenting on this paper).
Here’s a process to support the above definition of SOA:
· identify a few services you actually want to reuse.
· catalogue them along with their associated contracts.
· choose cheap and simple distributed computing tools to implement those services.
· implement those services and test them to required NFRs.
· see if you can actually get some clients to use those services.
· learn what you need by way of organisation, processes and documentation to manage and maintain those services in the light of change requests.
· measure the ROI you have got from reuse so far.
· see if you can build a business case for more/better infrastructure.
“Yup - you definitely get a better outcome using agile techniques.
Otherwise for a big piece of work you could be looking at a ROI of 3-5 years and projects of that size often fail as the business grows and morphs and the original requirements change over time.
To identify which services to start with - just look at what data the business uses most.
One tip for anybody new in this space: be careful when dealing with vendors because if you tell them you want an SOA platform they will usually throw their most expensive ESB at you.
An ESB is just one implementation for enabling SOA but there are alternatives.
I agree also on the history of architecture in general and SOA in particular.
These are not new concepts, just expanded.
For me the Architecture piece in SOA describes both the way in which you go about designing services, interfaces and contracts, and the way in which they will be executed.
You can achieve this without being overly prescriptive.
I may say we will use a particular platform but designers still have choice around options for interfacing and execution including languages.” Shane Downey
John Palmer proposes as follows:
An enterprise may maintain several distinct SOAs (and I suggest service catalogue for each).
The enterprise can and should maintain a cross-SOA canonical data model.
Each distinct SOA should have a message dictionary that defines request and response messages and common information elements thereof.
This message dictionary should be related to the cross-SOA canonical data model.
Incomplete adoption of definitions in the cross-SOA canonical data model should be a subject of governance review/exception management.
Each distinct SOA may in addition have its own SOA-specific data model.
Because it is easier to link the
cross-SOA canonical data model to this than to the SOA's message dictionary.
The cross-SOA canonical data model should be related to a business data model
or domain model (assuming there is one).
Incomplete adoption of the business data model definitions should also be a subject of governance review/exception management.
See also “SOA Business Case and Governance” in the Library at http://avancier.co.uk
This explores about a dozen challenges that any SOA initiative should address, including:
Synchronicity: How work, divided
between two components, is scheduled.
The two components
are called client and server below, but could be called sender and receiver, or
prior and successor.
Synchronous: 1: A request-reply style:
a client must wait for a server to reply before continuing (the usual
invocation from one COBOL module to another or one Java object to another).
2: A blocking
style: a server serves one client at a time, turning away any other client who
attempts to request a service.
The caller and
responder hold a channel open, blocking others from using it (the usual
invocation style in CORBA).
Asynchronous: 1: A fire-and-forget style in which a client does not wait for a server to reply,
so can carry on to do other things.
A call-back
mechanism may be needed.
2: A non-blocking style in which a server can
accept requests from several clients before responding to the first.
Typically, the
responder has a queue of incoming messages and releases the channel after a
message is received.
Loose coupling mechanisms: These
include the ways that SOA and WOA depart from the initial OO design
presumptions.
·
Internet domain names or URIs - rather than
object identifiers
·
Several name spaces - rather than one name space
·
Stateless components - rather than stateful
objects
·
Reuse by delegation - rather than reuse by
inheritance
·
Intelligent process controllers - as well as
intelligent domain objects
·
Message passing - rather than request-reply
invocations
·
Non-blocking servers - rather than blocking
servers.
The table below
lists some factors more generally considered.
|
Factor |
Tightly-coupled |
Loosely-coupled |
|
Time |
Parties
communicate synchronously and are deployed together. |
Parties
communicate asynchronously and need not be deployed together. |
|
Location |
Parties know
others’ locations. |
Parties do not
know others’ locations |
|
Data types |
Parties
exchange complex or strong data types. |
Parties
exchange only simple or weak data types. |
|
Transaction management |
A process
involving both parties can be roll-backed by a transaction manager. |
A process
involving both parties cannot be roll-backed by a transaction manager |
|
Version |
Client
components are disabled when a new server component version is released |
Client
components are not affected when a new server component version is released |
|
Protocol |
A client must
use one protocol to call a service. |
A client can
use any of several protocols to call a service. |
Cluster analysis: Techniques for finding and
grouping items because they are inter-dependent or co-dependent on the same
data, same role, etc.
It is
used to encapsulate cohesive services into one component, and so minimise the
couplings between components.
Affinity analysis: Techniques for finding and
grouping items based on characteristics they share.
It is
used to organise a large portfolio of components into a hierarchical catalogue.
Service-oriented design: A methodology that matches
required services to available services.
Required
services are discovered though decomposition of high-level business process and
use cases.
Available
services are discovered in some kind of services catalogue and invokable across a network via some kind of services
directory.
Service catalogue: A list of services designed to
help designers find and reuse them, in which each service is defined by a
service contract.
(It may
in practice list whole interfaces or components that cluster services, rather
than discrete services.)
Service directory: A service catalogue that a
service consumer can use at run time to find how and where each service can be
accessed.
Service quality: A characteristic of a service in
a well-designed architecture.
A
service conforming to Web Service standards has four such qualities: it is an
abstraction, composable, loosely-coupled and defined by a contract.
Beyond
that, a well-designed service should be reusable, autonomous, discoverable and
stateless.
Some
services are best designed to be transactional.
(All but
the last of these qualities were defined by Thomas Erl.)
Service-oriented design
challenges: Obstacles
to successful service-oriented design.
Notably:
service ownership, maintenance of shared services, versioning strategy.
governance of the service catalogue, avoiding vendor lock in, management of
service-oriented design methodology across the enterprise.
As a
service consumer, you don’t want service owner to change the interface unless
you ask, or refuse to change it when you do ask.
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0 27/09/2014 23:17
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and
include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org