0 оценок0% нашли этот документ полезным (0 голосов)
17 просмотров14 страниц
TU-Wien Service Oriented Architecture Software Architecture Document Version 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.
TU-Wien Service Oriented Architecture Software Architecture Document Version 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.
Авторское право:
Attribution Non-Commercial (BY-NC)
Доступные форматы
Скачайте в формате PDF, TXT или читайте онлайн в Scribd
TU-Wien Service Oriented Architecture Software Architecture Document Version 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.
Авторское право:
Attribution Non-Commercial (BY-NC)
Доступные форматы
Скачайте в формате PDF, TXT или читайте онлайн в Scribd
Service Oriented Architecture 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
Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 3 of 14
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 Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 4 of 14
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.
Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 5 of 14
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.
Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 6 of 14
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.
Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 7 of 14
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:
Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 8 of 14
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. Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 9 of 14
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.
Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 10 of 14
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:
Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 11 of 14
: 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: Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
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:
Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 13 of 14
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. Service Oriented Architecture Version: 1.0 Software Architecture Document Date: 26/March/2005
TU-Wien, 2005 Page 14 of 14
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.
AN ARCHITECTURAL APPROACH FOR QUALITY IMPROVING OF ANDROID APPLICATIONS DEVELOPMENT WHICH IMPLEMENTED TO COMMUNICATION APPLICATION FOR MECHATRONICS ROBOT LABORATORY ONAFT
ChatGPT Side Hustles 2024 - Unlock the Digital Goldmine and Get AI Working for You Fast with More Than 85 Side Hustle Ideas to Boost Passive Income, Create New Cash Flow, and Get Ahead of the Curve
ChatGPT Millionaire 2024 - Bot-Driven Side Hustles, Prompt Engineering Shortcut Secrets, and Automated Income Streams that Print Money While You Sleep. The Ultimate Beginner’s Guide for AI Business
Excel 2023: A Comprehensive Quick Reference Guide to Master All You Need to Know about Excel Fundamentals, Formulas, Functions, & Charts with Real-World Examples
Excel for Beginners 2023: A Step-by-Step and Quick Reference Guide to Master the Fundamentals, Formulas, Functions, & Charts in Excel with Practical Examples | A Complete Excel Shortcuts Cheat Sheet
Microsoft Access Guide to Success: From Fundamentals to Mastery in Crafting Databases, Optimizing Tasks, & Making Unparalleled Impressions [III EDITION]