Systems Development Modernization Project Definition

minceillusionInternet και Εφαρμογές Web

30 Ιουλ 2012 (πριν από 5 χρόνια και 22 μέρες)

224 εμφανίσεις


http://ais.its.psu.edu/


An Equal Opportunity Employer


3A Shields Building

University Park, PA 16802
-
1202

Ph
one: 814
-
863
-
0958

Fax: 814
-
863
-
6123

Administrative Information Services

A unit of Information Technology Services
















A
A
I
I
S
S


S
S
y
y
s
s
t
t
e
e
m
m
s
s


D
D
e
e
v
v
e
e
l
l
o
o
p
p
m
m
e
e
n
n
t
t


M
M
o
o
d
d
e
e
r
r
n
n
i
i
z
z
a
a
t
t
i
i
o
o
n
n



Final
Project Definition











Date: 10/28
/
05

Revision: 1.9

Last Modified By: K. Plavko


2

T
T
a
a
b
b
l
l
e
e


o
o
f
f


C
C
o
o
n
n
t
t
e
e
n
n
t
t
s
s


S
YSTEMS
D
EVELOPMENT
M
ODERNIZATION
P
ROJE
CT

................................

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 i
s Service
-
Oriented Architecture?
by Hao He

18




3


1.

Glossary of Terms


