Case #1 background: RailCo Ltd.

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 current business processes is becoming less acceptable. Clients have been switching to a competitor providing the same products in a more efficient manner and at a lower cost.

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.


Case Studies

Part I: SOA and Web Services Fundamentals

Introducing SOA

The Evolution of SOA

Web Services and Primitive SOA

Part II: SOA and WS-* Extensions

Web Services and Contemporary SOA (Part I: Activity Management and Composition)

Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)

Part III: SOA and Service-Orientation

Principles of Service-Orientation

Service Layers

Part IV: Building SOA (Planning and Analysis)

SOA Delivery Strategies

Service-Oriented Analysis (Part I: Introduction)

Service-Oriented Analysis (Part II: Service Modeling)

Part V: Building SOA (Technology and Design)

Service-Oriented Design (Part I: Introduction)

Service-Oriented Design (Part II: SOA Composition Guidelines)

Service-Oriented Design (Part III: Service Design)

Service-Oriented Design (Part IV: Business Process Design)

Fundamental WS-* Extensions

SOA Platforms

Appendix A. Case Studies: Conclusion

Service-Oriented Architecture. Concepts, Technology, and Design
Service-Oriented Architecture (SOA): Concepts, Technology, and Design
ISBN: 0131858580
EAN: 2147483647
Year: 2004
Pages: 150
Authors: Thomas Erl © 2008-2020.
If you may any questions please contact us: