project_sysdev_modernization.doc
Upcoming SlideShare
Loading in...5
×
 

project_sysdev_modernization.doc

on

  • 290 views

 

Statistics

Views

Total Views
290
Views on SlideShare
290
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

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

project_sysdev_modernization.doc project_sysdev_modernization.doc Document Transcript

  • Administrative Information Services A unit of 3A Shields Building University Park, PA 16802-1202 Information Technology Services Phone: 814-863-0958 Fax: 814-863-6123 AIS Systems Development Modernization Final Project Definition Date: 10/28/05 Revision: 1.9 Last Modified By: K. Plavko http://ais.its.psu.edu/ An Equal Opportunity Employer
  • Table of Contents SYSTEMS DEVELOPMENT MODERNIZATION PROJECT.............................................3 1. Glossary of Terms ................................................................................................3 2. Problem / Opportunity Statement .........................................................................4 3. Impact Statement..................................................................................................5 Doing the Project 5 Not Doing the Project 5 4. Goal/Scope Definition ..........................................................................................6 Out of Scope 7 5. Critical Success Factors .......................................................................................7 6. Potential Risks or Time Constraints ...................................................................8 7. Assumptions .......................................................................................................9 8. Deliverables ......................................................................................................10 9. Project Resource Requirements (People, equipment, materials, support, training or consulting)...............................................................................................................13 10. Communications Plan (Team, Sponsor and AIS Management Reporting) .....13 11. Issues for AIS Management ............................................................................14 12. Modernization Project Stakeholders List..........................................................15 Appendix A - More on Service-oriented Architecture.........................................17 The SOA Elevator Speech by John Reynolds 17 What is Service-Oriented Architecture? by Hao He 18 2
  • Systems Development Modernization Project 1. Glossary of Terms Service-oriented architecture (SOA) - A software design philosophy for encapsulating and making available, units of application functionality to support business needs. These functional units, called services, are defined and accessed in a standard way over a network so they can be utilized by systems built from different technologies. Some benefits of SOA are lower development and integration costs over time, standardized interfaces and increased reuse. SOA provides greater flexibility in addressing the long term business and integration requirements for enterprise computing in a highly distributed environment like Penn State. J2EE – Java 2 Platform Enterprise Edition. J2EE is a platform-independent, Java-centric environment from Sun for developing, building and deploying Web-based enterprise applications online. The J2EE platform consists of a set of services, APIs, and protocols that provide the functionality for developing multi-tiered, Web-based applications. (A Word Definition from the Webopedia Computer Dictionary) Some of the key features and services of J2EE: At the client tier, J2EE supports pure HTML, as well as Java applets or applications. It relies on Java Server Pages and servlet code to create HTML or other formatted data for the client. Enterprise JavaBeans (EJBs) provide another layer where the platform's logic is stored. An EJB server provides functions such as threading, concurrency, security and memory management. These services are transparent to the author. Java Database Connectivity (JDBC), which is the Java equivalent to ODBC, is the standard interface for Java databases. The Java servlet API enhances consistency for developers without requiring a graphical user interface. WebSphere - Integration and application infrastructure software from IBM which includes products like the WebSphere Application Server. WebSphere Application Server (WAS) – IBM’s J2EE application server. eServer zSeries – IBM’s newest line of 64-bit mainframes and this is the type of mainframe(s) currently used by Administrative Information Services at Penn State. AIS has 2, 890 zSeries servers. They provide a scalable platform for Linux computing since the zSeries can run mixed workloads, including numerous other operating systems. Linux on zSeries – The Linux operating system running on IBM zSeries servers. (This is represented in this document as zLinux.) VM – Virtual Machine operating system from IBM. It is in wide use on IBM mainframes today and is used to get maximum benefit from Linux on zSeries computers. 3
  • IFLs (Integrated Facility for Linux) – Mainframe processors dedicated to running Linux. Microcode restricts IFLs from running traditional workloads like z/OS and IFL hardware is less expensive than general purpose engines (CPs). Consequently, businesses can expand their mainframe Linux installations without affecting most of their software license charges. IDE – Integrated Development Environment is a programming environment integrated into a software application that provides a GUI builder, a text or code editor, a compiler and/or interpreter and a debugger. Visual Studio, Delphi, JBuilder, FrontPage, DreamWeaver and IBM’s Rational application developer software are all examples of IDEs. (A Word Definition From the Webopedia Computer Dictionary) IBM Rational – The IBM Rational Software Development Platform is a modular product line for developing software and software-based systems. It provides tools to automate and integrate the process of software development from requirements collection through testing in an open, proven and modular manner. The application products in this line were previously known as WebSphere Studio products and they have now been re-branded under the Rational name. One of these is already in use in AIS and it is the Rational Application Developer for WebSphere which supports Eclipse- based UML Visualization and Java Development. Eclipse – Eclipse is an open source community whose projects are focused on providing an extensible development platform and application framework for building software. Uniform Description, Discovery and Integration (UDDI) services - A platform- independent, XML-based registry for businesses worldwide to list themselves on the Internet. UDDI is an open industry initiative (sponsored by OASIS) enabling businesses to discover each other and define how they interact over the Internet. UDDI is nominally one of the core Web Services standards. It is designed to be interrogated by SOAP messages and to provide access to WSDL documents describing the protocol bindings and message formats required to interact with the web services listed in its directory. 2. Problem / Opportunity Statement • The AIS Development Tool Set Subcommittee recommends a technology shift to embrace the defined AIS open standards strategy in a mainframe-centric environment. To achieve this, AIS would provide the enterprise-level infrastructure to support J2EE application development and operation on the mainframe(s) and establish and support JAVA as the preferred programming language for future AIS application development. This is an important step in implementing a more service- oriented architecture for future administrative information system development. • All central administrative system developers and many AIS operational staff will be impacted by this change. It is also probable that developers needing access to administrative data in the future will be positively impacted by this change. • The stakeholders for this project are outlined in the Section 1.13 - Stakeholders List. They are generally in the following groups: -- Members of the AIS Development Toolset Subcommittee, 4
  • -- AIS management, -- ITS management, -- Application developers across the University who work on central administrative systems and other developers of enterprise systems at Penn State who plan to use Java or .NET programs to interact with legacy data. 3. Impact Statement Doing the Project • There will be a more loosely coupled, service-oriented environment on the mainframe for developers working on central administrative systems and those Penn State developers who need access to administrative data from the mainframe for their local applications. • This positions the Universities’ future enterprise administrative systems development in an open standards-based environment (J2EE) that makes it easier for Penn State’s information systems to share, communicate and integrate with each other and with appropriate external groups. • More consistent business logic is possible across applications through the reuse of web services and sharing of software. • It allows further deployment of the AIS Open Standards Strategy as announced in Sept 2003 with JAVA as the preferred programming language. • Enterprise data can become more usable “information” for our customers as the development and knowledge of, commonly shared web services improves. This can result in improved University-wide collaboration in applications development. • Penn State can have a more consistently trained programming workforce. • Penn State has a much higher probability of hiring and retaining experienced developers in this more state of the art, industry standard development environment. Not Doing the Project • The continuation of our current proprietary toolset does not support an open standard strategy and in some cases presents unnecessary hurdles for non-AIS developers who are not Natural programmers. This makes it less likely that these developers will be able to easily use administrative data now in legacy systems on a real-time basis for their own University business processes. • The proliferation of independent Intel servers which has created a high maintenance cost will continue unabated. 5
  • • Delay in beginning this project would soon place Penn State at risk in our efforts to continue to develop and support our core administrative systems without having to resort to using the costly services of commercial providers such as PeopleSoft and Oracle in order to provide the business systems required to remain competitive. 4. Goal/Scope Definition The goal is to create a service-oriented, enterprise architecture to affect dramatic change and improved efficiencies in the development and deployment of administrative services at Penn State. The environment in which we will deploy administrative services will be IBM WebSphere in Linux on zSeries. There will be a database development environment with DB2 and connectivity from this environment to the Adabas environment with templates for developers to use for those connections. AIS will continue to be using Adabas as the integrated database for existing systems. It will also be necessary to assess, select and implement system management software and other hardware and networking components that may be needed to effectively monitor the performance and stability of this environment. As part of the J2EE architecture, we will provide Uniform Description, Discovery and Integration (UDDI) services for all enterprise-wide software objects to be shared including management of UDDI and access control mechanisms for change management. We will also implement the necessary infrastructure to support sharing of .NET objects and provide processes and staffing for maintenance and performance monitoring of the J2EE mainframe environment. In order for University developers to efficiently use the new enterprise development environment, we will implement a “prototype” application” (an example that is not production ready), document any anomalies and document development standards and recommended techniques specific to the new J2EE environment. We will also dedicate resource(s) in support of these. These standards will help to break down silos of data, applications and services and move closer to legacy integration and interoperability. The shift from the Natural Adabas environment to a J2EE Web Services environment has far reaching implications. There are organizational, policy and procedural issues to be considered in support of the new environment and there are the technology and re- training issues. This is a shift in programming language, application development methods and a dramatic shift in inter-operability standards. Therefore, the success of the application migration to this new environment is heavily dependent on a well organized training plan. In addition to training, this project will re-tool developers with the necessary hardware upgrades, software licenses and support environment to foster development of enterprise applications across the University using IBM's Rational Application Developer. 6
  • Out of Scope This project addresses the creation of an infrastructure for future application development and the training and re-tooling of developers to use the new infrastructure. The migration or re-deployment of existing or new applications into this environment lies beyond the scope of this project. The WorkFlow project, for example, represents an initial deployment of selected J2EE technologies for processing business forms, but is managed as a separate project even though the WorkFlow developers will participate in Modernization training. This project does not cover the long-term training for future application developers who may not be identified during this project. 5. Critical Success Factors University-wide stakeholders in the Toolset Committee spent several years formulating recommendations for the future development of enterprise-level administrative systems. These are detailed in the committee’s report of November 24, 2004 and were a key source of many of the itemized deliverables in this document. In order to foster the University-wide acceptance of the new application development standards and their benefit of systems interoperability, it will be important to keep stakeholders up to date on the progress of this project. The critical success factors are: A. The J2EE environment exists on the mainframe(s) which includes a service-oriented application development environment using JAVA with IBM’s WebSphere Application Server. B. Processes and procedures must be in place for management and support of JAVA and .NET objects when developers are trained. Otherwise, application builds will be slower and there may not be a standard approach to troubleshooting problems and insuring reliability. C. AIS Enterprise Infrastructure needs to have created a database development environment with DB2 and other tools under z/Linux in order to support WebSphere applications. They also need to have named the DB2 and WebSphere support person(s) for developers to contact. D. There must be connectivity from this J2EE application development environment to Adabas. E. There must be a mechanism for requesting database support for new applications in this area. F. A cross-section of application development and systems management tools need to be evaluated, selected and installed. These tools must be able to be integrated such that they can be managed from a central location. 7
  • G. The framework (read plumbing) for JAVA application development must be in place with templates, standards and samples when developers are being trained. It should be published on the web for use by programmers. Otherwise, they may develop bad habits resulting in unreliable or inefficient applications and minimal re-use of existing services. All of this can cost the University time and therefore, money. H. AIS application development staff are aware of the future JAVA direction and have been offered training/hardware upgrades where needed. I. Other University development staff are aware of the future JAVA direction and have been offered training/hardware upgrades where needed. J. JAVA training has occurred to include the JAVA programming language and the new application development framework. K. A prototype JAVA application is working reliably in the J2EE environment. It should access all types of supported data sources. (SQL server, Adabas, DB2, Tivoli) L. AIS has documented their direction with Natural, Smalltalk and Java so that University offices can develop a clear plan for beginning new application development or migrating existing applications to the new architecture and tools. M. Developers who were trained had immediate work assignments to start on in order to use and refine their newly learned skills. In fact, since the new methodology will encourage re-engineering business services, a clear plan for ongoing collaboration with respect to application development and migration should be under discussion among AIS and its partners. N. A JAVA developers support group run by both AIS and non-AIS programmers exists and it meets at least quarterly with updates on the environment and opportunities for sharing information on the effective reuse of services, etc. 6. Potential Risks or Time Constraints  Delays caused by waiting for vendors to provide required support.  Chronic over-engineering which causes delays in project schedule.  Trying to implement too much at once increases chance of failure.  Partner offices anxious to start earlier because of their own commitments and schedules increase demands for the completed framework and the infrastructure to support it.  Frustration on the part of developers who want to develop in the new environment and are not able to be successful because the support processes and framework for developing and getting applications running in production aren’t fully understood, documented or in place.  Partner offices may have so many ongoing priorities that their timely transition of applications into the new architecture is delayed. 8
  •  Lack of sufficient support in AIS for JAVA application development and the new infrastructure, including WebSphere.  Sufficient support for the DB2 environment on zLinux is not available or does not develop in the timeframe required by the project.  Timing of training completion needs to coincide with productive work assignments for developers in the new environment.  Java developers may not be proficient for 9-12 months after training assuming they begin to work with the new tools right away. Therefore, time tables for completing new development in the first round will be longer. (**** Training does not equal experience. ****)  The time required for AIS staff to develop the necessary skill levels for the operational support and management of this new environment is an unknown at this point. 7. Assumptions Business: • All purchase requests that are part of this project will be submitted in writing to the Project Manager. • There will be a Change Management process for this project and a request form for submitting any requests for changes to the Project Scope. • There will be development projects designed to coincide with the date of training completion so that developers can begin immediately to use and refine their skills in a productive environment. Technical: • WebSphere Application Server will be the application server in the new J2EE environment. • WebSphere Application Server will be run under zLinux. • The new application development environment will require an additional database and it is likely DB2 because of its integration within the selected application development environment. • IBM Rational Application Developer software will be used for AIS developers even though University offices may or may not choose to use this tool for their JAVA development. • The recommended operating system environment for developer machines using Rational Application Developer software will be Windows. • Other IBM Rational Tools will be examined to see where they fit in the new AIS software lifecycle development process. • Because of the complexity of the new environment and the impact of other projects, some of the work may be refined through an iterative implementation process. • Application developer training should not take place until there is a production J2EE environment. 9
  • 8. Deliverables A. Infrastructure Management Tool Selection 1. Assess, prioritize and select system management software and other hardware and networking components needed to effectively monitor the performance and stability of the new production J2EE environment. 2. Assess, prioritize and select application change management software required to effectively manage all changes in the new production environment. B. Infrastructure Management Tool Installation 1. Install system management software and other hardware and networking components needed to effectively monitor the performance and stability of the new production J2EE environment. This includes the development of associated documentation and processes for monitoring the performance and stability of the environment. 2. Install application change management software required to effectively manage all changes in the new production environment. This includes the development of associated documentation and processes for change management. 3. Determine the requirements and timing for the re-allocation of staff positions to support the new enterprise infrastructure. C. z/Series 1. Install IBM’s WebSphere Application Server on the zSeries server to run under z/ Linux. 2. Create a secure Linux environment and assess security of the environment on the zSeries. 3. Establish processes, documentation and staffing for maintenance and monitoring of the z/Linux and J2EE mainframe environment. 10
  • D. WebSphere Application Server, Application Development Framework & Components 1. Test IBM’s WebSphere application server in zLinux and document any anomalies so that they may be resolved. 2. Identify and document any issues related to porting J2EE applications from the Windows environment to the zSeries Linux environment. 3. Establish connectivity to the Adabas environment and develop templates for connections. 4. Provide Uniform Description, Discovery and Integration (UDDI) services for all enterprise-wide software objects to be shared including management of UDDI and access control mechanisms for change management. 5. Implement the necessary infrastructure to support hosting of .NET objects. 6. Create a JAVA application development framework for the AIS enterprise and document it for use by university developers. Framework should include common ways for logging, exception handling, getting a connection to a resource (database, naming service, security for authorization and authentication), building JSP pages, data validation, etc. 7. Document the baseline hardware/operating system requirements for developer machines to effectively run the Rational Application Developer software. 8. Provide a document repository for the artifacts associated with the software development lifecycle. 9. Build an iterative, step-based process for designing a software system. 10. Recommend a software lifecycle development strategy and process for AIS. E. Database Installation & Testing on zServer 1. Create a database development environment with DB2 and other tools necessary to run under z/Linux. 2. Establish processes, documentation and staffing for maintenance and monitoring of the DB2 database environment. F. Prototype Application and Performance Testing 1. Implement a prototype J2EE architecture. 11
  • 2. Implement a “prototype application” in the new environment to demonstrate its efficacy. 3. Demonstrate “prototype application” to all interested University developers as part of their training. 4. Measure and summarize performance characteristics to establish a baseline for applications. G. Standards and Procedures for Managing Objects 1. Establish and document development standards and required techniques specific to the new J2EE and the .NET environments. For example, what does an object look like, who checks them in, what are the control mechanisms, etc. Dedicate resource(s) to support of these. These standards must be acceptable to stakeholders so that they can help to break down silos of data, applications and services and move closer to integration and interoperability of systems across the University. H. Training and Developer Re-tooling 1. Conduct an administrative systems developer survey to get updated information on the numbers and names of developers (by area) who will need training. This survey was initially completed in October of 2003. 2. From the development survey results, create a list of developers who need training in this environment for their work in central administrative systems or enterprise-level systems. Their preferred timing within training cohorts should also be noted. 3. Obtain an inventory of participant machines including any plans that their departments have for upgrades in the next year or so. This information will be compared to the hardware baseline and should indicate where additional hardware is needed so that it can be purchased and provided to developers prior to training. AIS developers will have hardware upgrades installed by AIS LAN Support prior to training. Departments outside of AIS will have the option of having AIS install the application software as part of the training and re-tooling effort. 4. Provide Rational Application Developer software licenses for AIS and non-AIS developers working on central administrative systems and obtain additional hardware where necessary to efficiently run this client software. 5. Coordinate, fund and schedule training for AIS and non-AIS developers to help them attain a complete understanding of the new methodologies and tools for 12
  • building and successfully running, efficient enterprise Java applications. 6. Coordinate, fund and schedule training for AIS staff involved in support of the new J2EE and .NET object server environment. 7. Negotiate vendor agreements for training, software and other support needs such as consulting. 8. Coordinate, fund and schedule any additional licenses or tools needed at training facilities for this effort. 9. Create and communicate training plan. 10. Create requirements for the AIS Enterprise Developer Certificate. This is to be given to developers who successfully complete all of the training. 11. Create a model for supporting the developer’s installation, maintenance and use of the functionality in the application developer software. 9. Project Resource Requirements (People, equipment, materials, support, training or consulting) After the Project Definition is finished, working group leaders will each complete a General Work Breakdown matrix using a template provided by the PM on Microsoft Project to identify specific tasks necessary to provide each deliverable and later, how long each will take, who will be doing them and what the critical path items are. Within these documents, the following items will be covered. • AIS resources needed (use project org chart if desired – see sample template). • Estimated completion time in person hours or months. • Equipment or other costs, i.e., software licenses, hardware, etc. Support/Maintenance • Estimated completion time in person hours or months. 10. Communications Plan (Team, Sponsor and AIS Management Reporting) The Project Manager will: • Coordinate collaborative project definition meetings with stakeholders to discuss and develop the project plan and finalize the scope and definition. • Distribute Project Definition once finalized to all stakeholders and project team. • Coordinate project Kick Off Meeting for project team to outline general plan for project and identify stakeholder and project team responsibilities. • Conduct bi-weekly meetings with project team to coordinate the completion of a project plan and then review status reports for project tasks to stay current with all aspects of the project. 13
  • • Communicate to the University community via multiple methods when appropriate, i.e. TechNews, News wires, listservs, Network of People, ITS Forums, etc. • Use AIS Newsletter to communicate announcements, reports, general information, etc. • Provide weekly project status at AIS Operations meetings. • Provide general project status at AIS Management meetings. • Meet with and provide project status to AIS Advisory Committee. • Meet with and/or communicate regularly with AIS Deputy Director • Create project status reports and communicate them as appropriate either monthly or quarterly to stakeholders via email. • Schedule and conduct stakeholder meetings as needed. 11. Issues for AIS Management • Providing information to the University indicating the strategic direction for new administrative applications development in Natural, Smalltalk and Java. 14
  • 12. Modernization Project Stakeholders List Name Role Responsibility Contact Info Ron Rash Senior Director, AIS Sponsor and AIS final rhr@psu.edu decision maker Scott Smith Deputy Director, AIS Sponsor and AIS sas1@psu.edu decision maker for enterprise-wide strategic projects Karen Schultz Director, Solutions & Directs the work of kls2@psu.edu Services application development areas Mike Kauffman Manager, Enterprise Manages the work of mjk3@psu.edu Infrastructure, AIS mainframe infrastructure groups and database administration on the mainframe Mike Belinc Enterprise Architecture Enterprise mfb1@psu.edu consulting Architecture consulting Pete Dawson Manager, Mid-Tier Manages the work of pmd1@psu.edu Infrastructure mid-tier infrastructure groups including database administration in the mid-tier environment Bill Cook Manager, Database Manager, database wgc1@psu.edu administration administration on the mainframe Phil Hawkins Enterprise Services Team lead for this pdh2@psu.edu Integration new group focusing on integrating products such as iBPM, Mediator and WebSphere. Todd Litzinger Manager, Network Network tfl13@psu.edu Infrastructure and Data Infrastructure and Security Data Security Vicki Hoffman Senior Support and Coordinates and vlw3@psu.edu Training Analyst facilitates training needed by AIS or our customers (content, delivery and contracts) Carl Seybold J2EE Consulting J2EE Consulting cvs3@psu.edu Ed Hayes emh1@psu.edu 15
  • AIS Advisory Committee which will also represent the Development Toolset Subcommittee below via Ken Forstmeier Development Toolset Kenneth Forstmeier Office of Research Subcommittee Committee chair Information Systems Proposed a strategic Don Albertson Office of Physical direction regarding Plant the toolsets and environment used for Walt Beatty (until 10/04) College of development of Engineering enterprise-level administrative Carol Findley Registrar’s Office systems. First report Nov, Steve Focht Undergraduate 2003, final report Admissions Office November, 2004. Rich Gabel Office of Research Information Systems Craig Haynal Graduate School Edie Hertzog University Budget (chair til 9/04) Office Kelley King (until 7/04) Corporate Controller Carl Seybold AIS Cheryl Seybold Outreach and Cooperative Extension Steve Shala College of Agricultural Sciences Mike Sherlock Auxiliary and Business Services Vince Timbers Enrollment Mgmt Vicki Hoffman AIS (began 9/04) University Budget Tim Whitehill Office 16
  • Appendix A - More on Service-oriented Architecture The SOA Elevator Speech by John Reynolds Posted by johnreynolds on January 06, 2005 Here are some notes from a "brown bag" talk that I am preparing for our IT staff, many of whom are died-in-the-wool mainframe COBOL programmers. This talk will be far more evangelical then technical, and I hope that it will de-mystify SOA for some. I'm sure many of you will say "Duh!" when you read some of the points, but you'd be surprised how many folks just don't get it (yet). I like the following definition of SOA from a paper by Bernhard Borges, Kerrie Holley and Ali Arsanjani, but it's a bit over-the-top as an introduction: SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business- aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions. I think it works better if I break down the definition as follows: -- SOA is an architectural style that encourages the creation of loosely coupled business services. -- Loosely coupled services that are interoperable and technology-agnostic enable business flexibility. -- A SOA solution consists of a composite set of business services that realize an end-to-end business process. -- Each service provides an interface-based service description to support flexible and dynamically re-configurable processes. It's not as concise as the original, but I think it's a bit easier to swallow. I’d like to get across the following points about SOA: SOA isn’t really new, but there are now some standard technologies (such as Web Services) that make it much easier to implement. The “Services” in SOA are business services… updating a loan application is a business service, updating a record in a database isn’t. Services are linked together to implement business processes... Business Process Engines make it easier to combine services into business processes, and BPEL is an emerging standard language for this purpose. 17
  • Business partners can use your company's services within their own business processes and your company can use services provided by business partners within your own business processes. SOA solutions favor flexibility over efficiency... machine cycles and network traffic are less important then being able to quickly implement and change business processes. On the implementation front, we need to clear up the following common misconceptions: Services aren’t tied to user interfaces. User interfaces invoke services. Many user interfaces can use the same service. A partner may build a user interface on top of your service, and you may build a user interface on top of a partner’s service. Services can be implemented in any language, COBOL, Java, etc., but all services must support the same invocation/communication protocols (for example XML/SOAP). Perhaps that's a bit more information then you can get across in one elevator ride, but its close. What is Service-Oriented Architecture? by Hao He SOA Defined and Explained Now we are able to define a Service Oriented Architecture (SOA). SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. This sounds a bit too abstract, but SOA is actually everywhere. Let's look at an example of SOA which is likely to be found in your living room. Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different. The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems. The results of a service are usually the change of state for the consumer but can also be a change of state for the provider or for both. After listening to the music played by your CD player, your mood has changed, say, from "depressed" to "happy". If you want an example that involves the change of states for both, dining out in a restaurant is a good one. The reason that we want someone else to do the work for us is that they are experts. Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering. 18
  • How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints: A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services. As illustrated in the power adapter example, interfacing is fundamentally important. If interfaces do not work, systems do not work. Interfacing is also expensive and error-prone for distributed applications. An interface needs to prescribe system behavior, and this is very difficult to implement correctly across different platforms and languages. Remote interfaces are also the slowest part of most distributed applications. Instead of building new interfaces for each application, it makes sense to reuse a few generic ones for all applications. Since we have only a few generic interfaces available, we must express application-specific semantics in messages. We can send any kind of message over our interfaces, but there are a few rules to follow before we can say that the architecture is service oriented. • First, the messages must be descriptive, rather than instructive, because the service provider is responsible for solving the problem. This is like going to a restaurant: you tell your waiter what you would like to order and your preferences but you don't tell their cook how to cook your dish step by step. • Second, service providers will be unable to understand your request if your messages are not written in a format, structure, and vocabulary that is understood by all parties. Limiting the vocabulary and structure of messages is a necessity for any efficient communication. The more restricted a message is, the easier it is to understand the message, although it comes at the expense of reduced extensibility. • Third, extensibility is vitally important. It is not difficult to understand why. The world is an ever- changing place and so is any environment in which a software system lives. Those changes demand corresponding changes in the software system, service consumers, providers, and the messages they exchange. If messages are not extensible, consumers and providers will be locked into one particular version of a service. Despite the importance of extensibility, it has been traditionally overlooked. At best, it was regarded simply as a good practice rather than something fundamental. Restriction and extensibility are deeply entwined. You need both, and increasing one comes at the expense of reducing the other. The trick is to have a right balance. • Fourth, an SOA must have a mechanism that enables a consumer to discover a service provider under the context of a service sought by the consumer. The mechanism can be really flexible, and it does not have to be a centralized registry. 19