Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com Requirements analysis needs to establish what the service needs to do, its scope, and potential usage patterns. Given the much closer alignment of business needs that SOA demands, services will usually be business-relevant – however, there may also be infrastructure services needed to support a SOA. Infrastructure vendors in particular are identifying this need – for example, BEA Systems has coined the Requirements analysis needs to establish what the service needs to do, its scope, and potential usage patterns. phrase Micro Services Architecture to cover the way it sees the need break up its infrastructure tools into smaller pieces that can then be assembled to meet the diverse requirements of its customers in the future. The design and development phases may require platform-specific issues to be taken into account, such as the choice of programming language, and the development environment to be used. A number of the platform vendors provide SOA development tools (such as JDeveloper from Oracle), and there are additional vendors such as Skyway Software that offer specialist tools here. Developing composite applications in a SOA should, of course, focus heavily on reuse of existing services wherever possible, and this mindset must be encouraged from the outset. Sometimes it may not be possible to serviceenable an existing application, and it will need to be re-written in a new way. In addition, there will always be the need to create some completely new services. The mantra should always be to reuse first, then potentially recycle… and only finally develop new services from scratch. At the service deployment phase, a number of considerations come into play such as installing and configuring distributed components, service interfaces, and the necessary middleware products; and all of this from development to test to staging to production environments. Once services are deployed, ongoing administration will be required to include service monitoring and auditing, and to control the whole change management process. Packaging of all the artefacts required is unlikely to be fully present, given that the full breadth of the SOA paradigm is still evolving. The design and development phases may require platformspecific issues to be taken into account, such as the choice of programming language, and the development environment to be used. Once services are deployed, ongoing administration will be required to include service monitoring and auditing, and to control the whole change management process. Whilst it may not be highly desirable to allow a service to change over time, in practice it may be impossible to avoid this. The OASIS SOA Reference Model allows for versioning of services. Doing this helps to manage any interface changes. Clients of a service then have to be able to make a decision about which version of the service (with the older or the newer interface) they need. An iterative process to the development lifecycle will be necessary – it is unlikely that any organisation will get it all right the first time, even if they use the services of the most experienced vendors and services providers. It will be valuable to get a widespread understanding up-front so that not too much time is wasted doing things the wrong way. Not all services will be created in-house – in fact, it may be that the skills required at first are not available in-house. All the major Systems Integrators are investing heavily in SOA training and development, and many have already assisted in successful pilot projects. The optimal way to proceed with service-oriented development is to combine a top-down and bottom-up approach together. An imbalanced approach could risk ‘paralysis by analysis’ if too top down, and service creation for the sake of it can be too far the other way. Roles A complex SOA project is likely to entail a wide range of different skills that will require an understanding of the different roles needed when developing services within a SOA. A lot of this comes down to basic people issues – to ensure that there is an understanding of services at the right level. Service-oriented development can be a major challenge if developers do not understand the concept, and reuse will be minimal unless the services are designed in the right way. 28 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA IBM recommends that the development phase of a SOA project will require a number of roles, such as Software Architect, Developer (this may include application developer, component developer, and integration developer), Test Engineer, Test Architect, and Test Implementer. Whilst this may appear overkill, and sometimes these roles could be filled by one or two people, the identification of the different roles needed may help assemble the best project team. Planning the infrastructure for SOA will require careful thought. Planning for a SOA deployment will require capacity planning and hardware planning where estimates of service volumes need to be considered, as well as usage patterns. Such planning will not be straightforward; a SOA infrastructure is made up of many components, such as middleware, mediation and orchestration brokers (which may be part of an ESB), infrastructure integration services (such as for security, monitoring, and exception management), as well as BPM engines, and of course, the underlying network infrastructure. This may itself have many components that impact performance and capacity including routers, switches, traffic load balancers, and encryption (such as SSL) and transformation XML Stylesheet Language Transformation (XSLT) accelerators. When carrying out capacity planning for SOA, performance is probably one of the easier aspects to measure, yet even that can be a challenge given the distributed nature of SOA. Estimating the number of transactions that are likely to occur, the number of users accessing a service is also quite measurable. Composite applications may be made up from a number of services, and these may not all have the same SLA (especially over time), which may of itself lead to interesting decisions as to how to scale up the required infrastructure. A common approach would be to over-engineer the infrastructure – and certainly it would be wise to allocate budget to hardware at the outset of a SOA project. But some of the infrastructure elements can be very expensive if under-utilised (BPM engines are a particular example here). A pattern-based approach to capacity planning is one good option, taking into account a range of access patterns to the services that encompass simple and complex scenarios. A simple pattern might cover a validation service (using a schema, for example), a transformation from one format to another, and then publishing a message onto a queue. A more complex pattern might add in lookups and process management capabilities. The capacity planning process should then test the various scenarios and record results in order to then extrapolate based on peak load estimates. This peak should then be projected forward over time to forecast where additional capacity might be required in the future. Another part of infrastructure planning is to consider failover and disaster recovery – establishing how alternative infrastructure can be utilised and what the service failover options should be. In any serious project, failover should be designed in, and then tested to ensure that it works. Services within a SOA may be combined in unforeseen ways. When carrying out capacity planning for SOA, performance is probably one of the easier aspects to measure, yet even that can be a challenge given the distributed nature of SOA. A key issue in testing within a SOA is that it is not always clear, when designing a service, how it is going to be used. A service could be reused and combined with other services in ways that are not foreseen at the development phase, so services will therefore need rigorous testing to ensure that when the unpredictable happens, they cope. Testing in a SOA will encompass the ability to test Web services but also other types of service. As with any type of application or service, one of the first tests should be whether the service does what it is intended to do, in terms of the capabilities that it is intended to deliver. Such functional testing will also need to be carried out but issues such as unit testing, system testing, load testing, and overall performance all need to be addressed when testing is carried out, and where a service may have multiple bindings, each will need to be tested. December 2006 Section 1: SOA Deployment 29
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 27: 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?