| The following architecture principles present a high-level discussion of how to architect Web Services solutions. Some of these guiding principles are similar to architecting any IT solution, but they are discussed in Web Services technology context. They can be used as a checklist prior to reviewing a Web Services project proposal or a design artifact. In this section, the ground rules (aka corollary) refer to the extension of the associated high-level architecture principles, or any proposition inferred from the principle. 4.5.1 General Principles Principle 1. You should build a Web Services-based solution to satisfy user requirements at the time of delivery, where user requirements may evolve with a better understanding of the system and integration capability. You should use iterative requirements analysis techniques to avoid rigid requirements. You must drive integration and interoperability requirements from the business vision. You should not create the impression that you are implementing the idea for technology's sake. Rather, you should focus on broader architecture items and system reusability. Some architects kick off Web Services projects without a business vision. They may start from a technical perspective, wanting to be in the state-of-the-art technology areas (gimmick). These Web Services projects may not have any supporting user requirements. For example, developers may modify an existing sample wireless Web Services program as a proof of concept. However, they may overlook the architecture complexity of wireless security, the memory constraints, and any associated performance issues of the mobile device (that is, the broader architecture items). Principle 2. You should achieve business results through a series of successes by breaking down any large and high-risk Web Services initiatives into a small and manageable number of pieces. Besides, you can deploy a small series of projects that are cohesive to the bigger picture of the Web Services initiative. Next, you would like to avoid re-engineering the entire business process while achieving a small success. People may perceive the focus as business changes. For example, if the Web Services project is anticipated to be a large-scale application implementation with 24 elapsed months, then it is better to split the project into smaller projects of three to four months' duration (also refer to ground rule 4). Principle 3. You should mitigate business and technology risks with pilot or reusable prototypes . Traditional development methodology requires lengthy requirements and design processes, before a pilot or prototype can be produced. You may choose to use an iterative development process with appropriate user involvement for feedback (such as a Use Case workshop). Ground Rule 1. Web Services solution release must deliver quantifiable business value (for example, a Web Services solution to address the market connectivity between brokerage firms to achieve Straight-through Processing should bring cost savings of around $100,000 dollars annually). Ground Rule 2. The cost of Web Services infrastructure and integration implementation (for example, the implementation cost for UDDI and SOAP server) should not exceed the business value delivered (such as the sum of cost savings or additional revenue generated from delivering all Web Services solutions). This needs to be expanded in the business case justification. For example, it would not make sense to invest in a $10 million Web Services infrastructure implementation of UDDI Service Registry, while the anticipated revenue of deploying a Service Registry is US$10,000 per year. Ground Rule 3. Architects should avoid time-consuming analysis of current states and interoperability constraints. This is because Web Services implementation is not intended to re-engineer the entire enterprise architecture (which is usually done by analyzing current states and interoperability). The Web Services technology is suitable for exposing business services and system functionality from legacy systems (aka black-box systems) without refactoring or re-engineering them. This enables a fast interoperability solution. For example, it is not recommended to re-engineer the business process of securities trading (for Straight-through Processing) while implementing a new messaging infrastructure using SOAP messaging over JMS. This will add to the project implementation risks. Ground Rule 4. You should time-box any Web Services into a three- to five-month delivery time window. Ground Rule 5. You should exploit reusable prototype (with performance benchmarking) to mitigate business and technology risks. 4.5.2 Lower Platform Layer Principle 4. Web Services technology operates independent of the Operating System or the Lower Platform. However, the availability of Web Services solutions is dependent on the reliability and availability of the Lower Platform (such as hardware and software clustering, High Availability configuration, and system management). Ground Rule 6. You should always consider and include the hardware and software level's reliability and availability (for example, clustering or hot fail-over ) during the Web Services implementation. Typically, UDDI or ebXML Service Registry and SOAP appliances are examples of service components where the hardware and software's reliability and availability will be of great importance. 4.5.3 Upper Platform Layer Principle 5. Web Services solutions can run on any Web or servlet container (such as Tomcat), not necessarily on an EJB container. However, it will still be architecturally neat to have the same vendor servlet container for the same operating environment. Most RPC-based SOAP calls do not manage session or state. Keeping track of the states for each call or every child process may not be necessary or desirable for some RPC-based (synchronous) Web Services for performance reasons. Ground Rule 7. Many Web Services calls are stateless beans making RPC calls. You may still want to store the session information (such as who has initiated a payment request, and when) when you initiate a SOAP call in order to support Single Sign-on and identity management. This will allow the security infrastructure (such as identity server) to track each security session and Web Services management tools to meter the remote business services for billing or performance-monitoring purposes. Ground Rule 8. You should not store the state of the Web Service if it spans different legacy systems or multiple nodes, as that requires extremely complex application design to support multiphase commit and rollback. For example, if developers want to aggregate account balances from multiple banking systems to provide a consolidated investment portfolio using synchronous Web Services (say, JAX-RPC), they should not persist the session state of each connection to the individual banking system. Otherwise, if one connection fails, the account balance aggregation service may hang up the entire application (thus, performance overhead). If one of the connections with the banking system needs to make a secondary RPC call to perform a business transaction and the secondary RPC call aborts with an exception, should the developer roll back the transactions or not? This may be a complex design issue to address, if the states of each connection or RPC calls are persisted and tracked. 4.5.4 Virtual Platform Layer Principle 6. The message exchange between the SOAP Service Provider and the SOAP consumer can be one-way (asynchronous) or two-way (synchronous), bound to the data transport such as HTTP, SMTP, JMS, and so forth. The choice of synchronous messaging is appropriate for the RPC application model. Asynchronous messaging is appropriate for sending or receiving XML documents and can be supplemented by SOAP-JMS binding for guaranteed message delivery. Business transactions and business process orchestration often require reliable messaging infrastructure to support. Without reliable messaging, Service Requesters do not know the requests have been received and processed by the Service Provider. This will result in potential financial loss. Ground Rule 9. If guaranteed message delivery is required, then use asynchronous SOAP calls with SOAP-JMS binding (SOAP messages bind to a reliable messaging layer using JMS). This addresses the issue of the reliability of SOAP messaging over HTTP. There are vendor products that provide JMS bridge functionality to bind SOAP messages to JMS; developers need not build this functionality from scratch. 4.5.5 Application Platform Layer Principle 7. It is easier to wrap a legacy system with a SOAP client proxy. However, be coarse-grained, and do not wrap every functional call. Some SOAP calls can be cached with a time period if the data is relatively static within the predefined time period. Ground Rule 10. The Web Services calls should be coarse-grained when defining new business services from an existing system. For instance, if an EJB has 100 methods of inquiring about a customer account, it will not be practical to expose all 100 methods as Web Services. A coarse-grained approach to exposing business functionality as Web Services may suggest three to five Web Services calls, where similar account information can be encapsulated into one Web Services call. | 