How case studies are used

This book weaves approximately 125 examples relating to these case studies throughout all subsequent chapters. This essentially establishes these two organizations as constant real-world reference points. Appendix A concludes this book by ending the storylines of both case studies and exploring the results of the organizations' respective transitions to SOA.

2.1.1. Style characteristics

To more easily identify these examples, we've incorporated a special style element. Any portion of the book (beyond Chapter 2) that discusses our case studies will contain a light gray background. Below is an example.

...Initially, there was no concern around this approach, as each application delivered its promised set of features and solved its corresponding business problems. However, because no strategy was used to ensure that XML and Web services were being applied in a standardized manner in support of SOA, there was nothing in place to prevent the resulting design disparity...

2.1.2. Relationship to abstract content

For those of you not interested in learning with case studies, you can consider these parts of the book as voluntary reading. None of the abstract descriptions reference or rely on the examples. They are provided only to further assist in communicating the purpose and meaning behind the concepts, technologies, and processes covered. Feel free to bypass shaded areas or perhaps only reference them when you need further elaboration on a given subject.

2.1.3. Code samples

The chapters that comprise Part V: Building SOA (Technology and Design) contain numerous case study examples with markup code. These code samples are used to demonstrate many of the technologies discussed.

This book has been designed so that the supplementary technology tutorials include descriptions of all of the language elements used in the case study code samples. (Note that there are three samples in Chapter 17 that introduce elements from languages that are not explained to demonstrate an aspect of a container element that is explained.)

2.2. Case #1 background: RailCo Ltd.

RailCo Ltd. is an established parts supplier for railways, specializing in air brakes and related installation tools. RailCo ships air brake parts internationally, but 90% of its sales are in North America. Though its primary line of business is product resale, RailCo also has a small group of specialized technicians that are hired out locally for installations and repairs.

2.2.1. History

Established in the early 90s, this company has gradually grown from a staff of 12 to 40. It started out as a brokerage for various railway wholesalers, but then came to specialize in air brakes. The narrowed business focus resulted in increased opportunities, as RailCo was able to become a wholesaler in its own right by dealing directly with air brake parts manufacturers.

2.2.2. Technical infrastructure

Five employees and one manager are dedicated to full-time IT duties, responsible primarily for maintaining client workstations and back-end servers. Custom development tasks have typically been outsourced to local consulting firms, whereas periodic upgrades and maintenance fixes have been the responsibility of in-house staff.

2.2.3. Automation solutions

RailCo's automated environment consists of the following applications:

A two-tier client-server system governing all accounting and inventory control transactions. Two administrative clerks manually feed this solution with standard transaction document data (primarily incoming and outgoing purchase orders and invoices). Receipt and submission of these documents typically initiates corresponding inventory receiving and order shipping processes.

A contact management system in which customer and business partner profile information is stored and maintained. This simple application consists of a database fronted by Web-based data entry and reporting user-interfaces. Users range from managers to administrative assistants and accounting personnel.

2.2.4. Business goals and obstacles

Profit margins have been noticeably declining over the past year. A recent review revealed that the overhead associated with RailCo's

Further investigation led to the discovery that this competitor has implemented an extension to their existing accounting system, allowing them to perform various transactions online via B2B solutions provided by some of the larger clients. They have subsequently been able to reduce the staff required for processing orders, while increasing response time and lowering their overall price point. A further unpleasant revelation was that RailCo's primary client, Transit Line Systems, has started an online relationship with this competitor as well.

RailCo is a company with outdated technology automating inefficient business processes. It is looking to overhaul its technical environment to better respond to new business trends and automation requirements.

To remain competitive and minimize losses, RailCo must upgrade its automation environment as soon as possible. Its top priority is to participate in online transactions with TLS. Before our storyline begins, RailCo has already hurried to build a pair of Web services (Figure 2.1) that enable it to connect with the existing TLS B2B solution. These services are explained and referenced as we progress through chapters discussing Web services technology.

Figure 2.1. RailCo's initial set of Web services, designed only to allow RailCo to connect to

TLS's B2B solution.

The design of this solution, though, is revisited and expanded in Part V. By that point RailCo runs into some limitations and decides to re-evaluate its environment in consideration of establishing an SOA. Further, RailCo realizes that it must also seek new clients to make up for the lost sales to TLS. This new requirement ends up also affecting the design of its SOA.

Note that though technically a Web service with its own WSDL, the Invoice Submission Service frequently acts as a service requestor, issuing invoice documents to a TLS Web service. It is important not to view this service as just a Web service client program. It begins to perform more of a provider role in later chapters where it evolves along with RailCo's SOA. Chapter 5 explains how services play both requestor and provider roles.