Planning_and_Impleme.. - didier beck weblog
Planning_and_Impleme.. - didier beck weblog
Planning_and_Impleme.. - didier beck weblog
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Planning</strong> <strong>and</strong> <strong>Impleme</strong>nting SOA<br />
www.butlergroup.com<br />
Requirements analysis needs to establish what the service needs to do, its scope, <strong>and</strong> potential usage<br />
patterns. Given the much closer alignment of business needs that SOA dem<strong>and</strong>s, services will usually be<br />
business-relevant – however, there may also be infrastructure services needed to support a SOA.<br />
Infrastructure vendors in particular are identifying this need – for example, BEA Systems has coined the<br />
Requirements analysis<br />
needs to establish<br />
what the service<br />
needs to do, its scope,<br />
<strong>and</strong> potential usage<br />
patterns.<br />
phrase Micro Services Architecture to cover the way it sees the need break up<br />
its infrastructure tools into smaller pieces that can then be assembled to meet<br />
the diverse requirements of its customers in the future.<br />
The design <strong>and</strong> development phases may require platform-specific issues to be<br />
taken into account, such as the choice of programming language, <strong>and</strong> the<br />
development environment to be used. A number of the platform vendors provide<br />
SOA development tools (such as JDeveloper from Oracle), <strong>and</strong> there are<br />
additional vendors such as Skyway Software that offer specialist tools here.<br />
Developing composite applications in a SOA should, of course, focus heavily<br />
on reuse of existing services wherever possible, <strong>and</strong> this mindset must be<br />
encouraged from the outset. Sometimes it may not be possible to serviceenable<br />
an existing application, <strong>and</strong> it will need to be re-written in a new way.<br />
In addition, there will always be the need to create some completely new<br />
services. The mantra should always be to reuse first, then potentially recycle…<br />
<strong>and</strong> only finally develop new services from scratch.<br />
At the service deployment phase, a number of considerations come into play<br />
such as installing <strong>and</strong> configuring distributed components, service interfaces,<br />
<strong>and</strong> the necessary middleware products; <strong>and</strong> all of this from development to<br />
test to staging to production environments.<br />
Once services are<br />
deployed, ongoing<br />
administration will be<br />
required to include<br />
service monitoring<br />
<strong>and</strong> auditing, <strong>and</strong> to<br />
control the whole<br />
change management<br />
process.<br />
Packaging of all the artefacts required is unlikely<br />
to be fully present, given that the full breadth of<br />
the SOA paradigm is still evolving.<br />
The design <strong>and</strong><br />
development phases<br />
may require platformspecific<br />
issues to be<br />
taken into account,<br />
such as the choice of<br />
programming<br />
language, <strong>and</strong> the<br />
development<br />
environment to be<br />
used.<br />
Once services are deployed, ongoing administration will be required to include<br />
service monitoring <strong>and</strong> auditing, <strong>and</strong> to control the whole change<br />
management process. Whilst it may not be highly desirable to allow a service<br />
to change over time, in practice it may be impossible to avoid this. The OASIS<br />
SOA Reference Model allows for versioning of services. Doing this helps to<br />
manage any interface changes. Clients of a service then have to be able to<br />
make a decision about which version of the service (with the older or the<br />
newer interface) they need.<br />
An iterative process to the development lifecycle will be necessary – it is unlikely that any organisation will<br />
get it all right the first time, even if they use the services of the most experienced vendors <strong>and</strong> services<br />
providers. It will be valuable to get a widespread underst<strong>and</strong>ing up-front so that not too much time is wasted<br />
doing things the wrong way.<br />
Not all services will be created in-house – in fact, it may be that the skills required at first are not available<br />
in-house. All the major Systems Integrators are investing heavily in SOA training <strong>and</strong> development, <strong>and</strong><br />
many have already assisted in successful pilot projects.<br />
The optimal way to proceed with service-oriented development is to combine a top-down <strong>and</strong> bottom-up<br />
approach together. An imbalanced approach could risk ‘paralysis by analysis’ if too top down, <strong>and</strong> service<br />
creation for the sake of it can be too far the other way.<br />
Roles<br />
A complex SOA project is likely to entail a wide range of different skills that will require an underst<strong>and</strong>ing<br />
of the different roles needed when developing services within a SOA. A lot of this comes down to basic<br />
people issues – to ensure that there is an underst<strong>and</strong>ing of services at the right level. Service-oriented<br />
development can be a major challenge if developers do not underst<strong>and</strong> the concept, <strong>and</strong> reuse will be<br />
minimal unless the services are designed in the right way.<br />
28 Section 1: SOA Deployment<br />
December 2006