4.3.1 Need for an ArchitectureMany systems are deployed today without a reliable, scalable architecture and thus suffer from capacity and performance issues. Some of them do not have reusable components. With an eye toward cost-reduction, there is a need to leverage application component framework and technical infrastructure investment by focusing on opportunities that can leverage reusable components . Many Web Services initiatives today begin and end with SOAP-UDDI programming, yet lack a framework for reusable components, scalability, and performance management. One goal of Web Services technology is to better leverage limited component frameworks, distributed services, and platform and network engineering resources. 4.3.2 The Architecture NirvanaThe term architecture has been overloaded with different meanings. It can denote a system, product components, or an infrastructure. There are many architectures labeled under Web Services today. While they may offer good contributions to the field, some are primarily a rebranding of vendor product architecture. A product architecture that lacks structure and guiding principles would not be useful for scalable and reliable Web Services. Both the previous chapter Web Services Technology Overview, and Appendix B provide a sampler of Web Services architectures. Which should a customer choose to implement? This chapter introduces a framework and reference architecture for building scalable and reliable Web Services. 4.3.3 Benefits of an ArchitectureA structured Web Services architecture framework enables developers to build reusable components, distributed services, and sharable systems infrastructure (for example, server, storage, network, performance, and availability management). This can help improve programmer productivity (speed), compress development cycles (speed), reduce infrastructure and support costs (cost), mitigate risk through use of pretested components (quality), and enhance Quality of Services, such as scalability and availability (quality). |