An Equal Opportunity Employer
3A Shields Building
University Park, PA 16802
Administrative Information Services
A unit of Information Technology Services
Last Modified By: K. Plavko
Glossary of Terms
Problem / Opportunity Statement
Doing the Project
Not Doing the Project
Out of Scope
Critical Success Factors
Potential Risks or Time Constraints
Project Resource Requirements (People, equipment, materials, support, training
Communications Plan (Team, Sponsor and AIS Management Reporting)
Issues for AIS Management
Modernization Project Stakeholders List
More on Service
The SOA Elevator Speech by John Reynolds
by Hao He
Glossary of Terms
oriented architecture (SOA)
A software design philosophy for encapsulating and
making available, uni
ts 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
er 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 lik
2 Platform Enterprise Edition
environment from Sun for developing, building and deploying Web
applications online. The
consists of a set of services,
provide the functionality for developing multi
. (A Word
rom the Webopedia Computer Dictionary)
Some of the key features and services of J2EE:
tier, J2EE supports pure
, as well as
applications. It relies on
code to create
HTML or other formatted data for the client.
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.
(JDBC), which is the
, is the standard interface for
servlet API enhances consistency for developers without
graphical user interface
Integration and application infrastructure software from IBM which includes
products like the WebSphere Application Server.
here Application Server (WAS)
IBM’s J2EE application server.
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 server
They provide a
scalable platform for Linux computing
can run mixed workloads, including numerous other operating systems.
Linux on zSeries
The Linux operating system running on IBM zSeries servers.
represented in this docu
ment as zLinux.)
Virtual Machine operating system from IBM. It is in wid
e use on IBM mainframes today
to get maximum benefit from Linux on zSeries
Systems Development Modernization Project
(Integrated Facility for Linux)
Mainframe processors dedicated to runni
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 s
oftware license charges.
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,
are all examples of IDEs.
(A Word Definition
From the Webopedia Computer Dictionary)
The IBM Rational Software Development Platform is a
developing software and software
It provides tools to automate
the process of software development
from requirements collection through testing
an open, proven and
in this l
ine were previously known as WebSphere
and they have now been re
branded under the Rational name. One of these is
already in use
Rational Application Developer
for WebSphere which supports
based UML Visualizatio
Eclipse is an open source community whose projects are focused on providing an
extensible development pla
tform and application framework
for building software.
Uniform Description, Discovery and Integration (UDDI) services
based registry for businesses worldwide to list themselves on the
UDDI is an open industry initiative (sponsored by
) enabling businesses to discover
each other and define h
ow they interact over the Internet. UDDI is nominally one of the core
standards. It is designed to be interrogated by
messages and to provide
documents describing the protocol bindings and message
to interact with the
web services listed in its directory.
Problem / Opportunity Statement
The AIS Development Tool Set Subcommittee recommends a technology shift to
embrace the defined AIS open standards strategy in a mainframe
environment. To achieve this, AIS woul
d provide the enterprise
level infrastructure to
support J2EE application development and operation on the mainframe(s) and
establish and support
as the preferred programming language for future AIS
is an important step i
n 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
. They are generally in the following groups
Members of the AIS Deve
lopment Toolset Subcommittee,
across the University who
work on central
administrative systems and other developers
of enterprise systems
plan to use
or .NET programs to
interact with legacy data.
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
’ future enterprise
in an open standards
based environment (J2EE) that makes it easier for Penn State’s
ems 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
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
esult 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
who are no
t Natural programmers. Thi
s makes it less likely that these
be able to easily use administrative data now in legacy systems on a real
for their own University business processes.
proliferation of independent Intel servers wh
ich 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
services of commercial providers such as PeopleSoft and
Oracle in order to provide the business systems required to remain competitive.
The goal is to create a service
enterprise architecture to affect dramatic chang
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 d
atabase development enviro
nment with DB2 and connectivity from this
environment to the Adabas environment with templates for developers to use for those
AIS will continue to be using Adabas as the integrated database for existing
It will also be necessary to a
ssess, select and implement
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 Desc
ription, 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 infrastructu
re to support
g 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
application” (an example that is not
document any anomalies and document development standards and
recommended techniques specific to the new J2EE environment. We wi
ll also dedicate
of these. These standards
help to break down silos of data,
applications and services and move closer to legacy integration and interoperability.
The shift from the Natural
environment to a J2EE Web Services environment has
far reaching implications
here are organiza
tional, policy and procedural issues to be
considered in support
the new environment and there are
is a shift in programming language,
methods and a dramatic shift in inter
success of the
application migration to this new environment is heavily dependent on a well organized
In addition to training,
this project will re
tool developers with
hardware upgrades, software lice
nses and support environment to foster development of
enterprise applications across the University using IBM's Rational
Out of Scope
This project addresses the creation of an infrastructure for future application development
the training and re
tooling of developers to use the new infrastructure. The migration
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,
d as a separate project even though the WorkFlow
developers will participate in
This project does not cover the long
term training for future app
lication developers who
may not be identified during this project.
Critical Success Factors
in the Toolset Committee spent several years formulating
recommendations for the future development of enterprise
These are detailed in the
and were a key source of
the itemized deliverables in this document.
In order to foster the
acceptance of the
s and the
fit of systems
interoperability, it will be important to keep stakeholders up to date on the progress of this
The critical success
J2EE environment exists on the mainframe(s) which includes
velopment environment using
with IBM’s WebSphere
and procedures must be
in place for management and support of
objects when developers are
application builds will be
slower and there may
not be a standard approach to troubleshooting problems and
needs to have created a database development
environment with DB2 and other tools under z/Linux in order to support
also need to have named the DB2
person(s) for developers to contact.
There must be
connectivity from this J2EE application development environment to
There must be
a mechanism for requesting database support for new applicatio
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.
he framework (read plum
with templates, standards and samples wh
en 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 ine
fficient applications and minimal re
use of existing
services. All of this can cost the University time and therefore, money.
development staff are aware of the future
direction and have
been offered training/hardware upgrades where n
Other University development
aware of the future
direction and have
been offered training/hardware upgrades where needed.
training has occurred to include the
programming language and the new
application development framewor
application is working reliably in the J2EE environment.
access all types of supported data sources.
SQL server, Adabas, DB2, Tivoli)
has documented their
ith Natural, Smallt
alk and Java so
ear plan for beginning new application
or migrating existing applications to
the new architecture
Developers who were trained had immediate work assignments to start on in order to
use and refine their newly lea
In fact, since the new methodology will
engineering business s
ervices, a clear plan for ongoing collaboration
with respect to application
should be under discussion
among AIS and
lopers support group run by both
AIS and non
and it meets at least quarterly with updates on the environment and opportunities for
sharing information on the effective reuse of services, etc.
Potential Risks or Time Constraints
Delays caused by waiting for vendors to provide required support.
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
increase demands for the completed framework and the infrastructure
to support it.
on the part of
environment and are not able to be successful because the
and framework f
or developing and getting
running in production
aren’t fully understood
or in place
Partner offices may have so many ongoing priorities that their timely transition of
applications into the new architecture is de
Lack of s
ufficient support in AIS for
and the new
infrastructure, including WebSphere.
ufficient support for the DB2 environment on zLinux is not available or does not
develop in the timeframe required by the project.
iming of training completion needs to coincide with productive work assignments
for developers in the new environment.
developers may not be proficient for 9
12 months after training assuming
they begin to work with the new tools right away
time tables for
new development in the first round will be longer.
(**** Training does
not equal experience. ****
The time required for
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
for this project
requests for changes to the Project Scope.
There will be development projects designed to coincide with the date of training
so that developers can begin immediately to use and refine their ski
lls in a
WebSphere Application Server will be the application server in the new J2EE
WebSphere Application Server will be run under zLinux.
will require an additional database
and it is likely
integration within the selected application
software will be
or AIS developers even
though University offices may or may not choose to use this tool for their
The recommended operating system environment for developer
Application Developer software
Other IBM Rational Tools will be examined to see where they fit in the new AIS
software lifecycle development process.
cause 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
Infrastructure Management Tool
system management software and other hardware
and networking components needed to effectively monitor the performance and
the new production J2EE
Assess, prioritize and select
change management software required
to effectively manage all changes in the new production environment.
. Infrastructure Management Tool Installation
nstall system management software and other har
dware 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
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.
Determine the requirem
ents and timing for the
allocation of staff
support the new enterprise infrastructure.
ll IBM’s WebSphere Application S
erver on the
to run under
Create a secure Linux environment
and assess securi
ty of the environment
and staffing for maintenance and monitoring
of the z/Linux and J2EE mainframe environment.
Server, Application Development Framework &
M’s WebSphere application server
in zLinux and
document any anomalies
so that they may be resolved.
any issues related to porting
applications from the
Windows environment to the zSeries Linux environment.
to the Adabas environment and develop templates for
Provide Uniform Description, Discovery and Integration (UDDI) services for all
wide software objects to be shared including management of UDDI
and access control mechanisms for cha
Implement the necessary infrastructure to support hosting of .NET objects.
Create a JAVA application development framework for the AIS enterprise and
cument it for use by university developers
. Framework should include common
ways for log
ging, exception handling, getting a connection to a resource
(database, naming service, security for authorization and authentication), building
JSP pages, data validation, etc.
Document the baseline hardware/operating system requirements for developer
chines to effectively run the Rational Application Developer software.
Provide a document repository for the artifacts associated with the software
Build an iterative, step
based process for designing a software system.
Recommend a s
oftware lifecycle development strategy and process for AIS.
Database Installation & Testing on zServer
Create a database development environment with DB2 and other tools necessary
to run under z/Linux.
Establish processes, documentation and staffing
for maintenance and monitoring
F. Prototype Application and Performance Testing
Implement a prototype J2EE architecture.
Implement a “prototype application” in the new environment to demonstrate its
ate “prototype application” to all interested University developers as
part of their training.
Measure and summarize performance characteristics to establish a baseline for
Standards and Procedures for Managing Objects
Establish and docu
ment development standards an
to the new J2EE
and the .NET
For example, what does an object
look like, who checks them in, what are the control mechanisms, etc.
resource(s) to support of these. These sta
must be acceptable to
stakeholders so that they can h
elp to break down silos of data, applications and
services and move closer to integration and interoperability
of systems across the
Training and Developer Re
administrative systems developer
survey to get updated information on
the numbers and names of developers (by area) who will need training.
survey was initially completed in October of 2003.
From the development survey results, create a l
ist of devel
training in this environment for their work in central administrative systems or
Their preferred timing
within training cohorts
also be noted.
Obtain an inventory of participant machines including any plans t
departments have for upgrades in the next year or so. This information will be
is needed so that it can be purchased and provided to developers
developers will have hardwa
re upgrades installed by AIS LAN
Support prior to training. Departments outside of AIS will have the option of
having AIS install the
software as part of the training and re
AIS and non
developers working on central admi
nistrative systems and obtain
hardware where necessary to efficiently run this client software.
Coordinate, fund and schedule training for
AIS and non
lopers to help
them attain a
complete understanding of the new methodologies and tools
building and succ
essfully running, efficient
und and schedule training for AI
S staff involved in sup
port of the
nd .NET object server environment.
Negotiate vendor agreements for training, software and other support needs
Coordinate, fund and schedul
any additional licenses or tools needed
for this effort.
Create and commu
nicate training plan.
Create requirements for the AIS Enterprise Developer Certificate. This is to be
given to developers who successfully complete all of the training.
Create a model for supporting the developer’s installation, maintenance and use
functionality in the application developer software.
Project Resource Requirements (People, equipment, materials,
support, training or consulting)
After the Project Definition is finished,
working group leaders
will each complete a
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,
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.
imated completion time in person hours or months.
Communications Plan (Team, Sponsor and AIS Management
Project Manager will:
tion meetings with
stakeholders to discuss
develop the project
finalize the scope and
once finalized to
stakeholders and project team.
roject Kick Off Meeting
for project and
and project team
weekly meetings with project team to
oordinate the completion of a
plan and then
eports for project tasks
stay current with all aspects of the
Communicate to the University community via mul
tiple 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
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
t status reports
and communicate them
as appropriate either
stakeholders via email
Schedule and conduct s
takeholder meetings as needed
Providing information to the University indicating the strategic direction for new
administrative applications development in
Natural, Smalltalk and Java.
Modernization Project Stakeholders List
Senior Director, AIS
Sponsor and AIS final
Sponsor and AIS
decision maker for
Director, Solutions &
Directs the work of
Manages the work of
administration on the
Manages the work of
administration in the
administration on the
am lead for this
products such as
Infrastructure and Data
Senior Support and
needed by AIS or our
Committee which will
also represent the
ia Ken Forstmeier
Proposed a strategic
the toolsets and
environment used for
First report Nov,
2003, final report
Office of Research
Office of Physical
More on Service
The SOA Elevator Speech
by John Reynolds
on January 06, 2005
Here are some notes from a "brown bag" talk that
am preparing for our IT staff, many of whom
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 yo
u 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 Bernh
ard Borges, Kerrie Holley and Ali
Arsanjani, but it's a bit over
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
processes realization using interface
based service descriptions.
I think it works better if I break down the definition as follow
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
SOA solution consists of a composite set o
f business services that realize an end
Each service provides an interface
based service description to support flexible and
It's not as concise as the original, but I think it's a bit eas
ier 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 s
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 o
ver 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 bu
ild 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
, 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
What is Service
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 SO
A 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
ervice. 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 depar
ts 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
rated. 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 a
re 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 inte
rfaces 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 t
he 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.
ed 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 i
s 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 o
nes for all applications.
Since we have only a few generic interfaces available, we must express application
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
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 pa
rties. 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.
is vitally important. It is not difficult to understand why. The world is an
changing place and so is any environment in which a software system lives. Those
changes demand corre
sponding 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
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.
e 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 centr