Administrative Information Services A unit of 3A Shields Building
University Park, PA 16802-1202
Information Technology Services Phone: 814-863-0958 Fax:
AIS Systems Development
Final Project Definition
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
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
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
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.
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,
-- 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
• 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.
• 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
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.
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
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
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
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
E. There must be a mechanism for requesting database support for new applications in
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.
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.
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
• All purchase requests that are part of this project will be submitted in writing to the
• 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
• WebSphere Application Server will be the application server in the new J2EE
• 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
• 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
• 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
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
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.
1. Install IBM’s WebSphere Application Server on the zSeries server to run under z/
2. Create a secure Linux environment and assess security of the environment on
3. Establish processes, documentation and staffing for maintenance and monitoring
of the z/Linux and J2EE mainframe environment.
D. WebSphere Application Server, Application Development Framework &
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
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
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.
2. Implement a “prototype application” in the new environment to demonstrate its
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
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
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
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
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
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.
• Estimated completion time in person hours or months.
10. Communications Plan (Team, Sponsor and AIS
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
• 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.
12. Modernization Project Stakeholders List
Name Role Responsibility Contact Info
Ron Rash Senior Director, AIS Sponsor and AIS final email@example.com
Scott Smith Deputy Director, AIS Sponsor and AIS firstname.lastname@example.org
decision maker for
Karen Schultz Director, Solutions & Directs the work of email@example.com
Mike Kauffman Manager, Enterprise Manages the work of firstname.lastname@example.org
Infrastructure, AIS mainframe
administration on the
Mike Belinc Enterprise Architecture Enterprise email@example.com
Pete Dawson Manager, Mid-Tier Manages the work of firstname.lastname@example.org
Infrastructure mid-tier infrastructure
administration in the
Bill Cook Manager, Database Manager, database email@example.com
administration administration on the
Phil Hawkins Enterprise Services Team lead for this firstname.lastname@example.org
Integration new group focusing
products such as
Todd Litzinger Manager, Network Network email@example.com
Infrastructure and Data Infrastructure and
Security Data Security
Vicki Hoffman Senior Support and Coordinates and firstname.lastname@example.org
Training Analyst facilitates training
needed by AIS or our
Carl Seybold J2EE Consulting J2EE Consulting email@example.com
Ed Hayes firstname.lastname@example.org
Committee which will
also represent the
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
administrative Carol Findley Registrar’s Office
First report Nov, Steve Focht Undergraduate
2003, final report Admissions Office
Rich Gabel Office of Research
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
Steve Shala College of
Mike Sherlock Auxiliary and
Vince Timbers Enrollment Mgmt
Vicki Hoffman AIS
Tim Whitehill Office
Appendix A - More on Service-oriented
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
-- A SOA solution consists of a composite set of business services that realize an end-to-end
-- 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.
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
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.
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.