TU Wien

TU-Wien
Service Oriented Architecture

Software Architecture Document

Version 1.0

Version: 1.0
Software Architecture Document Date: 26/March/2005

TU-Wien, 2005 Page 2 of 14

Revision History
Date Version Description Author
26/March/2005 1.0 Architectural description of service
oriented exercise
Amin Anjomshoaa

Version: 1.0


Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms and Abbreviations 4
1.4 References 4
1.5 Overview 4
2. Architectural Representation 5
3. Architectural Goals and Constraints 5
3.1 Google Web Service Constraints 5
3.2 Amazon Web Service Constraints 6
3.3 Standards and used technologies 6
4. Use-Case View 7
4.1 Use-Case Realizations 7
4.1.1 Google Search Use case 7
4.1.2 Amazon Search Use case 7
4.1.3 Combined Search Use case 7
5. Logical View 8
5.1 Overview 8
5.2 Architecturally Significant Design Packages 9
5.2.1 Amazon Package 9
5.2.2 Google Package 10
5.2.3 Server Package 10
6. Deployment View 11
7. Implementation View 12
8. Size and Performance 13
9. Quality 13
9.1 Performance 14
9.2 Security 14
9.3 Portability 14
9.4 Reusability 14
Version: 1.0


Software Architecture Document
1. Introduction
This document provides a high level overview of the technical architecture for the Service oriented
architecture exercise. It outlines the technologies that have been used for a simple service oriented
application which uses available services of Google and Amazon to present a new combined service. In
facilitating interoperability through standards, combined service will help its users to enhance their queries
by querying both Google and Amazon simultaneously.

The document provides a high-level description of the goals of the architecture, the use cases support by
the system and architectural styles and components that have been selected to best achieve the use cases.
This framework then allows for the development of the design criteria and documents that define the
technical and domain standards in detail.

1.1 Purpose
This document provides a comprehensive architectural overview of the system, using a number of different
architectural views to depict different aspects of the system. It is intended to capture and convey the
significant architectural decisions which have been made on the system.

With the ability to integrate data and applications through Web services, many opportunities will arise for
greater collaboration and more elaborated services on internet. This document will provide an overview of
technologies used and software architecture.

1.2 Scope
This software architecture document applies to the exercise of Software Architectures course presented in
winter semester 2004 by Distributes Systems Group, Vienna University of Technology.
1.3 Definitions, Acronyms and Abbreviations

SOAP Simple Object Access Protocol, http://www.w3.org/TR/SOAP/
UDDI Universal Description, Discovery and Integration, http://www.uddi.org
URL Uniform Resource Locator, http://www.w3.org/Addressing/rfc1738.txt
WSDL Web Services Definition Language, http://www.w3.org/TR/wsdl
Eclipse Open extensible IDE, http://www.eclipse.org

1.4 References

Service Oriented Architecture specifications,
http://www.infosys.tuwien.ac.at/teaching/courses/SWA/swaAufgabeD.html
1.5 Overview
In the upcoming sections we will discuss the Search Service which is based on a Service Oriented
Architecture. For simplicity we will refer to this application as Search Service in the rest of this document.
In Section 2 the software architecture of the system will be explored and the necessary views to depict the
software architecture are specified. Section 3 describes the architectural goal and constraints. In sections
4,5,6 and 7 the Use-case view, Logical view, Deployment view and Implementation view will be discussed
respectively. In Sections 8 and 9 performance and quality issues will be discussed.

Version: 1.0


2. Architectural Representation
Search Service is an application based on Web Services technologies and standards. The application
receives a keyword from user and then this keyword will be sent to Google and Amazon web services. The
result of these two queries will be combined and returned to end user as one result set.

In the upcoming sections the system architecture will be viewed from different perspectives at a high level
of abstraction that allows us to visualize, understand and reason about the architecturally significant
elements and identify areas of risk that require more detailed elaboration.

The architecture of the reference application is represented following the recommendations of the Rational
Unified Process (RUP). The system specifications have been divided into the following five views:

Use-Case View: Describes the actors and use cases for the system, this view presents the needs of
the user and is elaborated further at the design level to describe discrete flows and constraints in
more detail.

Logical View: This view describes the architecturally significant parts of the design model, such
as its decomposition into subsystems and packages. And for each significant package, its
decomposition into classes and class utilities. We will introduce architecturally significant classes
and describe their responsibilities, as well as important relationships, operations, and attributes.

