Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com ANALYSIS There is a trade-off possible between performance and long-term agility, and this needs consideration before committing to a course of action. We need to be quite clear about the purpose of SOA: it is to provide improved utilisation of business functionality as delivered by application programs. This improved utilisation may take the form of better integration, creation of composite applications, automation of business processes, and the ability to allow The purpose of SOA is not to improve performance, and adding extra layers of software will inevitably have a performance impact. each of these to evolve over time as the business model changes. Because SOA is layered on top of application resources, it is never going to increase performance above the capabilities of the underlying systems. (Note, though, that end-to-end times could be reduced through the ability to execute multiple tasks in parallel instead of sequentially.) The purpose of SOA is not to improve performance, and adding extra layers of software will inevitably have a performance impact. However, everything has its price, and IT must continue to meet the processing workload and performance expectations of the organisation, SOA or not. Much of the performance overhead of SOA stems from the use of Web services. The role that Web services plays is to isolate the SOA control and run-time environment from the physical properties of the underlying services. With Web services, the ESB neither knows nor cares what physical platform a service executes on, what operating platform is used, or which language has been used to create the application. This virtualisation is the source of the overhead with which we must contend. Web services itself is built on top of XML, this being the commonly-accepted standard for technology-neutral messages. The message body itself may become quite large, since a common way of exploiting SOA is for the same basic message to be passed to each service in turn, with each enriching the message with the results of its own activity. (In this way the message itself retains the context required for subsequent operations.) Hence, in a complex multi-step process the body gets larger and larger. Additionally, the SOAP envelope contains information necessary for the routing of the message plus optional extensions such as the style of messaging needed (e.g. guaranteed once-only delivery), privacy requirements, public and private key tokens for encryption, and potentially many more. Thus the Web services message load can add significantly to the network traffic, and particularly where encryption is needed, to the server overhead for processing the message. For any but trivial use of SOA, encryption is likely to be mandatory, even inside the firewall. Web services standards provide for encryption of just sensitive parts of the message, and this option should always be used to reduce the processing overhead. We need to consider whether to compromise the logical design to accommodate the performance needed by the business – but first there is a general rule in IT (which is re-learned in every new generation of technology): The golden rule: Do not optimise unless you have to! Thus the Web services message load can add significantly to the network traffic, and particularly where encryption is needed, to the server overhead for processing the message. In this case, Web services plays a major role in delivering the adaptability we seek from SOA. By abstracting away the physical details of an application we gain great freedom to replace applications piecemeal, outsource to a hosted service provider, provide hot-standby facilities for critical services, and many other important capabilities. If we discard Web services in favour of more compact technology-specific messaging, we lose these capabilities. Therefore, the best advice is to carry out performance modelling for the projected system capacity and decide if it is truly necessary to optimise. 24 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA Network appliance alternatives to traditional server/software implementation can offer cost/performance benefits. As described earlier, the ESB is really a suite of functionality that provides the means of moving the right message, in the right format, to the right recipient, in the right sequence. Commercial ESB suites are themselves built on SOA principles so that functionality can be added without a major reconstruction of the environment. This is important for the ability to add governance features and other ‘optional’ properties to a live SOA environment. The architecture also means that services provided by the ESB can be removed or replaced by functionally-equivalent alternatives. This has enabled a sub-market of ESB features deployed as network appliances rather than as software on a server. This idea is a logical extension of several mainstream security features commonly implemented as appliances. In particular, firewalls were originally implemented as software on conventional servers. but have been implemented as network appliances as the mainstream deployment mechanism for many years. It is simply more cost-effective to deploy firewalls in this way. By the same logic, several services provided by an ESB might be more costeffective if removed from a general-purpose server and implemented instead as network appliances. Potential candidates for this treatment are XML firewall, XML schema parsing, XML encryption/decryption, content-based message routing, and possibly other functionality also. This approach offloads tasks from the server to free its resources for business-related work, and moves the network-centric logic down into the network itself. Several vendors provide products that are well-worth evaluating as part of an overall strategy for dealing with SOA performance. Again, because of the adaptability that SOA offers, these appliances can be retrofitted to an established SOA environment. Although the use of network appliances implies an additional expenditure, their use can defer the need for extra server capacity. The main advantage, however, is that they can make a significant difference to performance and throughput without having to compromise the SOA agility. Run-time deployment of SOA-based applications does not always mean using Web services. Any discussion of SOA tends to start out with the assumption of the use of Web services throughout. Wherever services are to be integrated that are outside of the corporate environment. it is still advisable to use Web services as the underlying mechanism. This is because security concerns can be dealt with more directly through the common standards provided by Web services, and because any use of proprietary interfaces will leave the parties unable to change their services without impacting their partners. An exception to this would be where a particular industry has already established standards that pre-date Web services (and preferably use a private network for communication rather than the public Internet). At the outset, it is worth pointing out that both .NET and J2EE are suitable deployment infrastructures for SOA. ...several services provided by an ESB might be more costeffective if removed from a generalpurpose server and implemented instead as network appliances. For internal deployment, there are several alternatives to the Web services paradigm. At the outset, it is worth pointing out that both .NET and J2EE are suitable deployment infrastructures for SOA. Within a .NET only or J2EE only environment, there are few adaptability compromises to be made, in return for which significantly reduced overheads can be expected. The objects natively exposed by Java and .NET may still take part in an orchestrated sequence of events as part of composite applications or automated business processes. However, security issues must be managed in the traditional way rather than letting ESB products be guided by the Web services policy statements. Greater constraints will be experienced if it is subsequently required to replace a native .NET or J2EE service with hosted software as a service. Common Object Request Broker Architecture (CORBA)-based applications have similar properties to J2EE and .NET in terms of their use within SOA. However, there are few substantial IT environments where it would be possible to implement a wide-reaching SOA solution within a single technology. In a mixed environment, without the use of Web services, the ESB has to be made aware of the physical properties of the services. This may be of little consequence in the initial deployment, but will be a constraint of future adaptability when the time comes to replace legacy applications. December 2006 Section 1: SOA Deployment 25
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 23: www.butlergroup.com Planning and Im
Page 31 and 32: www.butlergroup.com Technology Mana

Planning_and_Impleme.. - didier beck weblog

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?