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:
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:
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:
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:
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:
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.