Service
-
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
are low
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
e
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 app
lications
. (A Word
Definition
f
rom 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
Java
Beans

(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
requir
ing a
graphical user interface
.

WebSphere

-

Integration and application infrastructure software from IBM which includes
products like the WebSphere Application Server.


WebSp
here Application Server (WAS)



IBM’s J2EE application server.


eServer z
Series



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
s.
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 docu
ment as zLinux.)


VM



Virtual Machine operating system from IBM. It is in wid
e use on IBM mainframes today
and is
used
to get maximum benefit from Linux on zSeries

computers
.


Systems Development Modernization Project


4

IFLs
(Integrated Facility for Linux)


Mainframe processors dedicated to runni
ng 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 s
oftware 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
integrat
e

the process of software development
from requirements collection through testing
in
an open, proven and
modular manner.


The application

p
roduct
s

in this l
ine 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 Visualizatio
n and
Java

Development
.


Eclipse




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
-

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 h
ow 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 woul
d 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 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
Section 1.13

-

Stakeholders
List
. They are generally in the following groups
:

--

Members of the AIS Deve
lopment Toolset Subcommittee,


5

--

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 syst
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
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
r
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
-
AIS

developers
who are no
t Natural programmers. Thi
s 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 wh
ich has created a high maintenance
cost will continue unabated.


6



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
res
ort to

using

the
cos
tly

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 chang
e
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
connections.

AIS will continue to be using Adabas as the integrated database for existing
systems.
It will also be necessary to a
ssess, 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 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
sharin
g 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 “
proto
type


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 wi
ll 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
.
T
here are organiza
tional, 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.
The
refore, 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 lice
nses and support environment to foster development of
enterprise applications across the University using IBM's Rational
Application Developer
.



7

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
manage
d 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 app
lication 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 administrativ
e 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
U
niversity
-
wide
acceptance of the

new
application development
standard
s and the
ir bene
fit 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 de
velopment environment using
JAVA

with IBM’s WebSphere
Application
Server
.

B.

P
rocesses
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
applicat
ions
.

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 applicatio
ns 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.


8

G.

T
he framework (read plum
bing) for
JAVA

application development
must be
in place
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.

H.

AIS
application
development staff are aware of the future
JAVA

direction and have
been offered training/hardware upgrades where n
eeded.

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 framewor
k.

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 w
ith Natural, Smallt
alk and Java so
that
University off
ices
can develop
a cl
ear 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 lea
rned skills.

In fact, since the new methodology will
encourage re
-
engineering business s
ervices, 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

deve
lopers 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.



C
hronic 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.




F
rustration

on the part of

developers who

want

to
develop in

the new
environment and are not able to be successful because the
support
process
es
and framework f
or 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 de
layed.


9



Lack of s
ufficient support in AIS for
JAVA

application development

and the new
infrastructure, including WebSphere.



S
ufficient support for the DB2 environment on zLinux is not available or does not
develop in the timeframe required by the project.



T
iming 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
. Therefo
re,
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 ski
lls in a
productive environment
.


Te
chnical:




WebSphere Application Server will be the application server in the new J2EE
environment.



WebSphere Application Server will be run under zLinux.



The n
ew
a
pplication

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 f
or 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.



Be
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
environment.


10


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

e
nvironment.

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.

I
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
environment.

2.

I
nstall
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 requirem
ents and timing for the
re
-
allocation of staff
positions to
support the new enterprise infrastructure.


C
.
z/Series


1.

Insta
ll IBM’s WebSphere Application S
erver on the
zSeries server

to run under
z/Linux.

2.

Create a secure Linux environment
and assess securi
ty of the environment

on
the zSeries
.


3.

Establish processes
, documentation

and staffing for maintenance and monitoring
of the z/Linux and J2EE mainframe environment.



11

D
.

WebSphere App
lication

Server, Application Development Framework &
Components

1.

Test IB
M’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 cha
nge management.

5.

Implement the necessary infrastructure to support hosting of .NET objects.

6.

Create a JAVA application development framework for the AIS enterprise and
do
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.

7.

Document the baseline hardware/operating system requirements for developer
ma
chines 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 s
oftware 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 data
base environment.



F. Prototype Application and Performance Testing


1.

Implement a prototype J2EE architecture.


12

2.

Implement a “prototype application” in the new environment to demonstrate its
efficacy.

3.

Demonstr
ate “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 docu
ment development standards an
d
required

techniques specific
to the new J2EE
and the .NET
environment
s
.
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 sta
ndards
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
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 l
ist of devel
opers who
need
training in this environment for their work in central administrative systems or
enterprise
-
level systems.

Their preferred timing

within training cohorts

s
hould
also be noted.

3.

Obtain an inventory of participant machines including any plans t
hat 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 hardwa
re 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
Applicati
on Developer

software

licenses for
AIS and non
-
AIS

developers working on central admi
nistrative systems and obtain
additional
hardware where necessary to efficiently run this client software.

5.

Coordinate, fund and schedule training for
AIS and non
-
AIS

deve
lopers to help
them attain a

complete understanding of the new methodologies and tools
for

13

building and succ
essfully running, efficient

enterprise
Java

applications.

6.

Coordinate, f
und and schedule training for AI
S staff involved in sup
port of the
new J2EE
a
nd .NET object server environment.

7.

Negotiate vendor agreements for training, software and other support needs

such
as consulting
.

8.

Coordinate, fund and schedul
e
any additional licenses or tools needed
at training
facilities

for this effort.

9.

Create and commu
nicate 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 Breakdo
wn 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



Est
imated completion time in person hours or months.

10.

Communications Plan (Team, Sponsor and AIS Management
Reporting)


The

Project Manager will:



Coordinate collaborative

project
defini
tion meetings with
stakeholders to discuss

and
develop the project
pl
an and

finalize the scope and
definition.



Distribute Project
Definition

once finalized to
all
stakeholders and project team.



Coordinate
p
roject 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

c
oordinate the completion of a

project
plan and then
review status
r
eports for project tasks
to
stay current with all aspects of the
project.


14



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
.



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



C
reate projec
t status reports
and communicate them
as appropriate either
mont
h
ly or
quarterly

to
stakeholders via email
.



Schedule and conduct s
takeholder 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.



15


12.

Modernization Project Stakeholders List


Name

Role

Responsibility

Contact Info





Ron Rash

Senior Director, AIS

Sponsor and AIS final
decision maker

rhr@psu.edu


Scott Smith

Deputy

Director, AIS

Sponsor and AIS
decision maker for
enterprise
-
wide
strategic projects

sas1@psu.edu


Karen Schultz

Director, Solutions &
Services

Directs the work of
application
development areas

kls2@psu.edu


Mike Kauffman

Manager, Enterprise
Infrastructure, AIS

Manages the work of
mainframe
infrastructure groups
and database
administration on the
mainframe

mjk3@psu.edu


Mike Belinc

Enterprise Ar
chitecture
consulting

Enterprise
Architecture
consulting

mfb1@psu.edu


Pete Dawson

Manager, Mid
-
Tier
Infrastructure

Manages the work of
mid
-
tier infrastructure
groups including
database
administration in the
mid
-
tier e
nvironment

pmd1@psu.edu


Bill Cook

Manager, Database
administration

Manager, database
administration on the
mainframe

wgc1@psu.edu


Phil Hawkins

Enterprise Services
Integration

Te
am lead for this
new group
focusing
on integrating
products such as
iBPM, Mediator
and WebSphere.

pdh2@psu.edu


Todd Litzinger

Manager,
Network
Infrastructure and Data
Security

Network
Infrastructure and
Data Security

tfl13@psu.edu


Vicki Hoffman

Senior Support and
Training Analyst

Coordinates and
facilitates training
needed by AIS or our
customers (content,
delivery and
contracts)

vlw3@psu.edu


Carl Seybold

Ed Hayes


J2EE Consulting

J2EE Consulting

cvs3@psu.edu

emh1@psu.edu





16


AIS
Advisory
Committee which will
also represent the
Development Toolset
Subcommittee below
v
ia Ken Forstmeier



Development Toolset
Subcommittee


Proposed a strategic
direction regarding
the toolsets and
environment used for
development of
enterprise
-
level
administrative
systems.


First report Nov,
2003, final report
November, 2004.









































Kenneth Forstmeier


Committee chair


Don Albertson





Walt Beatty

(until 10/04)




Carol Findley




Steve Focht






Rich Gabel




Craig Hayna
l



Edie Hertzog


(chair
til 9/04
)


Kelley King

(until 7/04)



Carl Seybol
d



Cheryl Seybold





Steve Shala




Mike Sherlock



Vince Timbers



Vicki Hoffman


(began 9/04)


Tim Whitehill










Office of Research
Information Systems


Office of Physical


Plant


College of


Engineering



Registrar’s Office



啮摥r杲g摵a
瑥t


A摭issi潮s⁏ffice



l晦ic攠ef⁒敳敡rc栠
䥮f潲m慴a潮 pys瑥ts


dr慤畡瑥⁓ch潯l


啮rv敲eity B畤来琠


l晦ice


Corporate Controller


AIS


Outreach and


Cooperative


Extension


College of
Agricultural Sciences



Auxiliary and


Business Services


Enr
ollment Mgmt



AIS


University Budget
Offic
e



17



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 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
-
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 follow
s:

--

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 o
f 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 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
tandard
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
processes.


18

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
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 Ar
chitecture?
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 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
s
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
sepa
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:


19

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.

As illustrat
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
-
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 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.




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 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
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.
Th
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
alized registry.