ınformatıon system

Transkript

ınformatıon system

Generated by Foxit PDF Creator © Foxit Software
http://www.foxitsoftware.com For evaluation only.
INFORMATION SYSTEM (IIS)
F. Sancar, S. Kaya, O. Kutlucan, B. Doğan, E. Çimen, H. Sarıtaş
Department of Software Engineering
Middle East Technical University
Ankara ,Turkey
ABSTRACT
As technology evolved, the expectations of the
software users have increased. Therefore, some legacy
systems that are being used today do not satisfy the users.
In order to make business processes more automated,
secure and reliable, either these legacy systems are to be
replaced or rectified. Due to some reasons such as budget
limitations or user familiarity, instead of developing
replacements, it is considered more efficient to use
enhanced versions of the current systems. These
enhancements involve the integration process of the
current scattered legacy systems. Such a goal can be
accomplished only by using proper system architecting
techniques. Constructing such system architecture requires
a well-defined interface skeleton architecture which
specifies the communication channels between these
legacy systems. In this case study, you can find such an
architecture design together with its required components
and also the interface requirements among these
components of Integrated Information System (IIS) for the
purpose of integrating legacy systems in METU.
SOAP
UDDI
WSDL
WSDP
INTRODUCTION
In 1990's, the dominant software development
approach was phased refinement. This approach was
criticized for its high cost of maintenance and the
complexities it brings in system integration. The related
problems in failing to produce reliable software within
reasonable time and cost and the predicted shortage of
software engineers to meet demands for new software,
had given rise to the so called ‘software crisis’. In spite of
all advances in conventional software development tools,
software development is still under the constant threat of
the software crisis.
"Software will be the main element that drives our
necessary capabilities and quality of life and people who
know how best to develop software-intensive systems will
have the greatest opportunity to make a difference in
result.”[1] To be able to do such an impact on software
world, the most difficult task of a software engineer faces
is that he/she has to select the right and suitable
components out of a huge box of them. Choosing and
integrating the components of a new system requires a
good system design. On the other hand, a good system
design must be stationed on a well defined methodology.
From traditional development era until these days, there
have been lots of methodologies used in different types of
projects.
NOMENCLATURE
CMP
COSEML
DAO
EA
EIS
EJB
http
IIS
JAX-RPC
JDO
J2EE
METU
OIDB
RAD
RPC
SOA
Simple Object Access Protocol
Universal Description, Discovery, and
Integration
Web Service Description Language
Web Services Developer Pack
Container Managed Persistency
Component Oriented Software
Engineering Modeling Tool
Data Access Object
Enterprise Architect
Enterprise Information System
Enterprise Java Bean
Hypertext Transfer Protocol
Integrated Information System
Java Application Program Interface for
XML-based Remote Procedure Call
Java Data Objects
Java 2 Enterprise Edition
Middle East Technical University
Ogrenci Isleri Daire Baskanligi
Rapid Application Development
Remote Procedure Call
Service Oriented Architecture
First, we as a whole team investigated all of the process
models from traditional era to now, including agile
processes. "Agile development which is a natural
evolution of Rapid Prototyping approach, can provide
important benefits, but it is not applicable to all projects,
products, people, and situations. It is also not antithetical
to solid software engineering practices and can be applied
as an overriding philosophy for all software work"[2].
1
develop the system integrity under SOA architecture with
the help of a meta language, such as XML. With such an
architecture and system design; the requirements in
between the legacy components of METU are covered
almost completely.
After analyzing the elicited requirements and planning, we
decided to use Rapid Application Development (RAD)
Process Model in our project, IIS. Figure 1 depicts this
process model.
RAD is an incremental software model that emphasizes a
short development cycle. The RAD model is a high speed
adaptation of the Waterfall Model, in which rapid
development is achieved by using a component based
construction approach. Since requirements are well
understood and project's scope is constrained, the RAD
process enables our team to create a fully functional
system within a very short time period. Why did we
choose this model?
COMPONENT INFORMATION AND INTERFACE
REQUIREMENTS
The components included in IIS system shares data with
other components manually. What needs to be done is to
automate this process.
IIS has twenty-nine components in total. These are:
1. The use of pre-existing components would simplify our
work.
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
2. RAD is suitable for small-scale projects and our team
consists of only 6 members.
3. IIS is properly modularized because it consists of
already existing legacy systems.
4. Performance loss resulting from the integration
of components into a whole is neither an issue nor a
requirement.
5. Technical risks are not high.
13)
14)
15)
16)
17)
18)
19)
20)
21)
22)
23)
24)
25)
26)
27)
28)
29)
IIS
The IIS is a combination of software applications that
use services available in a network using web. Currently
the business units at METU has different information
system infrastructure. Besides working on different
environments, they store data in different formats such as
Excel data sheet, text, Oracle, MySQL, XML etc. The
problem at that point is each of these units occasionally
needs information which is processed by another unit.
Therefore, there is a need of an automated system that
allows these units communicate without any data loss,
considering security, eliminating using manual methods
like mailing or using fax etc. The goal of this system is to
combine these different applications (units) and make
them send requests and responses towards each other
safely and with full reliability using a common data
format without changing or affecting the interior of the
existing systems working for those business units.
Genel Sekreterlik
Ogrenci Isleri Daire Baskanligi
Bilgi Islem Daire Baskanligi
Personel Daire Baskanligi
Kutuphane ve Dokumantasyon Daire Baskanligi
Strateji Gelistirme Daire Baskanligi
Saglik, Kultur ve Spor Daire Baskanligi
Personel Daire Baskanligi
Rektorluk
Strateji Gelistirme Daire Baskanligi
AB ve TÜBİTAK Projeleri Personel Birimi
Akademik Değerlendirme ve Kalite Geliştirme
Kurulu - ADEK
Araştırmalar Koordinatörlüğü
Avrupa Birliği Ofisi
Basın Bürosu
Bilgi Edindirme Birimi
Değişim Programları Ofisi
Döner Sermaye İşletme Müdürlüğü
Eğitim Destek Ofisi
Halkla İlişkiler Müdürlüğü
Hukuk Müşavirliği
Kariyer Planlama Merkezi
Kitaplık Müdürlüğü
Kurumsal Gelişim ve Planlama Ofisi
Mezunlarla İletişim Müdürlüğü
Müze
Öğretim Teknolojileri Destek Ofisi
Özel Kalem Müdürlüğü
Sürekli Eğitim Merkezi
In this paper, we have selected ten of them to investigate
in more depth. The related diagrams of these components
can be found in “Figures and Tables” section of this
paper.
Objective
Our objective is to prepare interface design, high
level system requirements and system architecture of the
IIS. We tried to combine these system components and to
Necessary information about the component data needs
are obtained from the BBS.zip file which is appended to
2
the paper.) Details about the components and their
automation requirements are listed below:
This component deals with medical reports and
reservations, Cultural and Convention Center and student
unions activities, sports events and swimming pool
management.
Ogrenci Isleri Daire Baskanligi:
It needs to communicate with the components Kutuphane
ve Dokumantasyon Daire Baskanligi, Personel Daire
Baskanligi, Strateji Gelistirme Daire Baskanligi, Genel
Sekreterlik, Rektorluk, Bilgi Islem Daire Baskanligi, Idari
ve Mali Isler Daire Baskanligi and OIDB components.
Figure 6 shows this component.
Ogrenci Isleri Daire Baskanligi (OIDB) component is
responsible for the processes concerning the students like
student registration, program acceptance, registration
withdrawal, and production of various documents. while
processing these internal tasks, it needs to communicate
with the components Genel Sekreterlik, Bilgi Islem Daire
Baskanligi, Personel Daire Baskanligi, Kutuphane ve
Dokumantasyon Daire Baskanligi, Strateji Gelistirme
Daire Baskanligi, and Saglik, Kultur ve Spor Daire
Baskanligi components. Figure 4 shows this component.
Automation Requirements:
1. It needs to receive student information from OIDB
which
is
currently
done
by
telephone.
2. Online reservation information for first-year student
training needed to be received from Kutuphane ve
Dokumantasyon Daire Baskanligi component which is
currently
done
by
e-mail
or
telephone.
1. The medical reports of the students are being sent by
hard-copies using authorized signatures from Saglik,
Kultur ve Spor Daire Baskanligi component.
2. This component gets instructor and information from
Personel Daire Baskanligi component.
3. Employee and health coupon information shall be
received from Personel Daire Baskanligi component,
which is currently done by telephone or mail.
3. OIDB component needs registration permission and
registration withdrawal information from Kutuphane ve
Dokumantasyon Daire Baskanligi component.
4. Student application and OIBS print outs shall be
received from Bilgi Islem Daire Baskanligi component.
Kutuphane ve Dokumantasyon Daire Baskanligi:
5. Advance pays and purchasing authentication
confirmation shall be received from Strateji Gelistirme
Daire Baskanligi component.
component has tasks like lending, requesting and ordering
books, also the documentation of several other
components. It needs to communicate with the
components Saglik, Kultur ve Spor Daire Baskanligi,
Personel Daire Baskanligi, Strateji Gelistirme Daire
Baskanligi, Genel Sekreterlik, Rektorluk, Bilgi Islem
Daire Baskanligi, Idari ve Mali Isler Daire Baskanligi,
Bilgi Islem Daire Baskanligi, and Idari ve Mali Isler Daire
6. Advance pays authentication confirmation shall be
received from Idari ve Mali Isler Daire Baskanligi
component.
Personel Daire Baskanligi:
Personel Daire Baskanligi is an automation system that
processes the employee applications, dismissals, personal
information, salary and other related information. It needs
to communicate with the components OIDB, Kutuphane
ve Dokumantasyon Daire Baskanligi, Strateji Gelistirme
Daire Baskanligi, Genel Sekreterlik, and Saglik, Kultur ve
Spor Daire Baskanligi components. Figure 7 shows this
component.
1. Kutuphane ve Dokumantasyon Daire Baskanligi
component gets student information from OIDB
component.
2. The component gets abroad employment information
from the Strateji Gelistirme Daire Baskanligi component.
Saglik, Kultur ve Spor Daire Baskanligi:
1. Personel Daire Baskanligi needs to receive registration
withdrawal information from Kutuphane ve
Dokumantasyon Daire Baskanligi.
3
1. Genel Sekreterlik component needs to get maintanance
service requests from Kutuphane ve Dokumantasyon
2. Employee medical reports are needed to be received by
Personel Daire Baskanligi.
3. SGDB payment information shall be received by
Personel Daire Baskanligi from Strateji Gelistirme Daire
Baskanligi.
2. Genel Sekreterlik component needs to get maintanance,
transportation, and guest house services requests from
component.
4. Instructor's academic information shall be received
from OIDB.
3. Personel Daire Baskanligi component sends personnel
labour, public housing and baby farm for personnel data to
Genel Sekreterlik component.
Strateji Gelistirme Daire Baskanligi:
4. OIDB component sends activities booklet and the
statistics data to Genel Sekreterlik component.
This component serves as an automation of the office
responsible for strategic plans, budget and performance
management. It needs to communicate with the
components OIDB, Kutuphane ve Dokumantasyon Daire
Baskanligi, Personel Daire Baskanligi, Yapi Isleri ve
Teknik Daire Baskanligi, and Saglik, Kultur ve Spor Daire
Rektorluk:
Rektörlük is a automation component for registerar's
office. It communicates with the Kutuphane ve
Dokumantasyon Daire Baskanligi, and Saglik, Kultur ve
Spor Daire Baskanligi components. Figure 10 shows this
component.
1. Strateji Gelistirme Daire Baskanligi needs to get
payment information and activity reports from Personel
Daire
Baskanligi.
2. Strateji Gelistirme Daire Baskanligi needs to receive
registration renewal process information from OIDB.
1. Rektörlük component needs to get the all activity
information from Saglik, Kultur ve Spor Daire Baskanligi
component.
3. Strateji Gelistirme Daire Baskanligi shall receive
approvals from Yapi Isleri ve Teknik Daire Baskanligi
component.
2. Rektörlük shall be able to receive announcements and
repairs requests from Kutuphane ve Dokumantasyon
4. Budget records must be transferred from Kutuphane ve
Bilgi Islem Daire Baskanligi:
5. Strateji Gelistirme Daire Baskanligi shall be able to
receive advace payments and purchasing requests from
Saglik, Kultur ve Spor Daire Baskanligi component.
Bilgi Islem Daire Baskanligi is a component which
performs web page, e-mail service, e-thesis and university
computer labs related works. It communicates with the
OIDB, Kutuphane ve Dokumantasyon Daire Baskanligi,
and Saglik, Kultur ve Spor Daire Baskanligi components.
Genel Sekreterlik:
Genel Sekreterlik is a component which deals with
personnel labour, public housing related works and
maintanence services. In order to perform necessary
actions, it needs to communicate with Personel Daire
Baskanligi, OIDB, Kutuphane ve Dokumantasyon Daire
Baskanligi, and Saglik, Kultur ve Spor Daire Baskanligi
components. Figure 9 shows this component.
1. Bilgi Islem Daire Baskanligi component receives the
thesis archieve information and user identity information
from Kutuphane ve Dokumantasyon Daire Baskanligi
component.
2. Registration and graduation information is received
from OIDB component.
4
3. Bilgi Islem Daire Baskanligi component gets student
application information and student union announcements
from the Saglik, Kultur ve Spor Daire Baskanligi
component.
•
Security concept: the components of units cannot
access the other directly, the web service control
all the permission
•
Adaptive system for the new adding components
•
The separation of the service interface from its
implementation
Idari ve Mali Isler Daire Baskanligi:
This component has processes like documentation,
internal service, budget management, purchasing
authorization, circulating capital management. It
communicates with the Kutuphane ve Dokumantasyon
Daire Baskanligi, Yapi Isleri ve Teknik Daire Baskanligi,
and Saglik, Kultur ve Spor Daire Baskanligi components.
Beside considering architectural requirements above,
we also need secure, reliable, and fast service. When we
consider all the requirements, the service-oriented
architecture is consistent for our system design because
SOA is ideal for use in an IT environment where software
and hardware from multiple vendors is deployed, or one in
which existing IT assets are mixed with newer
applications, integration technologies, or data sources.[7]
1. Idari ve Mali Isler Daire Baskanligi shall be able to
receive stock and inventory records and information
source contract information from Kutuphane ve
A service-oriented architecture is essentially a
collection of services where these services communicate
with each other. The communication can involve either
simple data passing or it could involve two or more
services coordinating some activity. A service is a
function that is well-defined, self-contained, and does not
depend on the context or state of other services. In this
system, services are requests between components defined
at the component interface diagram.
Yapi Isleri ve Teknik Daire Baskanligi:
Yapi Isleri ve Teknik Daire Baskanligi is a component
which performs the operations related to commercial
building in METU. It communicates with the Idari ve
Mali Isler Daire Baskanligi and Strateji Gelistirme Daire
Service-orientation aims at a loose coupling of
services with operating systems, programming languages
and other technologies that underlie applications. SOA
separates functions into distinct units, or services, which
developers make accessible over a network in order that
users can combine and reuse them in the production of
applications. These services communicate with each other
by passing data from one service to another, or by
coordinating an activity between two or more services.
1. Yapi Isleri ve Teknik Daire Baskanligi components
needs commercial building and approval information from
Idari ve Mali Isler Daire Baskanligi component.
THE SYSTEM ARCHITECTURE AND DESIGN
FOR IIS SYSTEM
SOA allows for the reuse of existing assets where
new services can be created from an existing IT
infrastructure of systems. In other words, it enables
businesses to leverage existing investments by allowing
them to reuse existing applications, and promises
interoperability between heterogeneous applications and
technologies.
The architecture design for the IIS is built by
evaluating the requirements of component interface. The
requirement document is defined at the appendix. When
we concentrate on the requirements, the system needs
those basic principles:
•
Loosely coupled, location transparent and protocol
independent system
•
Flexibility for the number of external system attached
to the overall system
•
XML based message communication
The following figure illustrates a basic serviceoriented architecture. It shows a service consumer at the
right sending a service request message to a service
provider at the left. The service provider returns a
response message to the service consumer. The request
and subsequent response connections are defined in some
way that is understandable to both the service consumer
and service provider. Web services will use XML to
create a robust connection. Those connections are
5
performed at the Web Services. A service provider can
also be a service consumer.
platforms. On the other hand, J2EE applications acting as
web service clients themselves, and they can communicate
with other web services, regardless of how they are
implemented.
API
Java API for
XML
Processing
(JAXP) 1.2
Description
This API lets you process XML
documents by invoking a SAX or
DOM parser in your application.
JAXP 1.2 supports W3C XML
Schema.
Java API for This is an API for building and
XML-based deploying SOAP+WSDL web
RPC (JAX- services clients and endpoints.
RPC) 1.1
Figure 1- Service provider/consumer
Each service implements one action, such as filling out an
online application for an account, placing an online
booking or airline ticket order. Instead of services
embedding calls to each other in their source code, they
use defined protocols that describe how one or more
services can "talk" to each other.
Java APIs
for XML
Registries
(JAXR)
1.0.4
This is a Java API for accessing
different kinds of XML registries.
It provides you with a single set of
APIs to access a variety of XML
registries, including UDDI and the
ebXML Registry. You don't need
to worry about the nitty-gritty
details of each registry's
information model.
SOAP with This API lets you produce and
Attachments consume messages conforming to
API for Java the SOAP 1.1 specification and
(SAAJ) 1.2 SOAP with Attachments note.
SOA with Web Services
Web services are designed to support interactions and
interoperability between the machines over the network
by using a set of XML-based open standards such as
WSDL, SOAP, and UDDI. By using these standards, a
common approach can be derived to define, publish, and
use the web services. SOAP (Simple Object Access
Protocol), which is a protocol specification for exchanging
structured information in the implementation of the web
services, will be used over HTTP for communication
between service providers and consumers. SOAP makes
use of Application Layer protocols (i.e. Remote Procedure
Call (RPC) and HTTP) for message negotiation and
transmission. Services are semantically defined in XML
and exposed as interfaces defined by WSDL (Web Service
Definition Language). For registry interaction and
searching for services, UDDI, which is a languageindependent protocol is used [6].
JSR 109:
Web
services for
J2EE 1.0
JSR 109 defines deployment
requirements for web services
clients and endpoints by leveraging
the JAX-RPC programming model.
In addition, it defines standard
deployment descriptors using the
XML Schema, thereby providing a
uniform method of deploying web
services onto application servers
through a wide range of tools.
Tablo 1 – Java APIs for XML (JAX) provided by J2EE 1.4 [3]
Under J2EE 1.4, a Web service client can access
J2EE applications. The client can access a Web service
created with the JAX-RPC API; behind the scenes, JAXRPC uses a servlet to implement the Web service. A Web
service client can also access a stateless session bean
through the service endpoint interface of that bean. Web
service clients cannot access other types of enterprise
beans.
Using the J2EE Platform for Developing SOA/Web
Services Frameworks
Sun's Java Web Services Developer Pack 1.5 (Java
WSDP 1.5) and Java 2 Platform, Enterprise Edition
(J2EE) 1.4 is used to develop web services to implement
SOA. By using The J2EE 1.4 platform, we build and
deploy web services. Also we quickly build, test, and
deploy web services and clients that interoperate with
other web services and clients running on Java-based or,
more importantly for our project, non-Java-based
The J2EE 1.4 platform provides a standardized
mechanism to expose servlets and EJBs as web services.
Such services are considered web service endpoints (or
6
web service ports), and can be described using WSDL and
published in a UDDI registry so that they can be
discovered and used by web service clients.
First, client discovers a web service and makes a
request. The web service processes the request and sends
the response back. To get a feeling for what happens
behind the scenes, consider Figure 2, which shows how a
Java client communicates with a Java web service in the
J2EE 1.4 platform. Note that J2EE applications can use
web services published by other providers, regardless of
how they are implemented. In the case of non-Java-based
clients and services, the figure would change slightly,
however. As mentioned earlier, all the details between the
request and the response happen behind the scenes. You
only deal with typical Java programming language
semantics, such as Java method calls, Java data types, and
so forth. You do not need to worry about mapping Java to
XML and vice-versa, or constructing SOAP messages. All
this low-level work is done behind the scenes, allowing
you to focus on the high-level issues.
Figure 3 – Service Oriented Architecture [4]
Figure 2 – A Java client calling a web service [3]
The various components interacting in the SOA
framework are listed below:
External Client: Web browsers, that are the users'
interaction points with the applications, serve as clients
for the applications. These clients correspond to the
components listed in the “Component Information and
Interface Requirements” part of this paper.
EJB Web services: Web services endpoints can be
modeled as stateless session beans according to EJB 1.4
specification.
Data access interfaces: The responsibility of this layer is
to interact with EIS and return data back to the related
EJB Web service method in a format that the method is
expecting. Here various persistence technologies and
7
various techniques such as EJB, CMP, JDO are used to
access the EIS.
CONCLUSION
The IIS project introduced in this paper enables
software design exercisability with an iterative
development process model, RAD. The feedbacks taken
from this study helped us to identify the drawbacks of the
current legacy systems and misinterpreted requirements.
Web Services Gateway: Web Services Gateway is used
by developers and IT managers to safely externalize a
Web service to make it accessible to clients outside the
firewall. A request sent by a client is transformed into the
messaging protocol that service requires using the Web
Services Gateway.
When we tried to decompose the system in a top-todown manner, we thought over the "loosely-coupled"
characteristics of the components of the system. In other
words, we practiced what Jim Waldo explained in his
essay; "Breaking the system down into smaller pieces
requires some thought into what those pieces are going to
be and how they fit together, which is exactly the art of
system design"[8].
RESULTS AND DISCUSSIONS
Major discussions can be listed as follows:
1. Deciding on the process model to which our study is
built on caused discussions in the team. Alternative
process models were Agile Methods, Rapid Prototyping.
As mentioned above in "Introduction" sub-section, RAD
was chosen.
Our study has shown that one can easily extend and
implement the system completely with further
investigations.
2.
Architecture decision also caused some conflicts
among the team. Alternatives were Data-Centered, DataFlow, Object-Oriented architectures. We decided on the
SOA because of the advantages of the J2EE platform and
the ones listed in the "SOA with Web Services"
subsection.
REFERENCES
[1] Boehm , B., "Making a difference in the
Software Century," IEEE Computer, March 2008, pp. 78.
[2] Pressman, R.S., "Software Engineering: A
Practitioner's Approach" 6th Edition 2005, pp. 103-104.
3. Choosing the suitable modeling tool was an issue.
Smart-Draw, COSEML, Enterprise Architect (EA) were
alternatives among which we decided on the EA with
which the team is more experienced with.
[3] http://java.sun.com/developer/technicalArticles
/WebServices/soa/ ; last access date: 07.29.09
[4] http://www.ibm.com/developerworks/webserv
ices/library/ws-designsoa/#2; last access date: 07.29.09
4.
As an application framework, we choose J2EE
because by using this platform, you can build and deploy
web services in your IT infrastructure on the application
server platform. The J2EE platform provides the tools you
need to quickly build, test, and deploy web services and
clients that interoperate with other web services and
clients running on Java-based or non-Java-based
platforms. In addition, it enables businesses to expose
their existing J2EE applications as web services. Servlets
and Enterprise JavaBeans components (EJBs) can be
exposed as web services that can be accessed by Javabased or non-Java-based web service clients. J2EE
applications can act as web service clients themselves, and
they can communicate with other web services, regardless
of how they are implemented"[3].
[5] http://www.ibm.com/developerworks/ webserv
ices/library/ws-soa-design1/; last access date: 07.29.09
[6] http://en.wikipedia.org/wiki/SOAP; last access
date: 07.29.09
[7] http://www.ibm.com/developerworks /webserv
ices/library/ws-soa-adaptleg/ ; last access date: 07.29.09
[8] Waldo, J., "On System
Microsystems, Dec. 2006, pp. 14.
8
Design,”
Sun
FIGURES AND TABLES
Figure 4 – Interactions of Ogrenci Isleri Daire Başkanlığı Component
9
Figure 5 – Interactions of Kutuphane ve Dokumantasyon Daire Başkanlığı Component
Figure 6 – Interactions of Saglik KulturVe Spor Daire Başkanlığı Component
10
Figure 7 – Interactions of Personel Daire Baskanligi Component
Figure 8 – Interactions of Strateji Gelistirme Daire Baskanligi Component
11
Figure 9 – Interactions of Genel Sekreterlik Component
Figure 10 – Interactions of Rektorluk Component
12
Figure 11 – Interactions of Bilgi İşlem Daire Baskanligi Component
Figure 12 – Interactions of İdari ve Mali İsler Daire Baskanligi Component
13
13 – Interactions of Yapi Isleri ve Teknik Daire Baskanligi Component
14
14 – Interactions of All Components
15

ınformatıon system

Transkript

Benzer belgeler