Deployment View: Describes the deployment structures, by including known deployment
methods. It will also describe the physical network (hardware) configurations on which the
software is deployed and run. In this configuration we will indicate the physical nodes that
execute the software, and their interconnections

Implementation View: This view describes the overall structure of the implementation model, the
decomposition of the software into layers and subsystems in the implementation model, and all
architecturally significant components.

3. Architectural Goals and Constraints
Search Service application is based on 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. In our case this service
will be provided by Google and Amazon web services. More over the mentioned web services will feed our
composition web service.

3.1 Google Web Service Constraints
To access the Google web service, we should have a license key. This key will be available after registering
to Google web service. In each query this license key should be included. Google web service uses this
license key to control and limit the access to its services. The Google Web APIs service is an experimental
free program, so the resources available to support the program are limited. Since the Google web service is
a free beta service, it cannot be guaranteed that every question will be answered by Google team. Also
based on the Google Web APIs terms of service we cannot create a commercial service using Google Web
APIs without first obtaining written consent from Google. Another is that you can only create one account
for your personal use.

Another constraint which has been proposed by exercise specification is that we are not allowed to use
Google API to create web service client application.

Version: 1.0


3.2 Amazon Web Service Constraints
Amazon will identify the end users like Google using a subscription ID. A subscription ID is a unique
identifier connected to Amazon Web Service (AWS). The subscription ID is needed to access any of the
web services offered by AWS. Comparing to Google, Amazon has provided a more commercial-oriented
web service. Amazon Web Services provides a platform that developers can use to create software that
enhances the productivity of Amazon merchants, Associates, or Web site owners, and increases value to
customers.

3.3 Standards and used technologies
The Search Service should use a set of standard technologies for implementation. These standards are those
that are based on Java technologies as well as the some related open source applications. The employed
technologies are as follows:

Java J2SE 1.4.2: Java 2 Standard edition which provides a complete environment for applications
development on desktops and servers.

Apache Axis: Apache Axis is an implementation of the SOAP (Simple Object Access Protocol).
SOAP is a lightweight protocol for exchange of information in a decentralized, distributed
environment. It is an XML based protocol that consists of three parts: an envelope that defines a
framework for describing what is in a message and how to process it, a set of encoding rules for
expressing instances of application-defined data types, and a convention for representing remote
procedure calls and responses.

JBoss 3.2.6: JBoss should be used as Search Service application server. The JBoss/Server is the
leading Open Source, standards-compliant, J2EE based application server implemented in 100%
Pure Java. JBoss Application Server has become a recognized leader in the Java application server
market and is to date the only major application server on the market to deliver a production-ready
J2EE 1.4 certified product. JBoss Application Server has quickly become the most popular
product among Java developers and independent software vendors alike. According to some
independent benchmark tests, JBoss offers improved performance and superior server utilization
to other leading J2EE application servers.

Apache Ant: Apache Ant will be used as build and deployment tool. Apache Ant is a Java-based
build tool. In theory, it is kind of like Make, but without Make's wrinkles; i.e. Instead of a model
where it is extended with shell-based commands, Ant is extended using Java classes. Instead of
writing shell commands, the configuration files are XML-based, calling out a target tree where
various tasks get executed. Each task is run by an object that implements a particular Task
interface.

Eclipse: Eclipse is a kind of universal tool platform - an open extensible IDE for anything and
nothing in particular. It will be used as development tool.

Lomboz: Lomboz is a free eclipse plug-in for the J2EE developers. It will be used to ease creation
of Search Service Bean in Eclipse IDE.

Version: 1.0


4. Use-Case View
This view presents the users perception of the functionality provided by Search Service. These use cases
were included in the exercise specifications and hopefully captures all requested features.
Note that this section provides the context for, and scope of the rest of the document. Putting aside
overriding architectural constraints outlined above all development (in terms of design and content
documentation) has been done in support of one or more of the following use cases.

4.1 Use-Case Realizations
The system will have three major use cases. Tow simple web service clients for accessing Google and
Amazon web services. Also there will be a composition web service, which send a query to Google and
Amazon web services and combines the results.

4.1.1 Google Search Use case
In this use case the end user who is considered as use case actor will ask the system to send a query to
Google. The system will call Google web service and displays the results in a customized format.

4.1.2 Amazon Search Use case
This use case is similar to Google web service, but the query is sent to Amazon web service instead. The
results could be shown in a customized way to the end user.

