Chapter 6 

287

Many enterprise applications change because of changes to the underlying

business requirements. EISs change for similar reasons, too, but they may also

change because of hardware and software upgrades and bug fixes. New function 

ality may be added to applications and existing functionality retired. Sometimes

policies change and, as a result, applications must access EISs in a different

manner. 

Generally, it is easier to evolve the various components the enterprise appli 

cations and EISs than it is to evolve the integration layer, since it is the point of

stability. Let's first look at some strategies to evolve EISs, and then discuss how to

evolve the different types of integration layers.

Sometimes as it evolves, the changes to an EIS are internal only. The external

functionality the functionality visible to other applications remains the same.

When this is the case, you should strive to keep unchanged the original external

interface specified in the integration layer. To do this, make the sort of changes to

the internal implementation of the EIS that do not impact the external interface;

that is, the internal implementation should be changed so that it adapts to the orig 

inal external interface.

It is different when the integration layer evolves. One way to handle this is to

use a transformation layer, which is an additional layer added to enable older

applications to continue to work. A transformation layer accepts messages in the

older style used by these applications and transforms them to the current format.

Often, because of their looser coupling, it is easier to evolve integration layers that

are Web services than other types of integration layers.

When you control both ends of the integration point (the Web services end 

point and the client), it is often easier to upgrade them both at the same time.

When just the internal implementation of the Web service changes and these

changes have no affect on the external interface you merely plug in the new

implementation. 

Internal implementation changes to the Web service that cause changes to the

external interface can be relatively easier to handle if these changes enhance the

service but do not modify the original service contract. In these cases, you can

provide two sets of WSDL files, one describing the original service and the other

describing the new, enhanced service. 

However, more complex scenarios exist, and you cannot expect clients to

immediately migrate to a new service implementation. Some clients may never

migrate to the new service. For more complex scenarios, a good strategy is to

publish a separate Web service endpoint that provides the new service version.

Clients can migrate to the new service when convenient for them. You can keep