The
world today is full of ‘services’, however, there are many definitions of what
a service is particularly in the realm of a Service Oriented Architecture
(SOA). The problem is that one man’s service is another man’s subroutine. This
leads to the issue not just of how one manages these services but what those
services are.
The
SOA Gateway specifically describes a service as a callable function that takes
input and returns output and is described by a Web Services Description
Language (WSDL) file. It can be called using SOAP or REST or, perhaps into the
future, by some other standard call mechanism that evolves to replace these.
Under normal circumstances, services exposed by the SOA Gateway are called from
a different hardware and software platform or at least a different machine.
However, there is nothing to stop these services being called between processes
on the same machine or even in the same process, address space or partition, however,
the performance penalty in these cases may dictate that a proprietary interface
between the elements be implemented.
The
services in question can be small functions that are required as a part of a
larger online application, or may in fact be a fully fledged business objects
that require multiple inputs and may in fact themselves consume lower level SOA
Gateway services. The goal here is to represent any reusable element of a
system as a SOA Gateway service which can be called in a standard way.
A
service has a number of parts that represent the actual service. These must be
defined in order to properly control the life cycle of a service.
2.1
The Service Name
A
service will generally have a logical name. The term ‘logical’ is used here to
represent the fact that the service being defined will have a life cycle and
may change over time. Therefore the service name may never be the same as the
names assigned to the physical elements that make up the service, otherwise, it
would be impossible to control changes to the service. Any service will have a
lifetime so its ‘service name’ is purely a logical link to the service which
may have multiple instances which may or may not need to be available at any
given time.
2.2
The Web Services Description Language (WSDL)
The
WSDL for a specific service is a software contract which defines what method(s)
may be called for that service, what the inputs to each method are and what
outputs will be returned by each method. As such, it represents a specific
version of a service. When the service interface changes, the WSDL will change,
thus the WSDL represents the interface to a service at a given point in time.
2.3 The SOAP/REST Requests
In
tandem with the WSDL, the SOAP/REST request and response format is tied to a
specific version of the service. The beauty of Web Services is that it makes it
possible to change the underlying implementation of the service without
impacting on the interface at all. Any changes to the interface for a published
or frozen service requires that a new version of that service be published to
ensure that functionality dependant on that service continue to function
properly.
2.4 The Underlying Implementation
The
interface itself will depend on some underlying implementation of the service.
The implementation of a service may be created and changed in many ways but
once the actual interface to the service does not change, the WSDL and
SOAP/REST will not change. The main point here is that if the service
implementation only changes, this can be changed without changing the service.
On the other hand, if the service interface is modified in any way, a new
version of the interface (i.e. the WSDL) must be published for the new service
interface.
It
is very rarely that even the best planned projects will get it right first
time. Normally a service will be agreed, implemented and published and will
subsequently have to be changed as a project continues. This is not a
reflection on the design but purely a reflection of the fact that sometimes it
takes the implementation of something to determine what works and what does
not. In many cases, it may not be a functional requirement but a technical
enhancement to make things work better. This section discusses the evolutionary
lifecycle of a service.
3.1 Define Service Data
Requirements
One
of the first stages of any project is to define the requirements for the data
and how that data will be used. This is different depending on whether the
service implementation is new or existing, or is an application or a database:
·
For an existing application which is to be reused as a
service, the SOA Gateway tools can parse the application and understand the
data that the application requires. It then defaults what must be provided in
the incoming message for the service, and the data that will be returned as
output from the service. These defaults may then be reviewed and adjusted as
appropriate.
·
For a new application, the project must decide what
data must be provided in the incoming message for the service, and the data
that will be returned as output from the service. The service profile may then
be created by the SOA Gateway and for some languages the shell implementation
of the service may be created.
·
For an existing database table or file which is to be
accessed as a service, the SOA Gateway tools can create a default view based on
the entire table or file. It then defaults what must be provided in the
incoming message for each service method, and the data that will be returned as
output from the service method. These defaults may then be reviewed and
adjusted as appropriate.
·
For a new database or file, the project must decide
what data is to be stored in the table or file. Once this has been defined to
the SOA Gateway, the SOA Gateway can in the majority of cases create the table
or file implementation to support the service.
3.2 Create the Service
Once
the data required is defined, it’s possible to create a service that will
expose one or more methods which will deliver the required output data based on
well defined input data.
3.3 Test the Service
A
service must be tested and tested again until people are sure that the service
is returning the correct data and based on the user request.
3.4 Freeze and Migrate to User
Test
When
the developers have verified that this service satisfies the project
requirement as given to them, the service will be frozen and migrated to a user
test environment. Once frozen in this way, this version of the service may
never change. This also means that the implementation of the service (WSDL, SOAP/REST
messages and the interface to the physical implementation) simply cannot be
changed until such time as all applications using that service have either been
retired or have moved to the latest version of the service.
3.5 Review/Modify Frozen Service
The
user test environment will test the new service but may push back to
development under the following sample circumstances:
1. It did not deliver
the data they expected. This may represent a misunderstanding at the design
stage and occurs quite frequently.
2. It delivered what
they asked for but it was not exactly what they wanted. This can occur when
users are not shown early story boards of what they will receive. When they see
it for the first time, they may not like it.
3. They like what they
see but have a better view of how it could be.
4. The business has
changed for some reason and changes simply must be made.
For
any of the above reasons, the service interface is likely to have to change,
however, as it has been frozen it cannot simply be reissued. There must be
version control of the service as it is updated and released during the
project.
3.6 Migrate to Production
When
a service has been accepted in the user test environment, it is migrated to
production where it will be used by other parts of the project deployed for the
users.
3.7 New Requirements
Once
users get used to a better system, they tend to want more. They can see how
things can be improved even more which will normally require changes to one or
more services. In this case, the same service is required albeit with some more
options so the ‘service’ is the same but the interface differs. In this case,
it makes far more sense to enhance what is there and migrate other applications
to the upgraded service instead of implementing a totally new service that is almost
identical to an existing service.
3.8 Superseded
A
service will be superseded when a newer version of the service is deployed or
because an entirely new service has been created which replaces the current
service. When a service is superseded, it must remain in operation until all
users of the service have been modified to use the newer service. This can be
managed based on the usage of the service so that it is only disabled or
deleted when it is no longer being used. In this way, a service can be retired
gracefully after it has remained unused for a number of weeks, months or years.
Some companies will maintain a service unavailable over years in the event that
some strange process or user happens to need it from time to time.
There
are essentially three critical actions that take place in the lifetime of a specific
version of a service where governance must take place.
4.1 Freezing the Service
When
a service has been tested and is to be made available for usage, it must be
frozen such that it will not change again. This will normally occur when the
service is being deployed to a user acceptance testing environment for example.
4.2 Migrating the Service
Once
frozen, the service must be migrated to the next environment. This could be
user acceptance, production or any number of places depending on an
organization’s mechanism for making new services available.
4.3 Deprecation of the Service
When
a given version of a service’s lifetime has finally come to an end, it must be
deprecated as a newer version of the service will be available to be used.
4.4 Deletion of the Service
Once
it has been established that no other applications are using or depend on a
version of the service, the service can be deleted and thus will no longer be
available.
The
SOA Gateway is being enhanced to enable an organization to control the
lifecycle of their services as follows.
5.1 Concepts
The
SOA Gateway has three new attributes for a service:
i. The Version of the
service.
ii. The status of a
service.
iii. The availability of
a service.
5.2 Version of a Service
This
is a number from 1 – n. When the service is created for the first time, it will
be given the number ‘1’. This will then be incremented each time a new version
of the service is created after the service has been frozen for distribution.
Each freeze of a service will result in a frozen version number with the next
change to the service in the test environment being allocated this version plus
1. This version number will be used to ensure that the various elements of the
service may be referenced in isolation to other versions of the same service.
5.3 Status of a service
This
represents the current status of a given level of the service. It should be
noted that the same version of the service could have the same status or a
different status in different environments.
5.3.1 Test
The
service is being tested. With this status, the service may be modified as often
as is required to bring the service to a point where it is to be made available
to others. The first time a service is created or modified after being frozen,
it will be allocated a new version number.
5.3.2 Frozen
When the service is to be deployed or made available to others for use,
it must be frozen. At this point, the version assigned to the service will
represent this version of the service forever.
5.3.3 Current
The newest frozen version of the service in a specific environment will
have this status.
5.3.4 Deprecated
When a new version of a service is deployed to a specific environment,
the existing ‘current’ version of the service will be given this status. It
indicates that the service is still available to support existing clients out
there; however, the goal should be to upgrade those clients to use the most
current version of the service. There may be occasions where multiple
deprecated versions of the same service
exist if it has been updated multiple times, however, this should be considered
bad practice as it will indicate that the organization is not being very
successful in having their clients upgrade to the latest versions of the
service. It is likely that a service level agreement will exist between parties
to determine how long the deprecated service will remain active after the
latest version of the service has been made available.
5.3.5 Historical
This status will be assigned to a service which is no longer active and
has essentially been deleted. It is maintained in the configuration for
historical purposes. If this service is invoked, the client will be returned a
SoapFault and a record logged that an attempt was made to use a historical
version of the service.
5.4 Operational Availability of a
Service
The availability of a service is also an attribute that is related to
the status of the service.
5.4.1 Available
When a service is available, it may be invoked. Under normal
circumstances, this will be the operational state of the service. A service
that is ‘historical’ may never be ‘available’ as it can no longer be used.
5.4.2 Unavailable
The service is not available for use. An organization may, for
operational reasons, want to make specific services unavailable for specific
time periods during the day. When a service in this state is invoked, the
client will receive a SoapFault indicating that the service is currently not
available.
5.5 Managing the Service
The SOA Gateway will manage the service using the Eclipse Control Centre
and data in the configuration as follows.
Note in the following description, it is required that the testing of
any service will take place in a single SOA Gateway server environment. It may
then be migrated to multiple SOA Gateway target servers. If the service is
tested and modified in multiple SOA Gateway server environments, the versioning
of the service will not work correctly.
5.5.1 Service
Creation
When a service is created for the first time, it must be assigned a
unique name within the infrastructure. If the name is not unique, the service
being created will be treated as a new version of an existing service. When a
new service is created, it will be given a version number of ‘1’.
5.5.2 Service
Testing and Modification
While the service is in test mode, it may be modified and refreshed at
will. No changes will take place to the version. When a service is change from
the ‘test’ status to the ‘Frozen’ status, it will become the ‘current’ version
of the service in the SOA Gateway server where this occurs.
5.5.3 Service
Migration
The Eclipse Control Centre will offer the user the ability to migrate a
service to one or more SOA Gateway servers. The version will remain intact and
this service will become the ‘current’ version of that service in each of the
SOA Gateway servers to which it is migrated. In addition, any existing version
of the service will be marked as ‘deprecated’.
5.5.4 Service
Review
As a service is reviewed, it may need to change at which point a new
version of the service will be created in the test SOA Gateway environment.
This will be allocated the next version number to the current version of that
service in the SOA Gateway server where it is deployed.
5.5.5 Further
Migration and Review
New versions of the service migrated multiple times with the new version
number. Each time this occurs, the current version of the service is deprecated
in the target SOA Gateway which could result in multiple deprecated versions of
the service being available in a single SOA Gateway server instance as they may
only be deleted or flagged historical when no longer used. It is good practice
to always ensure that deprecated services are retired in a consistent way as
their clients are upgraded to the next level of the service to avoid having to
manage and maintain multiple versions of a service going forward.
5.5.6 Versioning
Requirements
It will be required that when a new version of a service is being
deployed to a SOA Gateway server, if the existing current version of that
service has a version number equal to or higher than the version being
deployed, the deployment will be rejected. This is due to the fact that it does
not make sense if the current version number is not lower than the new version
number. It will be possible to correct this by deleting the current version of
the service in the target SOA Gateway server, however, it will probably reflect
very loose control of the management processes for services. On the other hand,
it could be that the current version of the service in a SOA Gateway is a
number of versions lower than the version about to be deployed. This can occur
when the service goes through a number of iterations before finally being
deployed to the new environment.
5.6 Service Elements
In order to deal with the migration of a service between versions and
the migration to other target SOA Gateway servers, the following elements will
be affected. In most cases, the Eclipse control centre will handle this
automatically but the implementation of the service and how it is handle must
be dealt with carefully.
5.6.1 The WSDL and Service End Point
The WSDL and Service End Point must be different for each version of the
service. To that end, when a service named ‘<MyService>’ is deployed, it
will get the following attributes:
1.
The WSDL will be retrieved using http://<host>:<port>/MyServiceV<version>?WSDL where
‘<version>’ is the version of the service required.
2.
The service endpoint will be http://<host>:<port>/MyServiceV<version>
3.
If a programmer wishes to get the current version of the service, they
may request http://<host>:<port>/MyService?WSDL and the WSDL for the current version of the service
will be returned. Note however that the end point will still be as in point 2.
4.
When a service is being registered in a UDDI server, the unique
reference given in 1 above is what will be catalogued. It assumed here that all
UDDI servers will understand that a service will have a lifecycle as described
in this document.
The above naming mechanism can ensure that any client application which
was built based on a specific level of the service will continue to run as that
version of the service will always be available until flagged as historical.
5.6.2 Service Implementation
The service implementation itself must also
be in a position to reflect the fact that different versions of the interface
may exist. The handling of this differs based on whether the service is a
database or some business logic.
5.6.2.1 Database Services
Database services which are tuple based, such as ADABAS or relational
databases, are very flexible in how they can work with the SOA Gateway as
follows:
1.
When a field or column is added, or a service is enhanced to use a new
field, both the old and the new service instances can work on the same database
table or file.
2.
When a field or column must be deleted, the service must be modified to
reflect this and the new version of the service deployed for use. As any
existing deprecated versions of the service must continue to run until they are
made ‘historical’, the field may only be deleted after all such versions have
been made historical.
3.
When a field or column name is changed on a database, this will
ultimately break any existing service using that table or column. This will
require a major effort to coordinate the change of name with the deployment of
a new service and upgrade of clients using that service and should only be done
if absolutely necessary.
Database services which are record based, such as VSAM or IMS/DB, are
less flexible from a change perspective as follows:
1.
When a new field is added to the record, it must be added to the end of
the existing record, in some unused space or in space unreferenced by the
current version of the service. Once it has been defined, the service may be
upgraded to reference the new field and any existing deprecated service(s) will
continue to run.
2.
When a field is to be deleted, the record format cannot be changed so
the area in the record may only be flagged as deleted if it is not at the end
of the record. If it is at the end of the record, all deprecated versions of
the service must first become historical before the physical area may be
deleted in the record.
5.6.3 Business Logic Services
Services that are based on business logic represent a different issue.
Ultimately if the interface to a program be it in C, COBOL, Natural, PL1 or any
other language changes, the underlying program must change with the service.
From that perspective, it will be necessary to keep active a version of a
program for each different version of the service that is available. This
should be achieved, for example, by adding the same service version number to
the name of the executable. Ultimately the executable may only be deleted or
made unavailable to the SOA Gateway server when the specific version of the
server that references it becomes historical or deleted.
5.7
Run Time Considerations
As it can be useful for the client
application(s) that are using a service to know the status of a service, the
Version of the service and its current status will be published in SOAP Headers
returned when a request is issued to the service. This will enable more intelligent
clients to understand when a service has been deprecated and log this in some
way. With intelligent clients, it would be possible for them to:
- Recognize
that the service is no longer current
- Read the
current WSDL
- Dynamically
adjust in some way so they are using the latest and greatest version of
the service.
This ‘self healing’ behavior in clients can
help to ensure a very quick migration to a new version of a service so that the
older version of the service may be deleted or marked historical.
The SOA Gateway provides an
ideal environment to govern the lifecycle of your services exposing your core
assets. This ensures that:
·
Services are created and managed in a standard,
uniform way.
·
Services may be upgraded in isolation to clients using
those services thus avoiding all or nothing upgrades.
·
Clients will continue to run until upgraded.
·
Services can be upgraded in a simple, controlled fashion avoiding
situations where multiple services do similar things but in a slightly
different way.
·
Intelligent clients can be programmed to start using a new version of a
service once it is deployed and made available.
7
The
SOA Gateway is a cost effective software tool to:
Access
data faster...
It enables access to data from a wide range of
database languages (ADABAS, MySQL, DB2, VSAM, Oracle etc.) without server side
code, or expensive middleware.
Access
business logic easier...
The SOA Gateway enables easy access and re-use of
valuable business logic available in CICS, COBOL, C, NATURAL and many other
languages and environments.
The
SOA Gateway is developed by integration specialists Risaris Limited.
For a free trail of
the SOA Gateway, please visit: http://www.soagateway.com/html/registration_form.php
This document is distributed for information purposes
only and does not form part of or constitute an agreement with Risaris Ltd.
Although Risaris Ltd. uses reasonable efforts to include accurate and
up-to-date information in this document, Risaris makes no warranties or
representations as to its accuracy. Risaris Ltd. may also make improvements
and/or changes to this document at any time without notice. The various
approaches outlined in this document are put forward in good faith, but it
remains possible that individual results may vary. For that reason and in
accordance with standard practice, readers are encouraged to test any
materials developed on the basis of this paper before putting them into
productive use.
|
|
More whitepapers
at: http://www.soagateway.com/html/industry_papers.html
See
Terms & conditions at www.soagateway.com
Ó Risaris
Limited 2009.
About the Author