4.1.3 Combined Search Use case
This combined web service will use the results of the previous two use cases and combines them into a
single web services. The user will send the query to Combined Search web service, then the query will be
forwarded to Google and Amazon web service respectively and the combined results will displayed. The
following diagram shows the interactivity between basic components to fulfill the requirements of this use
case:

Version: 1.0


5. Logical View
This section describes the architecturally significant elements of the search system. The system is
decomposed into some sub-system, to realize the requirements of the above mentioned use cases.

5.1 Overview
The design model is a client server model. Part of the system is automatically generated from the Web
Service Description Language files (WSDL files). These generated files are organized into two packages,
one for Google web service and the other one for Amazon web service. The package names are
googleSearch and amazonSearch respectively. For each web service another package exists which will
play the role of web service client; these packages are called google and amazon.

The most interesting package is server package which includes all the needed classes for search session
bean. This session bean will call the classes in amazon and google package to retrieve the results from
Google and Amazon web services respectively. The google and amazon packages include both web service
clients for part 1 and 2 of exercise and also some methods which will be invoked by search session bean.
Finally the client package contains the EJB client which will invokes the related web service to do
combined queries.
Version: 1.0


5.2 Architecturally Significant Design Packages
In this section we will describe the details of significant packages including the description of important
classes.

5.2.1 Amazon Package
This package includes a java class called AmazonClient which serves as client for Amazon web service
and also provide a method that is called from search session bean. The main method of this class is used for
a simple call to Amazon web service. The class has also a method for serialization of results which are
assumed to be books. Basically it is possible to let the end user to create his/her favorite serialization
methods by overwriting the serializeBook method; however we have decided to implement this method
as a private method which can not be overwritten.

Version: 1.0


5.2.2 Google Package
This package includes a java class called GoogleClient which serves as client for Google web service and
also provide a method that is called from search session bean. The main method of this class is used for a
simple call to Google web service. The class has also another method for serialization of results which are
query items. Basically it is possible to let the end user to create his/her favorite serialization methods by
overwriting the serializeSearchItem method; however we have decided to implement this method as a
private method which can not be overwritten.

5.2.3 Server Package
This package includes the necessary file for our stateless session bean which serves the combined web
service. The following diagram shows all the classes included in this package:
Rerole
SearchPoint
<<EJBRemoteMethod>> runQuery()
SearchPointBean
SearchPointBean()
runQuery()
Loca|
SearchPointLocal
3
SearchPointSession
SearchPointSession()
ejbActivate()
ejbPassivate()
setSessionContext()
<<EJBRemoteMethod>> unsetSessionContext()
ejbRemove()
<<EJBCreateMethod>> ejbCreate()
lore
SearchPointHome
COMP_NAME : String
JNDI_NAME : String
<<EJBCreateMethod>> create()
Loca| lore
SearchPointLocalHome
COMP_NAME : String
JNDI_NAME : String
<<EJBCreateMethod>> create()
SearchPointUtil
hexServerIP : String
SearchPointUtil()
lookupHome()
getHome()
getHome()
getLocalHome()
generateGUID()
getInt()
hexFormat()
padHex()
-$cachedRemoteHome
-$cachedLocalHome

The included files are interfaces and classes for invocation of our enterprise java bean. The method that
does the real task is runQuery which is located in SearchpointBean. The following diagram shows the
interactivity between this class and other classes to perform the query:

Version: 1.0


:
SearchPointBean
google :
GoogleClient
amazon :
AmazonClient
query(String)
bookQuery(String)

6. Deployment View
The system is composed of server side and client side components. The client computer will have only a
simple EJB client component. On the Search Point Server the server side components will be deployed.
This server has JBoss server plus Axis for serving our web service. This server should have access to
Google and Amazon servers for performing queries.

Client
SearchPoint
Server
Google
Server
Amazon
Server

Deployment of our Combined Searche Service on search point server will be done via a web service
deployment description file (WSDD file). The following is the WSDD file used for this purpose:
Version: 1.0


<?xml version="1.0" ?>
<deployment xmlns='http://xml.apache.org/axis/wsdd/'
xmlns:java='http://xml.apache.org/axis/wsdd/providers/java'
xmlns:soap='http://schemas.xmlsoap.org/soap/encoding/'
xmlns:xsi='http://www.w3.org/2000/10/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'>

