Đang tải... (xem toàn văn)
Planning a Service-Oriented Architecture
an Developer eBookPlanning a Service-Oriented Architecture Over the last four decades, software architectureshave attempted to deal with increasing levels ofsoftware complexity. But the level of complexitycontinues to increase and traditional architectures seem tobe reaching the limit of their ability to deal with the problem. At the same time, the traditional needs of IT organisa-tions persist, such as theneed to respond quickly tonew requirements of thebusiness, the need to con-tinually reduce the cost of ITto the business, and theability to absorb and inte-grate new business partnersand new customer sets, toname a few. As an industry,we have gone through mul-tiple computing architec-tures designed to allow fullydistributed processing; pro-grammeming languagesdesigned to run on any plat-form, greatly reducing implementation schedules; anda myriad of connectivity products designed to allowbetter and faster integration of applications. However,the complete solution continues to elude us. Service Oriented Architecture (SOA) is seen as the nextevolutionary step in software architecture to help ITorganisations meet their ever more complex set ofchallenges. According to IBM, the SOA market nearlydoubled in 2005 to more than £2 billion and could top£7 billion by 2009.The W3C Web ServicesArchitecture Working Groupdefines SOA as a form ofdistributed systems architec-ture that is typically charac-terised by the followingproperties:• Logical view: The serviceis an abstracted, logical viewof actual programmes, data-bases, business processes,and the like, defined interms of what it does, typi-cally carrying out a business-level operation.• Message orientation: The service is formally definedin terms of the messages exchanged between provideragents and requester agents, and not the properties ofthe agents themselves. The internal structure of an2Planning a Service-Oriented Architecture, an Internet.com Developer eBook. Copyright 2008, Jupitermedia Corp.Planning a Service-Oriented Architecture[]Planning a Service-Oriented ArchitectureJupiterimagesService Oriented Architecture (SOA) is seen as the next evolutionary step in software architecture to help IT organisations meet their ever more complex set of challenges.“” agent -- including features such as its implementationlanguage, process structure, and even database struc-ture -- are deliberately abstracted away in the SOA. Byusing the SOA discipline, one does not and should notneed to know how an agent implementing a service isconstructed. A key benefit of this concerns so-calledlegacy systems. By avoiding any knowledge of theinternal structure of an agent, one can incorporate anysoftware component or application that can be"wrapped" in message handling code that allows it toadhere to the formal service definition.• Description orientation: A service is described bymachine-processable meta data. The description sup-ports the public nature of the SOA: Only those detailsthat are exposed to the public and important for theuse of the service should be included in the descrip-tion. The semantics of a service should be document-ed, either directly or indirectly, by its description.• Granularity: Services tend to use a small number ofoperations with relatively large and complex messages.• Network orientation: Services tend to be orientedtoward use over a network, though this is not anabsolute requirement.• Platform neutral: Messages are sent in a platform-neutral, standardised format delivered through theinterfaces. XML is the most obvious format that meetsthis constraint.A service-oriented architecture allows for software sys-tems to be designed that provide services to otherapplications through published and discoverable inter-faces, and where the services can be invoked over anetwork. When you implement a service-oriented archi-tecture using Web services technologies, you create anew way of building applications within a more power-ful and flexible programming model. Development andownership costs as well as implementation risks arereduced. SOA is an architecture and a programmingmodel, a way of thinking about building software. ■3Planning a Service-Oriented Architecture, an Internet.com Developer eBook. Copyright 2008, Jupitermedia Corp.Planning a Service-Oriented Architecture[]1. First and foremost, leverage existing assets. Existingsystems can rarely be thrown away, and often containwithin them great value to the enterprise. Strategically,the objective is to build a new architecture that willyield all the value hoped for, but tactically, the existingsystems must be integrated such that, over time, theycan be componentised or replaced in manageable,incremental projects.2. Support all required types or "styles" of integration.This includes: • User Interaction: being able to provide a single,interactive user experience• Application Connectivity: communications layer thatunderlies all of the architecture• Process Integration: choreographs applications andservices• Information Integration: federates and moves theenterprise data• Build to Integrate: builds and deploys new applica-tions and services.3. Allow for incremental implementations and migrationof assets. This will enable one of the most criticalaspects of developing the architecture: the ability toproduce incremental ROI. Countless integration proj-ects have failed due to their complexity, cost, andunworkable implementation schedules.4. Include a development environment that will be builtaround a standard component framework, promotebetter reuse of modules and systems, allow legacyassets to be migrated to the framework, and allow forthe timely implementation of new technologies.5. Allow implementation of new computing models --specifically, new portal-based client models, grid com-puting, and on-demand computing. ■Requirements for a Service-Oriented Architecture The success of many Web services projects has shownthat the technology does in fact exist whereby you canimplement a true service-oriented architecture. It letsyou take another step back and not just examine your appli-cation architecture, but the basic business problems you aretrying to solve. From a business perspective, it's no longer atechnology problem; it is a matter of developing an applica-tion architecture and framework within which business prob-lems can be defined and solutions can be implemented in acoherent, repeatable way.First, though, it must be understood that Web servicesand a service-oriented architecture are not the samething. Web services are a collection of technologies --including XML, SOAP, WSDL, and UDDI -- which letyou build programming solutions for specific messag-ing and application integration problems. Over time,you can reasonably expect these technologies tomature, and eventually be replaced with better, moreefficient, or more robust ones, but for the moment,they will do. They are, at the very least, a proof of con-cept that SOAs can finally be implemented. So whatactually does constitute a service-oriented architecture?SOA is just that, an architecture. It is more than anyparticular set of technologies, such as Web services; ittranscends them, and, in a perfect world, is totally inde-pendent of them. Within a business environment, apure architectural definition of a SOA might be some-thing like "an application architecture within which allfunctions are defined as independent services withwell-defined invokable interfaces which can be called indefined sequences to form business processes." Notewhat is being said here:1. All functions are defined as services. This includespurely business functions, business transactions com-posed of lower-level functions, and system service func-tions. 2. All services are independent. They operate as"black boxes." External components neither know norcare how they perform their function, merely that theyreturn the expected result.3. In the most general sense, the interfaces areinvokable; that is, at an architectural level, it is irrele-4Planning a Service-Oriented Architecture, an Internet.com Developer eBook. Copyright 2008, Jupitermedia Corp.Planning a Service-Oriented Architecture[]Not Just Web ServicesWith the launch of something it calls the RetailIntegration Framework (RIF), IBM gaveprospective customers and its competitors apreview of what it has in store for SOA-enablement inthe coming year. RIF isn't a product but rather an enterprise softwarearchitecture, or framework, designed to help fill in thegaps between packaged software applications and lega-cy systems to help speed the implementation of new cus-tomer-focused strategies and technology initiatives inan SOA environment. This particular platform, happens to focus on the retailvertical. But expect IBM to serve up a steady diet ofindustry-specific and even process-specific announce-ments through the rest of this year. "This is kind of the direction we're heading," TomRosamilia, general manager of IBM's application and inte-gration middleware group, said in an interview withInternetNews.com. "RIF is one of a string of announce-ments where you'll see more customisation work by indus-try. We're taking SOA into the industry space to helpspeed the time to deployment. That's what it's all about." RIF is based on open standards and features retail-specif-ic components, templates and patterns geared to improvethe integration of business processes such as new prod-uct rollouts, cross-channel or selling, point of sale (POS)integration, store-to-enterprise integration and retailingbusiness intelligence. It's based on open standards thatintegrate with IBM's WebSphere middleware. Because most large retailers are opting for packagedapplications from the likes of Microsoft, Oracle and SAPrather than building their own proprietary and morecustomised systems, there's a greater opportunity toleverage fragmented applications and processes andreuse them again and again across the enterprise. For example, if one application in the marketing depart-ment can get to customer or inventory data in one partof the organisation and quickly share it with the salesteam in another division of the company without havingto buy or write another application, a company can startgetting some tangible return on its SOA investment. Butconnecting the two departments and, typically, disparatesoftware systems in a smooth fashion without disruptingthe day-to-day operations remains a bit tricky. -- InternetNews.com vant whether they are local (within the system) orremote (external to the immediate system), what inter-connect scheme or protocol is used to effect the invo-cation, or what infrastructure components are requiredto make the connection. The service may be within thesame application, or in a different address space withinan asymmetric multiprocessor, on a completely differ-ent system within the corporate intranet, or within anapplication in a partner's system used in a B2B configu-ration.In all this, the interface is the key, and is the focus ofthe calling application. It defines the required parame-ters and the nature of the result; thus, it defines thenature of the service, not the technology used toimplement it. It is the system's responsibility to effectand manage the invocation of the service, not the call-ing application. This allows two critical characteristics tobe realised: first, that the services are truly independ-ent, and second, that they can be managed.Management includes many functions, including:1. Security: authorisation of the request, encryptionand decryption as required, validation, and so forth.2. Deployment: allowing the service to be redeployed(moved) around the network for performance, redun-dancy for availability, or other reasons.3. Logging: for auditing, metering, and so on.4. Dynamic rerouting: for fail over or load balancing5. Maintenance: management of new versions of theservice ■5Planning a Service-Oriented Architecture, an Internet.com Developer eBook. Copyright 2008, Jupitermedia Corp.Planning a Service-Oriented Architecture[]Why adopt service SOA in the first place? The mainreasons are eminently practical and driven by eco-nomics because SOA adoption represents a clearpath for IT organisations to reduce cost and to improveoperational efficiency whilst bringing in agility and competi-tiveness for their companies. Let's look at the fundamental problem today. Let's takeas an example a typical Fortune 500 corporation. Thiscompany might gross £20.5 billion a year and have anIT organisation with a budget of about £563 million andabout 6,000 employees. Out of that budget, a figure of merit is the breakdownbetween dollars spent sustaining existing services("legacy" costs) versus dollars spent in new services.The dollars in the second category are the ones associ-ated with growth and business innovation. Studies from Gartner and Aberdeen put the fractiondedicated to legacy anywhere between 70 and 80 percent, depending on the company with the lower num-bers associated with the more progressive companies. Because of competitive pressures, and in spite of theeconomic recovery that's going into the fifth year, typi-cal IT budgets have remained flat or growing slowly,whilst the cost of legacy tends to grow with the compa-ny. Left unchecked, the cost of legacy will overwhelmthe IT budget. One strategy to lower the cost of legacy is through out-sourcing/offshoring and the ensuing cost arbitrage. Thearbitrage can be geographic and taking advantage oflower salary scales in some countries, or through divi-sion of labor, where an efficient, specialised firm deliv-ers a service such as payroll at a lower cost than the in-sourced cost. Offshoring entails a learning curve and cost bumpwhere the transition negotiations take place and con-sultants from the service provider are brought in. Thereis an initial cost decrease after the transition due tostaffing reductions. Although lower initially, legacy cost follows a steeperslope because salaries in Bangalore are growing muchfaster than salaries in the United States and Europe.Eventually, a new stasis is reached when the cost of theoutsourced service plus overhead reaches parity withthe in-sourced cost. And not every service can be outsourced. Outsourcinga company's core activities might lead to loss of intel-lectual assets and collective knowledge that will limit anSOAs to Lower Legacy Costs and Free Up Manpower organisation's growth potential. Outsourcing could alsoimpact customer satisfaction, quality-of-service andemployee morale that might hurt the organisation inthe long term. Technology refreshes provide an alternative. Theserefreshes have a deflationary effect. A strategic empha-sis to aggressively adopt emerging technologies willlead to reductions in capital outlays and cost of labor.Every refresh slides the cost line down. These transitions are not without risk and must be man-aged carefully. However, the rewards can be veryattractive. For instance, investing in server consolida-tion increases a system's capability to handle biggerworkloads with minimal data centre new investment. SOA & Legacy SOA adoption brings more fundamental change, lower-ing the legacy curve and its growth. Moreover, SOAdoes not exclude outsourcing and technology adop-tion. In fact, it might provide a more rational frameworkfor their application, with clean interfaces to mix andmatch in-house and outsourced composable serviceswith feedback based on business outcomes. The adoption of SOA becomes attractive if it can beshown that it leads to a structural and permanentreduction of the current 70% legacy cost by 10 to 20per cent. Through elimination of redundancy andbreaking silos, SOAs should bring increased opera-tional simplicity allowing dialing cost increases to a sus-tainable rate. The elimination of redundancy and a 15% increase inefficiency would be equivalent to hiring 1,000 staffwithout actually increasing headcount, accomplishedthrough the use of standardised platforms, simplifiedoperating environments. The adoption of SOA won't be without pain. Many jobdescriptions will change. An overall strategy requires anEA governance structure, consolidation of projects intofewer and deeper activities, and more consumption ofreusable components. This transition will take time. The cost curve will continue running its course for atime, and eventually tapers off as an increasing propor-tion of applications are brought up under a SOA frame-work. When the processes have been institutionalised, this1,000 headcount truly represents the resource that getsfreed up from legacy work to contribute to an organisa-tion's growth. ■6Planning a Service-Oriented Architecture, an Internet.com Developer eBook. Copyright 2008, Jupitermedia Corp.Planning a Service-Oriented Architecture[]Just as SOA is changing the way business and IT interre-late, it is also about to transform the types of peoplewho work in IT. This is because SOAs basically transform the IT depart-ment from a transaction-oriented cost-centre to achange agent. SOAs do this by making business leanerand more agile whilst simultaneously cutting costs andwringing ever more value from existing infrastructurethrough the reuse of past investments. But making this happen requires looking at IT and thebusiness it serves in more holistic ways. And this,although changing from days past, is not exactly IT'slong suit. "To make SOA really successful it can't be about justbuilding technology, it's got to be about solving busi-ness problems," says BEA Systems' Paul Patrick, who isvice president and chief architect of its SOA infrastruc-ture product, AquaLogic. From a technology perspective, SOA is comparativelystraightforward. If you have a mature IT department withsome depth of skills, then the technological portion ofyour SOA implementation - wrapping data in XML, set-ting up SOAP calls for Web services, setting up yourregistry and repository, etc. - should come pretty natural. The hard part is seeing things from a big-picture per-spective and, unfortunately for those who will have toStaffing for SOA Success deal with it, the politics of moving your line-of-businessusers used to consuming dedicated IT services towardsa model that, at its heart, is all about sharing. "The most important skill, which is going to be new toIT professionals, is they're going to have to shift theirthinking and their ability from being very technology-and product-focused to becoming much more (busi-ness) process-centric," says Marianne Hedin, a pro-gramme manager at IDC. This is where new blood may be needed to get yourSOA initiative off the ground and help make it success-ful. Key to this effort is having a systems' architect on anSOA team who is specifically challenged with tacklingthe larger, enterprise-wide issues that will inevitablycome up, including: • Who is going to have priority if shared services getbottlenecked? • Whose budget pays for new hardware and softwareif the services are going to be rolled out company-wide? • How will the SOA affect the business as a whole? • Who's responsible for re-organising IT into a serv-ice-delivery business? "It's in many ways a micro view of the problems sittingat Homeland Security where you've got 17 distinctagencies all trying to act as if they are one big thing,but their culture has been, 'I've got my world, you'vegot yours. Why should we share?' That's the hiddenproblem," says BEA's Patrick. The ideal solution, is to set up a team led by the CIOthat includes a business analyst who understands bothIT and the business processes it supports (not any easyperson to find by all accounts); a system's architect thatcan turn business concepts into IT-speak and ride herdover the infrastructure in order to minimise unintendedconsequences; and representatives from each of thecompany's lines of business. This last piece of the puzzle is particularly important toa successful SOA transition, claims Chris Warner,Software AG's director of Technical Marketing and amember of SAG's SOA competency centre. Withoutexecutive buy-in and sponsorship of the changeswrought by SOA, it will most likely, at least in part, fail. "It's kind of important that you have an executive spon-sor for any new initiative," he says. "In the case ofSOA, the way that works best is if you can tie that ini-tiative to something the executives already care about.In other words, not SOA for SOA's sake." Other team members can come and go, such as pro-grammers to explain different concepts, but the coremembers should be charged with smoothing the feath-ers sure to be ruffled by the wholesale changes SOAcan bring and making sure that whatever individualprocesses are served up by your SOA do not implodethe entire system. "A lot of people think SOA and they just think justtechnology," says BEA's Patrick. "Our experience hasbeen that if all you do is take a technology approach tothis problem … you can do a really great job and quickhit a wall." ■7Planning a Service-Oriented Architecture, an Internet.com Developer eBook. Copyright 2008, Jupitermedia Corp.Planning a Service-Oriented Architecture[]Managing the Complexity of SOAs for SuccessImagine you recently completed the first successful phaseof your "Enterprise SOA Master Plan." Services are distrib-uted throughout the enterprise, linking legacy applicationswith your ERP and CRM applications, and are presented toyour business users via a new portal interface. The users love the ease with which they can access allthis information and conduct their daily tasks. Now thatthey know what is possible, they want more and you areready to give them what they want. After all, you havejust proven that SOA is more than a mere buzzword. However, no one has yet told you there is a problem. This initial, highly successful project has introduced anew level of complexity into your IT organisation.Monolithic and heterogeneous applications running inisolation for many years have suddenly become crucial components in a more complex organism held togeth-er by the principles of service-oriented architectures(SOAs). The IT architects have very detailed architectural dia-grams to describe it all, the developers wrote thou-sands of lines of code to make it all work, and the inte-gration team has configured a complex web of mes-sage infrastructure to ensure that every message isguaranteed to be delivered to the right application.What could potentially be amiss in this picture? Let's pose a few questions: • How many services are currently deployed withinthe organisation? • Of these services, how many are currently up andrunning and how many are experiencing problems? • How well does every service perform its given task?Are your end-users waiting longer to achieve a giventask? • How stable are these services? How are some ofthese newly created business processes and applica-tions affected when a crucial service (or services) mal-functions? • Can you conduct an impact analysis to measure thepotential impact of changes to an existing service orset of services? By using the principles of SOA you have been able tosolve a complex problem and by doing so introducedadditional complexity into your IT infrastructure. Thechallenge that you now have to face is how to managethat complexity. SOA Governance Approach SOA Governance is a discipline that, in an ideal world,should be established early on in the SOA lifecycle. Yet,it is never too late to implement good policies, proce-dures, and technology to assist with the managementof a freshly implemented SOA project. Consider governance a "best practice" whereby onetransforms lessons learned into sound policies, guide-lines, and procedures with the aim of establishing amature SOA ecosystem. Here are five guidelines considered essential to goodgovernance: 1. Establish an SOA Competency CentreThis is a cross-functional team of key people that repre-sent different disciplines within IT. By establishing sucha group you facilitate communication between the vari-ous groups, ensuring that everyone is represented andthat every aspect of the SOA architecture gets properconsideration. Furthermore this group can be instrumental in estab-lishing organisational standards, setting guidelines andcreating blueprints. This core group can also dissemi-nate knowledge to new groups that need to adopt theSOA approach. 2. Experience is a Good TeacherBlueprints and best practices can be very good teach-ing mechanisms. They are a tangible way in whicheveryone involved in the SOA implementation can ben-efit from the work that has been done before. Too many times development teams have to "reinventthe wheel" in order to solve a particular problem.Identify and document those solutions that work welland turn them into patterns that can be used repeated-ly. By making a particular approach repeatable you areable to reduce risk, shorten development time and alsodecrease the cost associated with the overall project.Likewise, it may be just as important to documentthose approaches that don't work well or which mayhave failed. By documenting these so-called anti-pat-terns one is able to prevent mistakes from beingrepeated. 3. Use an SOA RepositoryServices are by definition reusable and self-describing,but don't be deceived by this oversimplified view. If services are not properly documented and madeaccessible in a consistent manner, they could becomejust as unusable as some of those legacy applications. Accomplishing such simple tasks as establishing the8Planning a Service-Oriented Architecture, an Internet.com Developer eBook. Copyright 2008, Jupitermedia Corp.Planning a Service-Oriented Architecture[] exact nature of a service, obtaining the latest servicedescription, or determining the owner of a particularservice may become quite a daunting task if servicesmanagement infrastructure is not put into place. This iswhere an SOA repository can play an important role. Itcan become the focal point where all services can bedocumented, searched, and accessed. 4. Monitor Quality of Service (QoS)Bring predictability to your SOA by implementing serv-ice management facilities. What you need is the capa-bility to maintain end-to-end visibility into your servicesinfrastructure via the ability to define SLAs (service levelagreements), measure services operation and responselevels, analyse service usage and resource utilisationpatterns, and proactively be alerted of potential andimminent service failures. Stability is the hallmark of a mature system and throughthe effective management of your deployed services(and related infrastructure) you can bring a great meas-ure of stability to your SOA. 5. Manage the SOA LifecycleCreate a disciplined and well-managed SOA lifecy-cle. In all other areas of IT this kind of discipline iswell established and maintained. SOA should be nodifferent. Implement tools and procedures that will help managethe services development, testing, quality control,deployment, and maintenance processes. As part of the lifecycle, create a services approvalprocess, ensuring that services are tested for standardscompliance and services are put through a comprehen-sive vulnerability, interoperability, and regression testingprocess. Implementing these measures will assist in ele-vating the overall maturity and robustness of your SOAimplementation. Implementing an SOA entails more than just imple-menting a few services or using an ESB (enterpriseservice bus). SOAs may start out simple, but they inher-ently introduce complexity into the IT organisation. Thisis mainly due to the nature of the problems that we areattempting to solve. Acknowledging the complex nature of SOA and takingthe appropriate steps to manage this complexity is acrucial step toward the successful development, imple-mentation, and maintenance of an SOA. The bestadvice is to plan for SOA success. Plan to be hugelysuccessful and in preparation, consider how you willgovern the next generation of business applications. ■This content was adapted from EarthWeb'sDeveloper.com and CIO Update Web sites.Contributors: Theo Beack, Allen Bernard, EnriqueCastro-Leon, Arulazi Dhesiaseelan, KishoreChannabasavaiah, Kerrie Holley, Edward M. Tuggle, Jr.9Planning a Service-Oriented Architecture, an Internet.com Developer eBook. Copyright 2008, Jupitermedia Corp.Planning a Service-Oriented Architecture[] . risks arereduced. SOA is an architecture and a programmingmodel, a way of thinking about building software. ■ 3Planning a Service-Oriented Architecture, an. Jupitermedia Corp .Planning a Service-Oriented Architecture[ ]Planning a Service-Oriented ArchitectureJupiterimagesService Oriented Architecture (SOA) is seen as the