Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com There are also successful SOA deployments using Z/OS IBM mainframes (albeit using a Web services mechanism), ‘green-screen’ UNIX applications that pre-date client/server, and even very elderly proprietary operating environments. However, we should differentiate between enabling these legacy platforms for use in a SOA, and deploying a non-standards-based approach. Using adapters to expose the underlying service functionality of legacy applications is part and parcel of the SOA model, provided that the adapters offer a Web services messaging interface. Adapters might be Commercial Off-The-Shelf (COTS), customised COTS, or entirely custom-built. Technology that bears a striking resemblance to the screen-scraping used by early client/server deployments can be used to obtain access to applications for which no other mechanism is available. Many vendors that support legacy products are very happy to provide Web services adapters to their applications, or connectors to the underlying platform. For example: IBM’s CICS transaction server can operate in a SOA environment in a number of different ways. First of all CICS directly supports Web services interactions, but can also work with WebSphere application server clients via Java Connector Architecture (JCA). It can also operate with an ESB, as well as a Web services gateway, providing considerable flexibility to those organisations that need to continue to use their legacy CICS systems, but want to enable reuse within SOA projects. During 2006, BEA Systems announced that it was enhancing its legacy Tuxedo infrastructure with SALT – Service Architecture Leveraging Tuxedo. BEA’s SALT is a way of service-enabling its Tuxedo platform by providing a native Web services layer on top of Tuxedo. Tuxedo is built on BEA’s Application-to- Transaction Monitor Interface (ATMI) architecture, allowing both C and COBOL programming. It is a transaction server built on UNIX, comparable to the IBM mainframe CICS transaction server, suitable for complex, transaction-based applications such as billing. What SALT brings is like an ‘ESB for transactions’ – it implements an XA standard, so that transactions either happen or not – there is no grey area (in other words one part of a transaction is automatically undone if the overall transaction fails to complete). It offers two-phase commit capability. Oracle is introducing the idea of Service Beans in its next version of the Oracle E-Business Suite. These will allow the underlying services within the suite to be deployed in a range of different ways – as EJB Session Beans; as Web services; or as co-located Java API. The service bean encapsulates the implementation details, and provides a consistent and easy-to-use interface, allowing them to be used as building blocks within a SOA. Such services are then available for BPEL process management, and they can consume and output Service Data Objects (to the JSR 235 specification). High-performance SOA need not be an oxymoron, but good understanding of issues is needed. This Section has outlined some of the performance challenges and some of the potential solutions. The question now is how to achieve the best compromise between agility and performance. The natural inclination within IT (charged for many years with squeezing a growing workload into a diminishing technology budget) is to look for the high performance solution. However, this is not the best approach in these new circumstances. The challenge here is to model the services that are meaningful to the business and then map these to the underlying application(s) that can support the service. Since SOA is architecture, we should be able to separate the logical design from the physical. The logical service architecture should be designed only considering the business requirements to ensure the maximum reuse of services. The challenge here is to model the services that are meaningful to the business and then map these to the underlying application(s) that can support the service. This may not be a one-to-one mapping – in order to satisfy the requirements of a business service it might be necessary to integrate several applications. Equally, each application is likely to provide a range of functionality that is best divided between logical services. The scope of this analysis should be constrained to the project in question, but using the business analyst’s experience and insight to determine where reuse will be possible in subsequent projects. The next step is to form a model for the likely performance characteristics of each service, and to use capacity planning tools to determine the infrastructure requirements to support the anticipated workload. The market for SOA capacity planning is maturing well, with a variety of competent products now available. 26 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA The capacity planning exercise will show where there is a need to apply optimisation. The minimum optimisation to meet targets is a more appropriate target than reducing the run-time overhead to the absolute minimum. The first targets for optimisation should be the situation where a number of small, lowlevel services are aggregated to create a widely-used service, and where there is little or no requirement for direct use of the low-level services. In this instance, direct native calls to the low-level services can be made with little adverse impact. In fact, this interchange could bypass the ESB entirely, with the high-level service making direct RPC calls to the required applications. The important step in this optimisation is that the original logical model should be retained, and the nature of the optimisation, together with the reasons for the decision to optimise should be recorded. The Chief Architect should review all such cases to ensure the best compromise has been reached. Other optimisation considerations include: Ensuring that encryption is truly necessary, and only applying encryption to the sensitive portions of a large message. Consider breaking multi-function services down into several simpler single-function services (as the simpler service will have simpler and smaller message requirements). Consider using alternative messaging protocols to HTTP for inside-the-firewall deployment. Consider the use of Binary XML or compression to reduce the size of XML messages. Consider physically relocating services to minimise network overheads. Whatever trade-offs are made for the sake of performance, it is important that it is not treated as a one-person decision that is the responsibility of a technical architect. The impact on agility and the ability to meet the forward plans of the business must be considered, alongside each compromise of the ideal architecture. SERVICE-ORIENTED DEVELOPMENT CATALYST A key challenge to organisations when getting to grips with SOA is in the development area. It is no longer about application development, it is about service development, yet understanding the impact on the development function can be complex. SUMMARY There is a SOA lifecycle in the same way as there is an application development lifecycle. Planning the infrastructure for SOA will require careful thought. Services within a SOA may be combined in unforeseen ways. SOA and Agile can be complementary. ANALYSIS There is a SOA lifecycle in the same way as there is an application development lifecycle. Development pressures in the past have always meant that applications are developed with little thought for reuse, change, or integration. This mindset will need to change in a SOA environment. However, it is clear that there is a lifecycle for SOA just as there is for earlier types of application development. December 2006 Section 1: SOA Deployment 27
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 25: www.butlergroup.com Planning and Im
Page 31 and 32: www.butlergroup.com Technology Mana

Planning_and_Impleme.. - didier beck weblog

Create successful ePaper yourself

Delete template?

Save as template?