<service name="SearchPoint" provider="java:EJB">
<parameter name="beanJndiName" value="SearchPointEjb"/>
<parameter name="homeInterfaceName" value="org.amin.server.SearchPointHome"/>
<parameter name="remoteInterfaceName" value="org.amin.server.SearchPoint"/>
<parameter name="allowedMethods" value="runQuery"/>
</service>
</deployment>

The deployment descriptor is called via execution of an Ant script and more explicitly by calling the
following target:


<target name="setup-axispoint" description="Deploy Webservice">
<java classname="org.apache.axis.client.AdminClient" fork="yes">
<classpath refid="master-classpath"/>
<arg value="./wsdl/deploy.wsdd"/>
</java>
</target>

Another important target in Ant file is the EJB deployment target which deploys the created EJB file to
JBoss server.
Also all client applications are accessible via Ant script. To run them on client side only Java run time
environment plus Apache Ant is needed.
7. Implementation View
This section describes the overall structure of the implementation model, the decomposition of the software
into layers and subsystems in the implementation model, and some architecturally significant components.
The overall view of system components are shown in the following diagram:

Version: 1.0


JBoss 3.2.x provides a bundled Web services implementation. This bundled service is called JBoss.NET
and incorporates Axis as a plug-in service for the JBoss microkernel. Deployment of Web services uses the
built-in JBoss deployment system that understands the WSR (Web Service aRchive) packaging.

Axis is an implementation of the Simple Object Access Protocol (SOAP). SOAP is a lightweight protocol
for exchange of information in a decentralized, distributed environment and the protocol is XML-based.
The protocol consists of three parts: an envelope that defines a framework for describing what is in a
message and how to process it, a set of encoding rules for expressing instances of application-defined data
types, and a convention for representing remote procedure calls and responses. Axis can convert an EJB
into a Web service by providing the interface plumbing and the service delivery. The following shows the
components from implementation point of view:

SearchPoint
Combined Web
Service
<<Application>>
Google
Library
Amazon
Library

8. Size and Performance
Web Services applications have the primary goal of sharing and using data between applications. The
Combined search service which send two simple queries and manages a small amount of data will respond
to the requests in time. However some big technical and performance issues for Web services occurs when
a user or application is handling large data or binary files.
W3C's XML Protocol Working Group has been looking at this issue almost from its inception, while it was
developing the first SOAP standard, SOAP 1.2. The newest Recommendations published today work with
SOAP 1.2 to address the specific issue of improving Web services performance by providing standard
methods and mechanisms for transmitting large or binary data.

9. Quality
The overall system quality could be overseen from different aspects. In this section we will discuss some
important quality issues like performance, security, portability, functionality and reusability.
Version: 1.0


9.1 Performance
From the performance point of view the system should be able to respond in a reasonable time. However
evaluating the performance of web service oriented systems is not as easy as traditional architectures.
While Web services ease the building of client-server systems, monitoring service quality is a significant
problem. Consider a client application that submits a transaction on our web service. Our business
transaction involves two Web service calls to Google and Amazon web services. Each call is a distinct
HTTP/SOAP (Simple Object Access Protocol) exchange and the performance of our web service would be
greatly affected by depending web services. Fortunately in our case the underneath web services look to be
stable enough and answering the queries in time.

9.2 Security
Web service security is an important issue in implementation of web services and there are well-known
methods which apply security policies to web services. In our case the security is not our primary concern
since we do a simple query. Should the system be extended to support e-commerce issues for Amazon web
service, the security issues come to play.

9.3 Portability
Portability issues are about abstracting the interfaces that a business application uses to communicate with
the underlying system upon which it is running. The web service oriented architecture has loosely coupled
components which are simply portable to other systems. Also the client application could be web based or
written in any favorite language. The current java client portability is very high, since the only requirement
to run the client is java enabled environment and fortunately the JVM is available for nearly all well known
operating systems.

9.4 Reusability
The focus in Service oriented architecture is not on software reusability but on Service reusability. The
other approaches focused on reusing a piece of code that was then deployed in a new system. SOA does not
focus on a piece of code, but on a running service providing the same functionality. This architecture makes
our software architecture much easier and more reusable; i.e. we can use the same component with a well
defined interface to the outer world over and over.

TU Wien

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TU Wien

Enviado por

Direitos autorais:

Formatos disponíveis

TU-Wien

Service Oriented Architecture

Você também pode gostar