How to manager the governance for web services

1.
© 2012 by EA-Optimised Limited. All rights reserved
www.ea-­‐optimised.co.uk
Conclusion
The
governance
of
web
services
is
not
a
complex
task
although
it
does
require
some
degree
of
planning.
Further,
the
task
is
made
considerably
easier
with
the
user
of
one
of
the
modern
governance
tools
that
are
available
on
the
market.
This
is
definitely
a
case
where
the
simplification
of
environments
and
design
patterns
will
yield
better
results.

2.
© 2012 by EA-Optimised Limited. All rights reserved
www.ea-­‐optimised.co.uk
Run
Services
in
a
running
environment
need
to
be
monitored
to
ensure
they
are
not
under
too
much
load,
if
they
are,
and
this
can
be
ascertained
from
the
non-­‐
functional
requirements,
additional
instances
of
a
service
can
be
created
to
horizontally
scale
the
load.
This
is
also
where
versioning
is
important;
it
is
completely
legitimate
to
have
several
running
versions
of
running
services,
each
supporting
multiple
versions
of
the
supported
interface.
The
reason
for
this
support
of
multiple
versions
is
simple.
Different
components
within
enterprise
solutions
mature
at
different
rates,
and
as
such
older
components
may
well
need
to
talk
to
older
service
interfaces.
Decommission
Decommissioning
of
a
service
version
should
only
take
place
when
it
can
be
shown
that
its
end
point
are
not
bing
consumed
by
any
callers.
This
can
make
decommissioning
tricky.
The
trail
of
what
services
are
being
called
and
by
whom
can
often
be
resolved
by
one
of
the
newer
governance
tools
such
as
service
registry
that
will
register
services
into
the
environment
and
then
monitor
their
usage.
Once
a
service
is
no
longer
required,
it
can
be
safely
decommissioned.
This
is
a
process
that
requires
some
signoffs
and
a
clear
audit
trail.
Archive
The
final
stage
in
the
services
governance
cycle
is
archiving.
After
the
services
have
been
decommissioned,
there
needs
to
be
a
clear
code
retention
policy,
since
a
time
may
come
when
the
service
has
to
be
recreated.
The
policy
should
state;
1. The
length
of
time
after
decommissioning
that
code
will
be
kept.
2. Where
the
code
repositories
can
be
found
that
allow
services
to
be
rebuilt.
The
code
repositories
should
also
hold
the
build
scripts
that
enable
the
reconstruction
of
the
environment.
3. The
test
scripts
need
to
also
be
maintained
in
an
appropriate
archive.
In
their
absence
it
will
be
impossible
to
prove
that
a
service
is
generating
the
correct
results.

3.
© 2012 by EA-Optimised Limited. All rights reserved
www.ea-­‐optimised.co.uk
Important
feature
are
the
clarity
of
design
around
the
WSDL
and
having
clear
and
unambiguous
understanding
of
the
required
performance
characteristics.
In
particular
once
the
service
interface
to
a
web
service
has
been
agreed
it
needs
to
be
seen
as
immutable.
If
for
any
reason
asn
interface
need
alteration,
then
it
should
not
be
changed,
rather
an
additional
interface
should
be
added.
This
approach
can
be
used
to
stop
the
proliferation
of
services
and
ensure
that
callers
are
able
to
interact
with
the
appropriate
version
and
interface.
Build
Build
is
no
more
difficult
than
it
sounds,
however
the
usual
good
house
keeping
and
practices
should
be
maintained.
In
particular
it
is
important
to
ensure
that
a
good
source
management
tools
is
in
use
and
that
services
are
always
built
from
scripts;
this
being
the
only
reliable
way
of
ensuring
what
defines
a
particular
version
of
a
service.
Test
in
Environment
I
say
test
in
environment
since
it
is
assumed
there
will
be
many
environment
and
before
any
service
is
deployed
in
a
live
deployment
it
will
have
moved
though
a
whole
series
of
others.
Typically,
these
will
include
at
least;
1. Development
2. Test(s)
various
3. UAT
4. Pre-­‐Prod
5. Prod
Failing
tests
at
any
of
these
stages
means
fixing
bug
and
starting
the
process
over.
The
importance
of
ensuring
environments
are
identical
cannot
be
over
stated.
Again
environment
should
be
build
from
scripts.
Any
variance
in
configuration
or
patching
level
is
likely
to
undermine
the
whole
test
process.
Promote
As
this
name
suggests,
this
is
simply
the
business
of
moving
services
from
one
environment
to
another.
However,
the
criteria
under
which
the
promotion
takes
place
need
to
be
documented
and
signed
off,
providing
a
clear
audit
trail.

4.
© 2012 by EA-Optimised Limited. All rights reserved
www.ea-­‐optimised.co.uk
Seven
Steps
Web
Services
Governance
Introduction
Web
services
form
an
important
part
of
many
enterprise
class
solutions.
However,
the
necessary
velocity
with
which
web
services
can
be
created
and
changes
presents
many
challenges.
It
its
therefore
vitally
important
to
ensure
that
any
such
environment
is
well
governed.
This
extends
to
ensuring
that
non-­‐
functional
requirements
are
met
as
well
as
and
including
levels
of
performance,
availability
and
security.
This
document
sets
out
to
describe
a
possible
system
of
governance
that
can
be
used
to
maintain
an
enterprise
class
service
environment.
However,
what
it
does
not
discuss
it
the
use
of
UDDI
and
services
registries
that
may
well
be
deployed
to
support
your
governance
model.
A
Typical
Governance
cycle
for
Web
Services
Design
Architve
Build
Test
in
Decommission
Environment
Run
Promote
Design
Design
is
as
expected,
the
start
of
the
process,
and
there
is
nothing
unusual
about
this
particular
design
activity,
with
the
exception
that
it
should
always
be
possible
to
obtain
the
version
of
a
particular
instance
of
a
web
service.