Service Oriented Architecture And What It Means To Capacity ...
Upcoming SlideShare
Loading in...5
×
 

Service Oriented Architecture And What It Means To Capacity ...

on

  • 324 views

 

Statistics

Views

Total Views
324
Views on SlideShare
324
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Service Oriented Architecture And What It Means To Capacity ... Service Oriented Architecture And What It Means To Capacity ... Document Transcript

  • Contents Introduction .....................................................................................................2 SOA Basics .......................................................................................................3 SOA Basic Structure .........................................................................................3 What SOA Means to Capacity Management .....................................................4 What Changes...............................................................................................4 What Stays the Same ...................................................................................4 Capacity Management Challenges ...................................................................4 Conclusion ........................................................................................................5 1 | TeamQuest IT Knowledge Exchange Series SOA and What it Means to Capacity Management
  • IntroduCtIon Service Oriented Architecture, or SOA for short, is probably the most discussed application development topic today. Where and how it originated is a matter of opinion. Some say it was initially devised by two Gartner Group analysts. Some say Sun Microsystems developed it to support their JINI project. Some say it is an offshoot of Component Based Design or CBD and others say it is a natural evolution from Structured Programming and Object Oriented Design. Besides the variety of claims, there are a multitude of “SOA” solutions being offered, usually in a form that touts a vendor’s own proprietary hardware and software solutions; actions somewhat in conflict with SOA’s goal of transparent interoperability. Standards organizations generally lag behind technologies and architectures, usually waiting until general acceptance is clear before committing precious resources to set a standard. SOA is no exception. Recently OASIS (Organization for the Advancement of Structured Information Standards) issued a standard called “OASIS Reference Model for Service Oriented Architecture,” however it provides basic definitions that are more suited to guiding vendors in developing solutions than IT organizations implementing SOA. OASIS continues its work to better define the different facets of SOA but we feel it will be some time before work can be completed and agreed upon. Because of the wide variety of offerings and minimal standards, SOA means a lot of different things to a lot of different people. In this paper, we will attempt to provide a simplistic view of SOA based upon its goal of a reusable, interoperable, platform independent architecture, then discuss how this new architecture impacts capacity management organizations. 2 | TeamQuest IT Knowledge Exchange Series SOA and What it Means to Capacity Management
  • SoA BASICS • Use IT infrastructure assets more efficiently and effectively determine new functions, changes to existing applications, or sunsetting It is important to remember that SOA, as applications no longer needed. the name implies, is only an architecture. The architecture is comprised of It is not a set of processes, procedures components, services, and processes. Application Architecture defines or best practices; however those are Although the solutions differ depending business templates or scripts that needed if you are to effectively and upon vendor products, there appears determine which services and/or efficiently operate applications within to be a common theme thus we have components are invoked, in what order, the architectural framework. chosen a 4-tier approach to help and when they are invoked. This area of visualize SOA. 1 SOA is responsible for understanding SOA provides a structure where changes in business processes, then applications or application components • Component – An individual using the knowledge to modify or enhance (i.e. services) more closely resemble executable module that performs a existing IT processes to satisfy them. The business processes, where services are single, measurable task applications teams will integrate other easily reused and interoperate well with existing services into the processes and, each other. The architecture provides a • Service – A collection of components where gaps exist, develop or procure framework by which services interface that provide a unique business new ones. When using SOA, applications with one another and interoperate service such as an order processing teams become integrators more than independent of how they are implemented service or a general ledger service. application coders. and independent of whether they are The architecture permits services internally or externally sourced. to be provisioned internally or externally with equal ease and When done correctly, additions and transparent to the service consumer. •HTTP changes to the application portfolio can •SOAP be accomplished quickly and easily, • Processes – A collection of components and services that are •Web Services permitting the business to capitalize invoked in a particular sequence in •XML on opportunities while keeping IT infrastructure costs low, improving order to mirror business processes. •J2EE competitive advantages. Common IT management reasons for Service Consumer Service Architecture addresses the implementing SOA: structure of services and how they are sourced. Some of the more common • Develop architecture that can support solutions to support this architecture are: and sustain shifting business requirements Application Architecture Middleware is the technology and protocols that permit the transparent • Use technology-neutral components movement of data and information, and services usually in increments called messages, across the IT enterprise infrastructure. • Speed time to market of new Service Architecture Middleware also permits seamless applications and functionality integration of external services into enhancements internal processes. • Employ component reuse techniques Workflow utilities facilitate consistent to reduce development times Component Architecture execution of business processes. During construction of a workflow, • Leverage reusable components discrete pieces of work, the order in to reduce application inventories, which they are completed, and the eliminate duplication of effort thus SoA BASIC people or business teams responsible lowering ongoing support costs for completing them are identified. StruCturE A script is developed in the workflow • Increase transparency between utility. As work is assigned, the Service Consumers are the people who internally and externally sourced workflow utility manages the assigning exploit IT services to perform business components and services and completion of the individual steps. functions. They are responsible for using services as agreed upon in Service Where steps are not completed within • Simplify interoperability across the specified time periods, the workflow Level Agreements (SLAs). They usually enterprise with a consistent approach utility invokes escalation procedures pay for the service, either directly or to application design indirectly. They interface with IT to to manage the delays. 3 | TeamQuest IT Knowledge Exchange Series SOA and What it Means to Capacity Management
  • Converters, sometimes called mediators, application and business process views, Applications still consume server may be used to normalize data which may include both internally and and network resources so the need between diverse infrastructure, such as externally sourced components, are remains to gather performance data, normalizing data between EBCDIC format needed to support management reporting store it for historical purposes, and on IBM Mainframes and ASCII format on needs. Capacity plans must be determined generate management and progress other platforms. In video format terms, looking across all affected infrastructure reports from it. converters would permit European PAL components to ensure service quality format to be displayed on North American across business processes. Business needs still need to be NTSC devices or vice versa. understood and translated into The need for modeling becomes more technology requirements. Those Employing solutions such as those urgent because although there are requirements still are needed to previously mentioned permits the fewer components to deal with, there feed existing planning processes, application teams to seamlessly is greater service quality risk due interfacing with Finance to build, and integrate components and services into to application interdependencies of then track financial plans supporting scripts or flows that resemble business component sharing. IT infrastructure growth. processes. When implemented correctly, components and services can be added, More involvement with the business There is still a need to tune applications changed or removed without any impact early in design cycles, as the reuse of to optimize the use of existing to the service consumers short of any common components permits more infrastructure assets, so the need to needed training. precise estimation of new application track trends and alert when potential implementation and ongoing support problems may occur continue to exist. costs. Using SOA’s modular approach, Bottlenecks still need to be identified it is easier to predict new application before they negatively impact levels performance. Since in many cases, of service. components from existing inventory will be used to satisfy requirements, capacity management can extract performance data and employ modeling tools to CAPACItY accurately predict the impacts of the additional usage on the IT infrastructure. MAnAGEMEnt CHAllEnGES Reporting scope has to be expanded. Because of the shared environments, The same application component or detailedreportingmaynotbeasmeaningful service may be used across many to business and IT management. A more business processes. Each process meaningful approach will be to track the may generate work at different rates, Component Architecture defines the performance of each business process depending upon needs. Therefore it may make-up of components themselves from end-to-end or an enterprise view. be necessary to find ways to identify and and the infrastructure upon which they segregate business process resource run. Components usually perform a SOA requires more capacity usage internal to the components. single, discrete function such as “get management involvement when customer record” or “compute interest designing and scaling the enterprise For example, if we look at a customer rate.” Components observe architecture architecture. Technology components service application, the day-to-day cross protocols for sending and receiving data are just as important as the application section of customer types calling is andinformationbetweenothercomponents development techniques. Quickly varied enough that you can accurately and services. XML is a commonly employed developed applications are of little use if predict future growth using average format for sharing data. the infrastructure cannot react to growth call metrics. Heavy query volumes just as quickly. Therefore it is important could skew the average if you add a to have capacity management and new service or process – using common modules and services – that gives WHAt SoA MEAnS infrastructure engineering involved in SOA architecture plans and decisions. special assistance to good customers to CAPACItY who have large amounts of purchase history. If the different business MAnAGEMEnt WHAT STAyS THE processes grow at different rates, it could be difficult to accurately predict WHAT CHANGES? SAME? future resource requirements. Therefore it will be necessary to segregate usage Capacity management processes and in the common components by business Capacity management’s individual the work required to execute them process for more accurate predictions. platform view is extended. End-to-end mostly remain the same. See the image on the following page. 4 | TeamQuest IT Knowledge Exchange Series SOA and What it Means to Capacity Management
  • management may need to devise ways CUSTOMER SERVICE SPECIAL ASSISTANCE to associate reporting of IT events to APPLICATION APPLICATION business durations. ConCluSIonS SERVICE SERVICE SERVICE SERVICE A B C D As you can see, capacity management work to support SOA is not much different from today. The same processes prevail, Provisioning or sourcing common As an example, the legacy with a change in scope from individual services may be difficult. When sharing a application could be converted to platforms to business processes. particular service, you need to ensure web services. Although the legacy piece would go away, some of the Since the viewpoint changes, new reports the lowest common denominator underlying OS support overhead need to be created to supplement those in is satisfied. That lowest common may not and some utility programs may place supporting existing platforms. Where denominator may require substantially be used by other applications. external services are used, reporting needs different levels of service than the to be put in place to ensure vendors deliver more frequent users of the service. For Recovering all resources consumed on a expected levels of service and when they example, a mapping service used by mainframe application is rare when it is do not, provide the data required to customers to find stores may experience moved to a different platform. escalate and resolve the issues. light usage but management prefers customers to find store locations any Larger, more comprehensive testing Modeling becomes even more necessary time of day or night. The warehouse environments would be required to test all to ensure service quality, plan for the application uses the same mapping applications sharing common components future, and find and correct potential service to optimize truck loading and because of interoperability complexity. bottlenecks prior to negative impacts to delivery routes to the stores. Usage is This additional infrastructure could production service quality. heavy but the warehouse only uses the substantially increase testing expenses. service weekdays between 8 a.m. and As a result, capacity management may Testing rigor requires a larger scope, 5 p.m. As a result the common service be called upon to employ modeling requiring more testing resources. could cost more since the lightest usage techniques to predict application Using shared components and services requires more expensive service options. performance based upon results produced require test practices that span different Therefore one must understand the in smaller test environments. business processes to ensure code and trade-offs between lower development performance quality for all processes costs by using a shared service and For outsourced services, capacity using shared components and services. increased service costs by sourcing for management will need to determine More rigorous monitoring is needed and the lowest common denominator. performance data requirements for modeling may provide lower cost options inclusion in business process performance than large testing infrastructures to During transition of legacy application reporting. Obtaining data can be difficult assure application performance. functions to the new architecture, it if performance data accessibility is not may be difficult to accurately plan addressed when the contracts are written. 1 Bieberstein, Norbert, Bose Sanjay, capacity positions. In many cases, the Capacity management must be involved Fiammante, Marc, Jones, Keith & Shah, Rawn applications run in shared environments in contract discussions to ensure needed (2006). Service-Oriented Architecture Compass so it may not be clear as to what really data is available to ensure vendor service – Business Value, Planning and Enterprise goes away in the legacy environments. levels are met and business processes Roadmap. Upper Saddle River: Pearson. perform as expected. Sprott, D, & Wilkes, L, (2004) Understanding Planning could further be complicated if Service-Oriented Architecture. Microsoft legacy systems need to be available for Business processes may have durations Architect Journal. Retrieved August 2006 historical purposes, such as regulatory measured in hours or days whereas IT from http://msdn.microsoft.com/library/ reporting, for some undetermined process durations are usually measured default.asp?url=/library/en-us/dnmaj/ period of time. in seconds or minutes. Capacity html/aj1soa.asp. If you like what you have read, click here for a FREE SUBSCRIPTION to the TeamQuest IT Knowledge Exchange Series. 5 | TeamQuest IT Knowledge Exchange Series SOA and What it Means to Capacity Management
  • TeamQuest Corporation www.teamquest.com Americas One TeamQuest Way Clear Lake, Iowa 50428 USA +1 641 357-2700 +1 800 551-8326 info@teamquest.com Europe, Middle East and Africa Box 1125 405 23 Gothenburg Sweden +46 (0)31 80 95 00 United Kingdom +44 1562 881 889 emea@teamquest.com Asia Pacific Level 6, 170 Queen Street Melbourne, VIC 3000 Australia +61 3 9641 2288 asiapacific@teamquest.com_ _ _ Copyright © 2006 TeamQuest Corporation All Rights Reserved TeamQuest and the TeamQuest logo are registered trademarks in the US, EU, and elsewhere. All other trademarks and service marks are the property of their respective owners. No use of a third-party mark is to be construed to mean such mark’s owner endorses TeamQuest products or services. The names, places and/or events used in this publication are purely fictitious and are not intended to correspond to any real individual, group, company or event. Any similarity or likeness to any real individual, company or event is purely coincidental and unintentional. NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THE DOCUMENT. Any product and related material disclosed herein are only furnished pursuant and subject to the terms and conditions of a license agreement. The only warranties made, remedies given, and liability accepted by TeamQuest, if any, with respect to the products described in this document are set forth in such license agreement. TeamQuest cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, indirect, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. U.S. Government Rights. All documents, product and related material provided to the U.S. Government are provided and delivered subject to the commercial license rights and restrictions described in the governing license agreement. All rights not expressly granted therein are reserved.