The bottom-up strategy

2017-11-03 09:05:05

This approach essentially encourages the creation of services as a means of fulfilling application-centric requirements. Web services are built on an "as needed" basis and modeled to encapsulate application logic to best serve the immediate requirements of the solution. Integration is the primary motivator for bottom-up designs, where the need to take advantage of the open SOAP communications framework can be met by simply appending services as wrappers to legacy systems.

10.3.1. Process

A typical bottom-up approach follows a process similar to the one explained in Figure 10.3. Note that this process assumes that business requirements have already been collected and defined.

Figure 10.3. Common bottom-up strategy process steps.

Step 1: Model required application services

This step results in the definition of application requirements that can be fulfilled through the use of Web services. Typical requirements include the need to establish point-to-point integration channels between legacy systems or B2B solutions. Other common requirements emerge out of the desire to replace traditional remote communication technology with the SOAP messaging communications framework.

For solutions that employ the bottom-up strategy to deliver highly service-centric solutions, application services also will be modeled to include specific business logic and rules. In this case, it is likely that two application service layers will emerge, consisting of hybrid and utility services. Those services classified as reusable may act as generic application endpoints for integration purposes, or they may be composed by parent hybrid services.

Step 2: Design the required application services

Some of the application services modeled in Step 1 may be delivered by purchasing or leasing third-party wrapper services or perhaps through the creation of auto-generated proxy services. These services may provide little opportunity for additional design. Custom application services, though, will need to undergo a design process wherein existing design standards are applied to ensure a level of consistency. Chapter 15 provides a design process specifically for reusable application services.

Step 3: Develop the required application services

Application services are developed according to their respective service descriptions and applicable design specifications.

Step 4: Test the services

Services, their associated solution environment, and underlying legacy logic are tested to ensure that processing requirements can be met. Performance and stress testing measures often are used to set the processing parameters of legacy systems exposed via wrapper services. Security testing is also an important part of this stage.

Step 5: Deploy the services

The solution and its application services are deployed into production. Implementation considerations for application services frequently include performance and security requirements.

10.3.2. Pros and cons

The majority of organizations that currently are building Web services apply the bottom-up approach. The primary reason behind this is that organizations simply add Web services to their existing application environments to leverage the Web services technology set. The architecture within which Web services are added remains unchanged, and service-orientation principles are therefore rarely considered.

As a result, the term that is used to refer to this approach"the bottom-up strategy"is somewhat of a misnomer. The bottom-up strategy is really not a strategy at all. Nor is it a valid approach to achieving contemporary SOA. This is a realization that will hit many organizations as they begin to take service-orientation, as an architectural model, more seriously. Although the bottom-up design allows for the efficient creation of Web services as required by applications, implementing a proper SOA at a later point can result in a great deal of retro-fitting or even the introduction of new standardized service layers positioned over the top of the non-standardized services produced by this approach.

Case Study

RailCo did not use any particular strategy when building the services they required to connect to the TLS B2B solution. They simply retrieved a set of published specifications from the TLS partner Web site and built the required services following the traditional development lifecycle they were already accustomed to.

RailCo was unaware that they were in fact following a very common approach to service construction known as the bottom-up strategy simply because this delivery approach consists of stages that closely mirror typical phases in traditional development methodology.

The result of building their Web services in this manner was predictable. The services were delivered to accommodate a specific need and therefore fulfilled immediate business requirements. Their construction was completed efficiently and cost-effectively, and the project was initially considered successful.

Some time later, though, new requirements surfaced. TLS implemented a new policy that affected some of the purchase order business logic on RailCo's end. Additionally, RailCo's own internal business process underwent a change as a result of a module upgrade within its legacy accounting system. This change carried over to affect low-level data access parameters processed by the RailCo Invoice Submission Service.

Both of these changes were an indication of things to come. Various adjustments needed to be made to the RailCo legacy systems that interfaced with their Web services, and numerous changes were made to existing automation processes as part of a company-wide initiative to improve responsiveness and efficiency.

Following are descriptions of the primary problems encountered by RailCo:

Each change, regardless of origin, required a significant redevelopment effort that typically affected multiple services. Because there was no separation of business and application logic, change impacted a broader part of their solution environment. Also because none of the services were reusable, there was less chance that new requirements could be even partially fulfilled by existing services.

With each programming modification came the overhead associated with the subsequent testing and deployment phases (for all services affected). This not only increased the ownership cost of each service, it also began morphing the services so that their underlying logic now exceeded the scope and context originally defined in their initial design.

SUMMARY OF KEY POINTS
The bottom-up strategy simply is based on the delivery of application services on an "as needed" basis. This common approach is easy to follow but does not result in the advancement of service-orientation or contemporary SOA.

Case Study

Категории