A.2. Transit Line Systems Inc.

TLS had already built a service-oriented solution when we began our timeline in this book. It successfully established a B2B environment that facilitated online transactions with multiple vendors.

The application was comprised of business and application service layers that consisted of the following services:

• Accounts Payable Service
• Purchase Order Service
• Vendor Profile Service
• Ledger Service
• Load Balancing Service
• Internal Policy Service
• Notification Service (added later)

As you may recall, TLS did not actually require the use of a task-centric or process service. Its Accounts Payable and Purchase Order Services already contained the necessary business logic to receive invoices and issue purchase orders.

TLS decided to continue investing in SOA to address two critical business goals:

• The need to increase the responsiveness of its IT environments so that changes to its business models (which occur relatively frequently) can be accommodated without major disruptions.
• The need to establish a federated environment to standardize the many different systems it has accumulated through acquisitions and partnerships.

As part of TLS's SOA initiative, it chose to proceed with a second service-oriented solution: the automation and validation of timesheet submissions. This next project was also tasked with some extra analysis to study different service layer configurations. Because of recent technology upgrades, TLS is in a position to explore options that were not available when they built their first solution.

TLS proceeded through an elaborate service-oriented analysis phase during which it modeled a series of service candidates that collectively represented the business process logic identified in the required Timesheet Submission Process. It then went on to compare three different service layer configurations. It finally decided to proceed with the following configuration:

• An orchestration service layer establishing a single process service.
• A business service layer consisting of three entity-centric business services.
• An application service layer consisting of one application service (and two additional services that were added later).

The use of an orchestration service layer was new to TLS, as its previous platform did not provide support for an orchestration engine. After going through the service-oriented design process, interfaces for the following individual services were built:

• Employee Service (entity-centric)
• Timesheet Service (entity-centric)
• Invoice Service (entity-centric)
• Notification Service (application)
• Human Resources Service (application)

Additionally, it was discovered that the existing Accounts Payable Service created for the B2B solution would be able to facilitate the processing requirements of the planned Invoice Service. This reuse opportunity was leveraged, and the Accounts Payable Service was enlisted to support this process as well.

Next, TLS carried its existing process workflow logic over to the service-oriented business process design stage. It established a WS-BPEL process definition to encapsulate the workflow logic for the Timesheet Submission Process. This process definition coordinated the activities of all services and successfully realized the planned orchestration service layer (Figure A.3).

Figure A.3. The service layers established by TLS's new SOA.

TLS proceeded to build this solution but for various reasons decided to create it using a different development platform from the one used to deliver the original B2B system. It took advantage of the availability of a group of .NET consultants and chose to develop the Timesheet Submission solution as a .NET application. The rationale was that it would prove interoperability with its existing J2EE services and eventually increase the diversity of its internal skill-set.

By building this second service-oriented solution, TLS has taken small but important steps toward realizing its primary goals, as follows:

• By successfully establishing an orchestration service layer, TLS can now utilize this layer for future solutions. Because orchestration was introduced early on, TLS can standardize on centralized business process abstraction without any real retrofitting.
• By continuing to add to its initial set of entity-centric business services, TLS furthers its goal of increasing organizational agility. An orchestration layer, coupled with a layer of entity-centric business services, establishes a solid foundation for business logic abstraction. This also results in a loosely coupled relationship with the expanding application services layer. Future response times are expected to decrease as these two abstraction layers continue to grow.
• By exposing functionality from their legacy timesheet and HR systems and by further abstracting parts of their accounting solution, TLS is building an increasingly federated environment. It is anticipated that the cost of integration projects involving federated applications will drop significantly.

A subsequent corporate planning session results in a list of new strategic goals for TLS, one of which happens to be the purchase of an air brake supplier. This would give TLS all the air brake parts they need at wholesale cost and would also open up a potential new business area.

Upon subsequent investigation, TLS identifies a number of acquisition candidates. RailCo Ltd. ranks high on this list. One of the benefits documented in the evaluation report on RailCo is the fact that its automation solution environment contains standardized, service-oriented applications and legacy endpoints.

This appealed to the TLS architects who were asked to assess the IT environments of each candidate. Inspired by the success of their second service-oriented solution, TLS IT managers asked architects to favor candidates with standardized service-oriented environments. With RailCo they recognized an opportunity to leverage existing SOAs for an easier and more cost-effective integration effort.