development process of a
general report publication
service implemented using
Web Services
Anders Nilsson & Klas Fahlberg
February 1, 2008
Master’s Thesis in Computing Science, 2*30 ECTS credits
Supervisor at CS-UmU: Jerry Eriksson
Examiner: Per Lindstr¨
om
Ume˚
a University
Department of Computing Science
SE-901 87 UME˚
A
Currently the reports from the business conducted in the Web portal LISA are generated and distributed manually. The people at GE Capital Solutions had a vision where this process is automated and reports can be requested and distributed in LISA.
This thesis is about the software process surrounding the design and implementation of a system for publishing, generating, and distributing reports. Software architecture and Internet security were explored in the in-depth studies in order to obtain the knowl-edge required to create a solid design.
The result of the thesis work is a fully automatic infrastructure for publishing reports designed using a service oriented architecture (SOA). The system is divided into two parts; the service that publishes and generates the reports and a front end that acts as the interface for the user. Our tests show that the system is both easy to use and general enough to support all currently available report types.
1 Introduction 1
2 Problem Description 3
2.1 Problem statement . . . 3
2.1.1 Requirements . . . 3
2.2 Scope . . . 3
2.3 Goals and purpose . . . 4
3 Software development focusing on Software Architecture and SOA 5 3.1 SOA . . . 5
3.1.1 Web Services . . . 6
3.2 Software development processes . . . 6
3.2.1 The Waterfall process . . . 6
3.2.2 Iterative processes . . . 7
3.2.3 Development processes suitable for SOA projects . . . 12
3.2.4 Discussion . . . 13
3.3 Software Architecture . . . 13
3.3.1 Stakeholders . . . 14
3.3.2 Software Architectural Document . . . 14
3.3.3 Views and viewpoints . . . 14
3.3.4 Perspectives . . . 20
3.3.5 Discussion . . . 24
4 Internet security focusing on Web services and J2EE 27 4.1 Basics of security . . . 27
4.1.1 Security requirements and goals . . . 27
4.1.2 Cryptography . . . 29
4.1.3 Critical application security flaws and exploits . . . 33
4.1.4 Threat modeling . . . 37
4.2 Strategies for building robust security . . . 38
4.2.1 The four W’s . . . 39 iii
4.2.2 Unified Process for security design . . . 39 4.2.3 Risk analysis . . . 42 4.2.4 Trade-off analysis . . . 42 4.2.5 Security patterns . . . 43 4.2.6 Best practices . . . 43 4.2.7 Reality checks . . . 43 4.2.8 Security testing . . . 43
4.3 J2EE security architecture . . . 44
4.3.1 J2EE architecture and its logical tiers . . . 45
4.3.2 J2EE security architecture and mechanisms . . . 45
4.4 Web service security - standards and technologies . . . 52
4.4.1 Web service architecture . . . 52
4.4.2 Core security issues . . . 54
4.4.3 Web service security standards . . . 54
5 Accomplishment 57 5.1 Planning . . . 57 5.2 Requirements gathering . . . 57 5.2.1 Mockup . . . 57 5.2.2 Use case . . . 58 5.3 System design . . . 58
5.3.1 The Web Service . . . 59
5.3.2 The front end in LISA . . . 64
5.3.3 The tool for creating report types . . . 65
6 Techniques, softwares and frameworks used 67 6.1 Web Services . . . 67 6.1.1 WSDL . . . 67 6.1.2 SOAP . . . 68 6.1.3 UDDI . . . 69 6.1.4 Java EE 5 . . . 69 6.2 Frameworks . . . 69 6.2.1 Spring . . . 70 6.2.2 XFire . . . 71 6.2.3 Logging . . . 71 6.3 Application servers . . . 71 6.4 Queue management . . . 72 6.5 Other technologies . . . 72 6.5.1 Java Servlet . . . 72 6.5.2 JSP . . . 72 6.5.3 JavaBeans . . . 73
7 Results 75 7.1 Screen shots . . . 75 7.2 Documentation . . . 75 8 Conclusions 85 8.1 Restrictions/Limitations . . . 85 8.2 Future work . . . 86 9 Acknowledgements 87 References 89 A Use case 93 A.1 Use Case UC1: List available reports . . . 93
A.2 Use Case UC2: Request report . . . 94
A.3 Use Case UC3: List report request . . . 95
A.4 Use Case UC4: Delete report . . . 96
A.5 Use Case UC5: Assign report access to users . . . 97
3.1 The different phases in the waterfall model. . . 7
3.2 Illustration of the different phases in the waterfall model, taken from [23]. 9 3.3 The project triangle, taken from [28]. . . 14
3.4 Illustration of how perspectives can be applied to views. . . 21
4.1 Example of an attack tree. . . 38
4.2 Secure UP: Security disciplines, taken from [18] . . . 40
4.3 Protection domains . . . 49
4.4 Web services operational model . . . 53
5.1 An overview of the system. . . 59
5.2 An overview of the elements in the request process. . . 62
7.1 Listing of the report types that are available . . . 76
7.2 An automatically generated input form . . . 77
7.3 The status page for requested reports . . . 78
7.4 The download page for a report . . . 79
7.5 The page for administrating which users has access to a report . . . 80
7.6 The page for administrating which Data IDs a user has access to . . . . 81
7.7 The tool for publishing new reports . . . 82
7.8 The view for adding a parameter . . . 83
Introduction
General Electric - Capital Solutions (referred to as GE from here on) has got a Web portal called LISA where vendors can do business with each other. The vendors regularly request reports on how their businesses are going. At the moment these reports has to be requested, generated and distributed manually. GE wants a system where this process is automated so that a vendor can place an order for a report and make a report request directly in LISA.
This thesis is about the software process surrounding the design and implementation of a general report publication and generation system. The work has been done in close collaboration with the staff working at the IT department at GE’s office in Stockholm. The thesis includes two in-depth studies. One about software development focusing on software architecture and SOA, and one about Internet security focusing on J2EE and Web services.
The following listing contains the outline for this report: – Chapter 2 describes the problem.
– Chapter 3 contains the in-depth study about Software architecture. – Chapter 4 contains the in-depth study about Internet security.
– Chapter 5 explains the accomplishment describing how and why the system was designed and implemented.
– Chapter 6 describes the techniques and softwares used for the implementation. – Chapter 7 contains a discussion of the result and what future work can be. done – Chapter 8 show acknowledgements.
Problem Description
This chapter describes the problem in detail together with goals and purposes.
2.1
Problem statement
As mentioned in the introduction GE wants a more automated way of handling the reports related to the business conducted in the LISA Web portal. The reports are currently generated upon a request via phone or email. The report is created by running a stored database procedure and the resulting file(s) (usually in Excel format) are sent via email back to the vendor.
GE had a vision where an administrator publishes a report in a database. The service would then automatically make the report available to the vendors in LISA. The report is represented in the database by the input parameters and other information related to the report so that it can be requested by the user. Since each vendor has different kinds of reports and come from different countries, the service has to be general and support multiple languages. The security of the service is crucial since the reports can contain sensitive business data.
2.1.1
Requirements
GE only had a few initial requirements. The rest of the requirements were acquired in the software development process. The initial requirements were:
– The system must be general enough to be able to handle all kinds of reports. – The system must support internationalization, making it available in several
lan-guages.
– The access to the reports must be limited in order to protect them from users that are not allowed to see the reports.
2.2
Scope
The scope of the thesis is to design and implement the following prototypes: – A report generation service that publish and generate the reports.
– A Web portal where the vendors can discover and request reports.
– A tool for publishing new reports to the report generation service. The tool will be used by the local administrators.
What falls out of the scope for the thesis is to write the database procedures that generates the actual report files. Some of these procedures already exist and those procedures have been reused to develop the prototype.
2.3
Goals and purpose
The goal of the thesis is to produce an automated system where an administrator can publish new reports that the vendors then can request in an easy-to-use interface. An-other goal is to treat the thesis as a real software development process to utilize the knowledge from the in-depth study about software development. The knowledge gained in the in-depth study about Internet security will be utilized through out the whole development process to make the system secure.
The purpose of the system is to eliminate the manual labor of running database procedures and emailing report files.
Software development focusing
on Software Architecture and
SOA
This chapter will describe some of the most commonly used software development pro-cesses and investigate how these propro-cesses will affect the success rate of a project and which are suitable for SOA development. The chapter also contains a section about Soft-ware Architecture and how views and perspectives can be applied in order to achieve a well documented architecture and a clear overview of the system.
Since it is important to know about SOA in order to compare the different processes that are suitable in SOA projects the chapter will begin with a short description of that architecture.
3.1
SOA
SOA stands for Service Oriented Architecture and is a structure for the communication between services. A service is a small distinct unit of functionality and SOA represents a model where services can be distributed over a network and reused to create business applications. The interaction between the services is defined using a description language and each interaction is independent. The services are loosely coupled meaning that the service interface is independent of the implementation [19, 30].
In [10] the author writes about the following key characteristics of SOA:
– It contains self describing interfaces in XML, which is platform independent. An example is WSDL (Web Service Definition Language), which is a language for describing Web services. WSDL will be covered more thoroughly in chapter 6. – The communication between services is defined using XML-schemas. The
envi-ronment in which the services communicate is often heterogeneous and often there is no information about the provider.
– To keep track of the services a registry where the services are published is used. When an application needs to communicate with a service, the service can be discovered using the registry and the application can invoke its operations. UDDI,
which stands for Universal Description, Definition, and Integration is the standard for communicating with a service registry.
– The fourth characteristic of SOA is that each service has a quality of service associated with it. Some examples are elements of security, such as authorization and authentication.
3.1.1
Web Services
One common way to implement SOA is to use Web services. The distinction between service oriented architecture and Web services is that Web services are about technology while SOA is a software design principle. Web services are services that are built upon a set of standards [10].
By making it possible to implement functional building blocks that can communicate independently from platform and programming language it has become an increasingly popular technique to use [10].
3.2
Software development processes
According to [17] a software project is a set of activities that leads to the production of a software product. It exists many different software processes but they all have four things in common:
1. They contain a software specification where the functionality of the software and constraints on its operations are defined.
2. The software is designed and implemented to meet the specification. 3. The software must be validated to ensure that it has the correct behavior. 4. Evolution of the software where it evolves to meet changing requirements.
A software model is an abstract representation of a software process. Each model describes approaches to different tasks or activities that take place during that process [17].
There are many software development processes available and the following sections will describe some of them in order to see how suitable they are for SOA projects.
3.2.1
The Waterfall process
The waterfall model is a sequential process in which the development is progressed downwards like a waterfall. The model consists of five phases and each of them must be completely finished before the project can progress to the next one [33]. The different phases are illustrated in figure 3.1 on page 7 and described further below.
– Requirements
The first step is to gather the requirements that the system must fulfill. This is done by doing consultation with the users of the system. The constraints and goals are defined in detail and serve as a system specification [17].
Figure 3.1: The different phases in the waterfall model.
– Design
The system is thereafter designed, which will partition the requirements into hard-ware and softhard-ware systems. The architecture is established by identifying the fundamental software system abstractions and their relationships [17].
– Implementation
After the system is designed a set of programs are implemented and tested. Each unit is tested individually in order to verify that it meets its specification [17]. – Verification
The different program units are integrated and tested together to ensure that the system has fulfilled the software requirements. The system is delivered to the customer when all tests have been successfully performed [17].
– Maintenance
The last step includes operation and maintenance of the system. This is normally the longest phase. The system must be adopted to new requirements that have been discovered and errors that were not discovered in earlier stages must be corrected [17].
3.2.2
Iterative processes
The requirements often change when dealing with large software projects. This affects the design and the implementation. Iterative processes address this issue by regularly repeat tasks in iterations, where the specification is developed in conjunction with the software. Three of the most common and interesting iterative processes will be described in the following sections [17].
RUP
The Rational Unified Process is a well documented process that is characterized by three things [11]:
1. Use cases
Use cases are used to discover and record the requirements in the system. They consist of text stories describing how some actor is using the system in order to achieve one or several goals. An actor can be a person, computer system or organization. The characteristic of an actor is that it is something that has a behavior. It can for example be a person or a computer system. A use case is a collection of related success and failure scenarios that describe the actor using the system with the aim to reach goals. A scenario is a sequence of actions and interactions between actors and the system.
A use case can be written in three different levels of formality; brief, casual and fully dressed. Brief use cases are one-paragraph summaries containing the main success scenario. The casual format consists of multiple paragraphs that cover various scenarios. When the use cases are fully dressed every step and variation is documented in detail containing supporting sections such as preconditions and success guaranties.
2. Architecture-Centric
The architecture is a function of the needs of the users, which is captured in the use cases. Since the architecture is central in the unified process it will shape the system.
3. Iterative and Incremental
The rational unified process is an iterative software development process. The development is organized into short iterations of fixed length. At the end of each iteration a result is achieved, which is a tested, integrated, and executable part of the system. Each iteration contains a requirement analysis, design, implementa-tion and testing activity. The system will grow incrementally after each iteraimplementa-tion and become more and more refined.
The iteration process is divided in four major phases: inception, elaboration, con-struction and transition. Figure 3.2 on page 9 illustrates these phases and in which order they are performed. A more detailed description of the phases follow below:
– Inception
The first step is to establish a common vision and basic scope for the project. This is done in the inception phase, which is the smallest of the four iterations. It will include analysis of about 10% of the use cases, creation of a business case, preparation of the development environment, and analysis of the critical non-functional requirements. The purpose is to establish the objectives of the project and determine if it is feasible.
– Elaboration
In the elaboration phase the majority of the use cases are defined in detail and the system architecture is specified. The core architecture that has the highest risk of failure is implemented and tested. The high-risk elements are resolved and an estimate of the overall schedule and resources is created.
Figure 3.2: Illustration of the different phases in the waterfall model, taken from [23].
– Construction
During the construction phase the remaining low-risk and easy elements are implemented. This is the largest phase and is built on the foundation laid in the elaboration phase. Features are developed in short time-boxed iterations where the result of each iteration is an executable release of the software. The end date is set in stone and may not be changed.
– Transition
Transition is the fourth and final step and the goal in this phase is to ensure that the requirements have been met to the satisfaction of the stakeholders. Beta releases are often made available in this step and the feedback from the initial release may further refine the system. The transition phase also includes site preparation, manual completion, and error identification and correction.
During the iterations a number of core workflows are identified and these are; business modeling, requirements, analysis, design, implementation, and test and deployment. These workflows are not sequential and will most likely be worked on during all of the four phases. Figure 3.2 shows during what phases they will be performed. Iterations within RUP are supported in two ways. Each of the four phases may be enacted in an iterative way where the results are developed incrementally. In addition the whole set of phases may also be performed iteratively which can be described as iterations of oterations [17][23].
UML UML stands for Unified Modeling Language and it was developed in conjunc-tion with the unified process. It is a visual language for specifying, constructing and
documenting the artifacts of the system. UML can be applied in three ways: As a sketch with informal and incomplete diagrams which are created to explore the difficult parts of the problem. As a blueprint which contains relatively detailed design diagrams used for either reverse engineering to visualize existing code, or for forward engineering where classes and interfaces are generated from UML. The final way is as a programming lan-guage where executable code automatically is generated from the specification in UML [11].
Agile models
Agile models are a family of development processes which all promote iterative devel-opment throughout the project. A group of people interested in iterative and agile methods met in 2001 and the outcome from that meeting was the Agile Alliance. A manifesto and statement of principles to capture the spirit of agile methods were created by the alliance. The main difference between the waterfall model and agile models is that waterfall features distinct phases with deliverables at each phase, while agile meth-ods have iterations rather than phases. The result of each iteration is working code that can be used to evaluate and respond to changing requirements. Small teams work together with stakeholders in order to develop prototypes in a fast way that can be used as proof of concept or to visually describe the problem. The work that the teams must perform during the iterations is to define the requirements, develop the code, test the code, and verify the code. This results in earlier verification compared to the waterfall model, which will result in much more fine-tuned requirements [20].
Two of the most common agile software development processes are Extreme Pro-gramming and Scrum. Both of them are described in the next two sections.
XP XP or Extreme Programming concentrates on the development rather than the management of a project. The process was developed due to the many projects that were running over budget, could not meet the project plan and were terminated prematurely [21]. XP projects starts with a release planning phase. This phase is followed by a number of iterations, each of which concludes with user acceptance testing. When the users are satisfied with the features, the software is released [22].
XP is based on five values [22]: – Communication
Continuous communication between the customer and the developers is important. This is achieved by having the customer close to the developers where it is possible to quickly decide the requirements and how they should be prioritized.
– Simplicity
The simplicity is achieved by constantly refactoring the code and keeping the number of documents as low as possible. The developers should always start with the simplest solution first and add more functionality later in the project. – Feedback
By writing unit tests the developers get feedback from the system after imple-menting changes. The acceptance tests, which are written by the customers gives the testers feedback on the current state of the system.
– Courage
of how much effort it took to implement. Courage also means persistence. By working on a problem persistently it is more likely to be solved.
– Respect
The team members should respect each other by never committing changes that break the compilation or make existing unit tests fail. Members respect their work by trying to produce as high quality results as possible.
Scrum The name scrum comes from a rugby term for a mass of players engaged with each other to get the job done. In the software development process the job is to develop software that can be released to the production environment. The focus in scrum is not purely on development like in XP, but also on management. The development and management in Scrum are described below [29]:
– Management
Each scrum project has a backlog of work to be done that is produced during the planning phase. The product backlog contains prioritized items describing what will be implemented during the project. When the product backlog is complete the process is divided into a series of short iterations, called sprints. A sprint has its own backlog with the part of the product backlog that the team will implement during the sprint. The two backlogs are however two different things. The sprint backlog is the team’s interpretation of the product backlog and it contains concrete tasks, while the product backlog contains high level requirements.
During a sprint the team has daily meetings, called scrums, where each team member describes what work was done during the previous day and what work will be done during the coming day.
When the implementation is done, which happens when enough of the backlog items have been implemented, management closes the development. The team thereafter performs integration testing, training, and documentation before the product can be released.
– Development
The development is concentrated to the sprints. Before each sprint it is decided what the team will work on during the sprint. Since the product backlog is priori-tized the tasks at the top of the list is chosen for the sprint. Teams develop, wrap, review, and adjust each of the backlog items that were chosen.
The first task that must be done during each sprint is to determine the changes that are necessary to implement the backlog items. The team then writes the code, tests it, and documents the changes. In the wrap stage the team creates the executable that is needed in order to demonstrate the changes. The features are demonstrated and new items are added to the backlog together with a risk assessment.
After each sprint a sprint review is performed where the entire team demonstrates the progress from the sprint. The remaining items in the backlog are also reviewed and new items are added, removed or reprioritized based on the information gained during the last sprint.
3.2.3
Development processes suitable for SOA projects
By looking at the software development processes that have been covered in this section it is hard to directly state which is the most suitable for SOA projects. None of them have all the desirable properties for a service oriented developing process.
This section will compare the waterfall model, RUP and agile processes aginst each other in order to see what advantages and disadvantages they have in a SOA project. Waterfall model
The waterfall model requires that the requirements are well understood and unlikely to change during the system development. A study performed by Bohem and Papaccio showed that a typical software project experience a 25% change in requirements. Other studies shows even higher change rates [11]. A SOA project is not different in this aspect and the waterfall model will not be suitable for this kind of project.
RUP
RUP provides a methodology that is focused on initial requirements, modeling and doc-umentation together with the method principles of agile software development. SOA projects will benefit from these factors since requirements tend to change. RUP also ad-dresses some of the key elements of SOA: re-usability, abstraction of business processes, flexibility, and code that is loosely coupled and finely grained. The reason for that is due to the practice to encourage component based architectures, which are the building blocks for services [3].
A drawback of using RUP in the creation of SOA-type application is that RUP is mostly oriented. Services however include many other factors that object-oriented design leaves out. For example, it ignores the underlying infrastructure such as protocols, location and technologies, and management [3].
When RUP is used the focus is often on large projects that in some cases can take several years to complete. In SOA projects however the system can be divided into smaller services that can be developed separately or become separate small projects. Another problem is that RUP only supports traditional reuse of system components where access to the source code is necessary. In service oriented projects the reuse of components are at another level where entire services can be reused and exchanged [14]. Another drawback that RUP suffers from is that it focuses on top-down develop-ment where systems are developed from scratch. Nowadays a combination of top-down and bottom-up is necessary where both new and existing work is to be combined and understood [14].
When a system that is using a number of services is to be developed much of the initial work is focused on specifying which services to use. Implementation and reuse of the services and how to put them together to a complete system are also important activities. The work is completely different when traditional analysis, design and implementation is performed.
Agile
Agile processes considers changes after every iteration which is a benefit for SOA projects since they consists in a highly uncertain environment where changes to business, code and so on is common. Another advantage is its instant communication with the cus-tomer. This is important since business rules and processes will change during the
project. By having a direct communication with the customer an accurate description of the requirements and business needs can be achieved [3].
The communication between the developers is also high which will increase the pro-ductivity in SOA projects. Small teams and pair programming are example of factors that contribute to this [3].
There are however some drawbacks that must be mentioned. One is the lack of up-front design of the system and of its requirements. When services are used as building blocks a good design must exist. The reason for that is because the services must support changes in the business environment, together with an increasing amount of variables and at the same time work correctly in any situation. The design must therefore be thought through and incorporate all variables [3].
The lack of documentation can be problematic even if it is replaced by constant testing, pair programming and the availability of an on site customer. If a failure in the design exists it may take a long time to discover. It is also arguable if the customer can be available at all time and give a complete picture of the business situation. A good documentation is also important for billing purposes, since it explains the amount of work performed [3].
3.2.4
Discussion
When comparing the different developing processes against each other it becomes clear that there is no process that can be used without some kind of adaption. The waterfall model was excluded due to the high failure rate associated with it. SOA is relatively new and the waterfall model has been around for decades. Although it is possible to change the model to suit SOA in a better way by for example not having the strict boundaries between the different phases, we think it is a bad idea to begin the development process with the waterfall model.
Iterative processes are clearly more suitable for modern projects where there are changes to the requirements during the development. By looking at the development processes described in previous sections we think that RUP is most suitable to fit SOA projects due to factors mentioned earlier. Parts from other methodologies can however be borrowed in order to develop a process that is suitable for the project. Depend-ing on the size and amount of reuse that can be made, different approaches can be applied. Scrum meetings and fast iterations sounds interesting and could increase the productivity in a SOA project, especially for smaller projects.
3.3
Software Architecture
Software architecture is defined as: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationship among them [15]. There are a lot of different aspects and concerns that must be addressed during a software-development process. A good software architecture can help to manage some of the problems that can occur.
Every computer system has an architecture that is constructed from one or several architectural elements. The elements are linked together in some way with different complexity depending on the system. It is also possible that the elements will be inter-acting with elements from other systems. Each element or module possesses a defined set of responsibilities, a defined boundary and a set of defined interfaces which will be
Figure 3.3: The project triangle, taken from [28].
used in the interaction with other modules [16]. Due to this fact it is important to achieve a well defined architecture that is understood by all the people that are involved in the project in some way. The next section will begin with a short description of the stakeholders of a system, followed by sections describing views and perspectives.
3.3.1
Stakeholders
The purpose of a software project is often to develop software that fulfills the require-ments established by interaction with the users. The users are however not the only people that will be affected by the system. There are also developers, administrators, testers and all others that have interest in the realization of the architecture. All these people are referred to as the stakeholders of the system. The stakeholders have different concerns about the architecture, which in many cases conflict with each other. It is often impossible to develop an architecture that satisfies all the important attributes. The project triangle, also called ’the quality triangle’ that can be seen in figure 3.3 on page 14, illustrates the fact that it is impossible to achieve a product that has low cost, high quality and a short time to market. Compromises between these attributes must be done and it is often only possible to choose two of the three corners in the triangle [16, 28].
3.3.2
Software Architectural Document
It is important to document the architecture in such a way that it can be effectively communicated to the different stakeholders. This is done in a software architectural document. The document will contain a comprehensive architectural overview of the system and covers the significant architectural decisions [16].
3.3.3
Views and viewpoints
Views and viewpoints are important concepts in software architecture because they introduce a separation of concerns into the architectural description.
A view is defined as: A representation of one or more structural aspects of an archi-tecture that illustrates how the archiarchi-tecture addresses one or more concerns held by one
or more stakeholders [16].
The content of the view should depend on which stakeholders the view is aimed at. Different stakeholders have different areas of expertise and the views should be designed with that in mind.
A viewpoint is defined as: A collection of patterns, templates, and conventions for structuring one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views [16].
The difference between a view and a viewpoint is that a viewpoint is a way of looking at a system while a view is what you see when looking from the chosen viewpoint. A viewpoint is a set of rules or methods, which will allow the architect of the system to create the architectural document [16, 12].
The following sections will describe some of the most common viewpoints used by software architects where each viewpoint contains models that are of importance to-gether with possible problems associated with the viewpoint.
Functional viewpoint
Definition: Describes the system’s runtime functional elements and their responsibilities, interfaces and primary interactions [16].
The functional view is the foundation of the architecture description and it illustrates how the system can assess the functional requirements.
Functional Structure Model The elements that a functional structure model con-tains are functional elements, interfaces, connectors and external entities [16].
A functional element is a part that has well defined interfaces, which makes it possible to connect it to other functional elements. Examples can be a software module, an application package or something similar. The interfaces are needed since they define the inputs, outputs, and the semantics of the operations. Connectors are used in the linkage between the elements and they allow the different elements to communicate with each other. The external entities represent other systems, hardware devices or some other element that the system communicates with [16].
Problems One common problem that a software architect can face when constructing the functional view is that the interfaces are poorly defined because the responsibilities of the elements are not fully understood. The view can also become overloaded with information that belong in other viewpoints. It is important to write the diagrams that include the element definitions. A diagram without definitions will lead to a model that is meaningless [16].
Since the functional viewpoint is of interest to many types of stakeholders where each needs to be communicated to in different ways, it can be hard to create a single model or notation that is suitable for everyone. Several models must be created with different modeling languages depending on the stakeholders [16].
Information viewpoint
Definition: Describes the way the architecture stores, manipulates, manages, and dis-tributes information [16].
The information viewpoint will, as the definition states, describe how the system handles information. This is important since all information system stores, manipulates or distributes information in some way [16].
The topics that the information viewpoint must assess are the structure and content of the information, the flow of information, data ownership, latency, references, trans-action management and recovery, data quality, and data volumes and regulations. The following three models are common in the information viewpoint [16].
Static Data Structure Models The static data structure model describes the static structure of the data, which consists of the important data elements and the relation-ships between them. Examples of techniques in data analysis are Entity-relationship modeling1
, and class models2
[16].
Information Flow Models To model how data is transferred from one component to another the information flow model has been created. The model studies the dynamic movement of information between the different components of the system, other systems or parts of the outside world. Coupled with each flow is a direction, information about the volume of data, the scope of the data, and the means by which the data is transferred [16].
Information Lifecycle Models The information in a system will probably change after a while and therefore it is important to analyze how the data changes over time. This is done in the information lifecycle model. Data often changes during its lifecycle in response to external events in updates, until it is deleted. This scenario is captured in entity life histories. The record of the overall changes in a system is presented in the state transition models. An example of a state transition model is a UML state diagram which contains the possible state transitions for an object [16].
Problems Several problems can occur in a system from an information viewpoint. Different systems have different representation of data which can lead to incompatibility. The data can also be inaccurate, inconsistent or incomplete. These problems must be identified early in the process in order to be avoided [16].
The data can be updated from several locations at once which must be handled by the system by developing strategies for resolving inconsistencies. Some solution such as always overriding old updates with never ones, or maintaining two copies of data and resolving problems manually can be used [16].
The latency associated with the retrieval of information can be a problem if it is unexpectedly poor. The problem can arise from overly complex architectures that are not designed to handle the volumes of data that they are presented with [16].
Concurrency viewpoint
Definition: Describes the concurrency structure of the system, mapping functional ele-ments to concurrency units to clearly identify the parts of the system that can execute concurrently, and shows how this is coordinated and controlled [16].
1
A relational schema used to model a system and its requirement in a top-down approach. Entity relationship diagrams is an end product of the modeling process.
2
Model where static class objects in a system and relationship between them are showed. The UML class model is a common notation.
Many information systems today sit idle until an external event occurs and respond to the event by doing some processing. Since several events can occur at the same time the architecture must be designed to handle concurrency. The concurrency viewpoint assesses this by defining the parts of the system that can run simultaneously and how the parts are controlled [16].
The concurrency viewpoint is important because it will help stakeholders understand the constraints and requirements associated with concurrency. It will also help avoid-ing common problems that can occur when several parts run simultaneously such as deadlocks and bottlenecks [16].
System-Level concurrency models A system-level concurrency model associates functional elements with runtime execution entities. The model contains a number of items that is used in the description of the view [16]:
– An operating system process that provides an environment for the execution of one or many threads. It is assumed that the processes cannot interfere with each other in any other way than through a communication mechanism.
– A process group contains processes that are closely related to each other. The details of the processes in the group are not specified.
– An operating system thread that run within an operating system process. – In a concurrent system different processes need to communicate with each other
in order to pass information within the system. This is done via interprocess communication mechanisms.
State models A state model describes which states the runtime elements in a system can be in, together with the transitions between the states. A state machine is a col-lection of states and transitions for one runtime element. All interesting state machines contribute to the overall state model [16].
A state model contains the following elements:
– A state that describes a condition for a runtime element. – A transition that defines the change from one state to another.
– An event, which indicates that something has happened and often trigger some event.
– An action is an atomic piece that can be associated with a transition.
Problems One problem that can arise when building the concurrency viewpoint is that the models can become too detailed. It is better to concentrate on what is archi-tectural important, which is the overall concurrency structure. Since the concurrency in a system can be hard to understand it is important to keep the complexity low [16]. Other problems that can occur, if not careful considerations are taken at an early stage, are deadlocks and race conditions [16].
Development viewpoint
Definition: Describes the architecture that supports the software development process [16].
Since almost every software project has some element of development it can be of importance to create a development view. The reason for this is because it often requires a lot of effort to plan the development environment. The development viewpoint describes how the code is structured, dependencies, build and configuration management of deliverables, system-wide design constraints, and which standards to use [16]. Module structure models A module structure specifies which modules that the source code should be grouped in and how the modules communicate with each other at a higher level. Modules that are closely related can be grouped into layers together with the specification of the dependencies between them [16].
Common design models In order to reduce risk and duplication, standard ap-proaches can be decided upon. It can also be helpful to have commonality among the system elements because it will decrease the technical coherence, which makes it easier to operate and maintain. The common design model specifies pieces that define these attributes [16].
Codeline models The codeline model will define the overall structure of the system’s code. It also specifies how the code is controlled in form of configuration management, where different types of source code should be located, and how it should be maintained [16].
Problems This view is not intended to be a full design of how the system should be implemented. It is therefore important to keep the amount of work at a reasonable level. The architect must also be careful with the distribution of the level of details. It is easy to have an uneven focus on things which will make some concerns clear but other more difficult to understand [16].
Deployment viewpoint
Definition: Describes the environment into which the system will be deployed, including the dependencies the system has on its runtime environment [16].
After the software has been implemented and tested it will be put into a real environ-ment where it will operate. The deployenviron-ment viewpoint specifies the physical environenviron-ment in which the system is intended to run. It also defines the hardware required, the tech-nical requirements for the hardware, and the mapping of the software elements to the hardware in which it will operate [16].
Runtime platform Models The runtime platform is the main model in the deploy-ment viewpoint. The model defines what hardware is required, the network connections between the nodes, and which software elements are hosted on which hardware nodes [16].
In the model each computer is represented as a processing node and client hardware as client nodes. The storage hardware together with the capacity and speed is also specified both for online and offline storage nodes. Network links are captured in the
model, but the bandwidth requirements are not specified. The system’s functional elements are mapped to the processing nodes in which they will execute [16].
Network models This model will define a specification of the network in which the system will operate. The specification contains which nodes should be connected, the network hardware, and the bandwidth requirements. Processing nodes, network nodes, and network connection describes the model and is typically represented as a network diagram [16].
Technology dependency models To manage dependencies in the deployment envi-ronment a technology dependency model can be created. The technology dependencies can be documented for each node in tabular form [16].
Problems Many dependencies in the runtime environment is invisible and can not be checked easily. It is important to specify which versions are required and if patches are available. The use of new and unproven technology can also be risky because it can lead to functional shortcomings, less performance, availability, or security. Another problem can be to gather all the expertise required in order to design, develop, operate and maintain the different technologies [16].
Operational viewpoint
Definition: Describes how the system will be operated, administrated, and supported when it is running its production environment[16].
The operational viewpoint illustrates the operational concerns that the user of the system is likely to encounter together with the solutions that can be applied during the implementation in order to solve the concerns [16].
Installation models This model describes how the system can be moved from the development environment to the production environment. The installation model il-lustrates what needs to be installed or upgraded in order to move the system to its operational environment, the dependencies between the parts that is installed or up-graded, the constraints on the installation process, and what need to be done in order to undo the process if something goes wrong [16].
Migration models The migration model defines the strategy that will be used if a migration process is required. This includes the overall strategy to migrate information and users to the system, how the system will be populated, how the synchronization between the new and the old environment will be kept, and how the migration process can be undone [16].
Configuration management models Some systems will need constant reconfigura-tion, which makes it necessary to have a configuration management model. The model should address which configuration items exist and how they are managed, the depen-dencies that exists between the configuration groups, the different configuration value sets required for normal operation, and how the values will be applied to the system [16].
Administration models When a system has been developed and is running in the operational environment it must be maintained and administrated to some extent. The administration model will define the operational requirements and constraints of the architecture. The model should define the monitoring and control facilities that are provided in the system. It should also define the required routine procedures that an administrator must perform at a regular basis together with likely error conditions [16]. Support models It is very likely that the stakeholder will require some sort of support when the system is operational. The support model will provide information about what groups need the support, what kind of incidents can occur, which support providers exists and which responsibilities they have. In addition to that an escalation plan also needs to be documented. The escalation plan describes the process when several support providers need to contribute together in order to solve the incident [16].
Problems There can often be a gap between the development staff and the operational staff, which can lead to difficulties if both parties are not engaged early in the develop-ment process. Software is often passed to the operational staff without much thought on operational requirements. It is also important to have backout plans if something goes wrong and things need to be undone and migration plans if one system is to be replaced by the new system [16].
Another factor that can cause some problems is the lack of management tools. The developers can manage the system by using their knowledge of the system. The oper-ational staffs often do not possess that knowledge and thus require more sophisticated management tools [16].
3.3.4
Perspectives
Definition: An architectural perspective is a collection of activities, tactics, and guide-lines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’s architectural views [16].
There exist some quality attributes that are common among all the views described earlier. It would not work well to define a new view for each quality property. Instead perspectives are used as an orthogonal way of describing these attributes. A perspective is applied to each view but it is never handled alone and in isolation. Figure 3.4 on page 21 illustrates how the perspectives are applied to the views where each square represents the application of a perspective to a view. The perspectives will work as guides on how to analyze and modify the architecture in order to make sure that the system possesses the particular quality attributes. Different perspectives have different effect on a system and the amount of effort that is applied to each perspective can therefore vary depending on the system. The perspectives should be applied as early as possible in the design of the architecture in order to help avoid problems with lack of performance, availability and so on [16].
Security perspective
Security is often of most importance for large information systems and special concerns must be taken into consideration when designing the architecture. There are five steps that an architect should perform when applying the perspective on a view [16].
Figure 3.4: Illustration of how perspectives can be applied to views.
In the first step the sensitive resources are identified. This action will establish what needs to be secured in the system rather than how to secure it. The identification process is performed with the security requirements together with the functional and information views as input.
The second action will define the security policy or a trust model. This step will form the basis for the security implementation in the system. During the work with this model the people that can be trusted in the system must be identified together with their access rights to resources. The model must also include the integrity guarantees required within the system and the accountability required when sensitive resources are accessed.
In the third step the threats to the system are identified which will define what in the system needs to be protected and what it needs to be protected against. A common notation used when defining the threat model is an attack tree that contains an illustration of the threats that the system faces and the likely probability of each occurring.
The fourth action is to design the security infrastructure that enforces the system’s security policy. Technologies such as single sign on, firewalls, cryptographic technologies, and so on are decided upon in this step which will affect a number of views, primarily the functional, information, deployment and operational views.
In the fifth and last step in the security perspective the security risks are assessed. This means that the risks needs to be reevaluated in order to see if an acceptable cost and risk balance has been achieved [16].
Problems When applying the security perspective there are some problems that can occur. One common problem is that the security policies become too complicated. Security is hard to implement as it is and if the policy is complex the job becomes
much more difficult during both the implementation and operation. This will increase the likelihood of flaws in the security implementation. Other problems can occur when unproven security technologies are used. One security flaw is enough to expose the whole system. To avoid further problems the security infrastructure should be able to handle failures in a safe way in order to avoid unexpected failures that opens up a hole in the security. It is also important that the system can be administrated effectively when the system is operating. The administration tools should be able to handle the system load and be designed for the system [16].
Many security mechanisms rely on some reliable time source in order to work. If the time can be altered in some way there is a flaw in the mechanism that could lead to security issues [16].
If no clear requirements or models are specified there is no way to ensure that the system is secure. It is difficult to add the security after the implementation. It will lead to a lot of rework, if it is even possible. There can also be the case that parts of the system are secured in some way while other parts are not. An example can be that a transfer of a file from one location to another is encrypted but the storage is not [16]. Performance and Scalability perspective
The performance and scalability perspective is important because these factors can cause problems if they are not considered at an early stage. Although Moore’s law states that the number of transistors that can be placed on an integrated circuit is doubled every eighteen to twenty-four months, the tasks that the systems must perform also become much more complicated. The systems must handle more data, users, and so on. The performance of a software system depends on more than just the processing power. The way software is written, hardware configured, and resources allocated and handled are factors that play an important role when it comes to performance [16].
Scalability is also a measure of performance, but it focuses on how well the system will perform when the workload increases. If a system can handle the workload currently present but has poor scalability properties it will perform poorly when the workload increases [16].
The first step that must be done when a performance and scalability perspective is applied is to capture the performance requirements. The requirements should be quantitative which makes it possible to analyze and measure if they are met. After the performance requirements have been established the performance model can be created. The model should provide the ability to assess the maximum workload of the system and supply estimates for capacity planning. By analyzing the performance model it can be calibrated and the system throughput under different scenarios can be estimated. In parallel with the analyze of the performance model, practical testing should also be performed. The practical test can include benchmarks or other measures with the goal to determine some performance metric. When the performance analysis and the practical testing are finished the results of these activities should be compared with the performance requirements. If they differ modifications on the architecture may be needed in order to fulfill the requirements. It is also possible that further testing is necessary in which case the performance analysis and the practical testing need to be repeated [16].
Problems It is common that software projects fail to have a complete and clear set of performance goals or even to address scalability concerns. This will lead to problems
since a suitable framework for designing, tuning, and building the system will not be available. Another concern is that the performance model does not capture all the performance issues in the system. The model is an abstraction of reality and is only as good as its match with the reality. A common pitfall is to oversimplify the performance testing and modeling process. The practical tests that are performed must reflect how the real system will behave in order to get a reliable measurement [16].
Invalid environment and platform assumptions can also occur when new technology is used or technology that has never been used before is tested. It is also common that problem arises although there exists technology to avoid the problems. This can happen when the technology is misconfigured, used in the wrong way, or when the developers decides to write the software themselves [16].
When concurrency is introduced in the system the potential for contention is high. The reason for this is that threads often spend a lot of time waiting for other threads to finish in order for it to continue to solve the task. To avoid bottlenecks it is important to test the behavior of critical elements as early as possible [16].
Hardware has become cheap which leads to an increased amount of available com-puting power. Nowadays we do not have to be so careful with allocating resources. It is however a costly process of freeing up resources such as memory and locks at runtime, which has got a negative effect on the performance of the system [16].
Availability and resilience perspective
The availability and resilience is important if the system has high requirements regarding these factors. A system must often be available at all time [16].
In order to ensure that the architecture is designed with an availability and resilience perspective a number of actions must be taken [16]:
1. The first step is to capture the availability requirements by working with the stakeholders to understand and validate the availability and categorizing them by the service they provide.
2. After the requirements are acquired an availability schedule should be produced. The schedule defines when the different system services need to be available and if the service under any period does not need to be in service.
3. In the third step an estimate of the platform availability is produced which will provide an accurate estimate of the availability of the underlying hardware and software. The estimate is the maximum theoretical availability that the system can provide.
4. In parallel with the estimate of the platform availability an estimate of the func-tional availability should also be done. This action must be performed since the system design will likely impose further unavailability of the system. In many cases a system require some period where it can not provide full functionality due to internal processing, updates, or some other task that must be performed. By drawing a functional availability schedule it becomes clear under which periods the system cannot provide full functionality.
5. After the estimates have been done an assessment of the architecture against the requirements must be performed. This action includes ensuring that the overall level of availability is acceptable and that the no availability risks are too high. If the requirements are not met the architecture needs to be reworked.
Problems One common problem introduced in some systems is the single point of failure, which means that if one single element fails the whole architecture fails. The risk can be reduced by introducing replication and duplication but it can be very expensive. If a requirement states that the system must be available all time, maintenance and other task that must be performed during operation can be difficult. It is therefore important to assess the requirements in order to establish if it is cost effective to have the high availability [16].
Another problem that can occur is that different pieces of third-party software do not work together in a perfect way. If they do not work together under normal conditions it is unlikely that they will work correctly during a failure [16].
Evolution perspective
Software systems often change over time and software that has not been designed with respect to this property can be difficult to change. The evolution perspective deals with the fact that the architecture should be designed in a way that changes can be performed as easy as possible [16].
The first step that must be taken in order for the architecture design to fulfill the evo-lution requirements is to characterize the evoevo-lution needs. This implies understanding the requirements and further analysis of the existing requirements. It must be deter-mined what is likely to change over time, the type of change, magnitude of the change, likelihood of the change, and timescale of the required change. For each of the evolution requirements defined a scenario should be developed. The scenario will explain how the system must change in order to meet the requirement when it becomes necessary [16].
If the architecture need changes in order to support the evolution requirements the effort of creating a flexible system can be done during initial development or when the system changes are required. The choice depends on the type of system and the likelihood that the changes will be required [16].
Problems A problem that often occurs during the design of the architecture is that focus is put on wrong things. When this happens the architecture becomes more complex and expensive to build but not easy to change. Another problem can arise if the system is too flexible. It can affect the runtime efficiency and performance. It is however not impossible to design an architecture that have both high performance and high flexibility [16].
3.3.5
Discussion
All the viewpoints and perspectives that have been described in this chapter are of importance in a SOA project. The functional viewpoint is important since it will describe most of the functional requirements that exists and how they can be assessed. The viewpoint will contain the interfaces of the system and well defined interfaces are very important in SOA development.
The information viewpoint will describe how the architecture stores, manipulates, manages and distributes information which is of importance in service based architec-tures.
In SOA services can be executed concurrently and the architecture must be designed with this knowledge in order to avoid the problems that are associated with it. The concurrency viewpoint can contribute to the elimination of possible failures and help
the stakeholders to understand the constraints and requirements associated with con-currency.
The development, deployment and operational viewpoints apply to almost every system that is developed and deployed in a production environment. Systems developed in SOA will therefore benefit from an architecture that has been planned with these viewpoints in mind.
In addition to the viewpoints every perspective will also describe properties that are important in service oriented systems. The security is often very important in a business application and a whole chapter has therefore been assigned to that area. Since services often are accessible over a network scalability and performance become increasingly important. If a SOA application is not scalable and has good performance the bussiness can suffer big consequences financially. The availability perspective will also be of most importance since the services must be able to handle requests at any time. If a service is not available it can also lead to consequences that have a big impact on the company that is responsible for the system.
When a service oriented architecture is developed it is often impossible to apply every model of every viewpoint to every perspective. It would probably take too long time to produce all the artefacts associated with the different tasks. Depending of the project the artefacts to produce must be prioritized and only the most important to the project can be developed.
Internet security focusing on
Web services and J2EE
This chapter will cover the key concepts in security and the mechanisms behind them. It will also cover the specific security challenges in the J2EE and Web service environments and how they are handled.
Doing business in today’s world usually requires that a company utilize the Internet for both business-to-customer and business-to-business interactions. Everyone relies on information from a variety of sources and tend to depend on its accuracy and reliability in making their own business decisions. The information is often mission-critical, market-valued or confidential. Therefore the information must be protected while traveling over the Internet to avoid threats and risks such as service interruptions, unauthorized access, stealing and altering of information, impersonation, the spreading of viruses, and so on [1, 18].
Security is, unfortunately, in most projects considered a post-deployment event at the end of the development phase or an after-the-fact reaction when something goes wrong. Most business and organizations recognize the importance of information security, but very few have implemented strategies and processes to proactively identify and counter the risks they face. Not having good security often results in businesses and organizations suffering huge financial losses and losing customer confidence [18].
4.1
Basics of security
This section will describe the key concepts and goals of information security.
4.1.1
Security requirements and goals
When we speak of security in software, it can refer to many areas of the system; appli-cations, data, networks, communiappli-cations, users, host systems, and so forth. There are some common security requirements and goals in these areas that involve the protection of data. These concepts will be named and explained in the following sections.
Confidentiality
Confidentiality is the concept of protecting sensitive data from being viewable by an unauthorized entity. There are many types of information that falls under the category of sensitive data. Some data may be illegal to compromise, such as medical records or a customer’s credit card number. Other data may be sensitive in the way that it may uncover too much information about an application. To protect the confidentiality the data must be protected from unauthorized users during transit and in storage. This is often accomplished by using encryption algorithms [18]. Encryption is discussed in more depth in the cryptography section.
Integrity
Integrity is the concept of ensuring that data has not been altered by an unknown entity during transit or storage. For example, the information in an email could be altered during transit, or a program available for download on a web site could be altered to con-tain malicious code, such as a virus or a Trojan horse. Many communication protocols, including the popular TCP/IP protocol, use checksums or CRC (Cyclic Redundancy Check) algorithms to verify data integrity. These techniques are however easy to over-come. An adversary could insert malicious content and then alter other insignificant parts of the data so that the CRC calculates the same value as before. To counter this threat, strong one-way hash functions have been developed. These functions make it computationally infeasible to create the same hash value from two different inputs [18]. One-way hash functions are discussed in more depth later in the cryptography section.
Authentication
Authentication is the concept of ensuring that a user’s identity is truly what the user claims it to be. This is generally accomplished by having the user present his identity together with a piece of information that could only be produced by that user. The most common piece of information is a password. This ensures that users are who they say they are [9, 18].
There are however several ways a password could be compromised. For example, the confidentiality of the password could be compromised if it is sent over an unsecured line. Passwords are also easily exposed in other ways because people often write passwords down and leave them in places where other people easily can discover them. Another problem with passwords is that the same password is used for many different services. If one service is compromised it opens up multiple targets for potential abuse [18].
Passwords are an example of authentication based on what you know. Other ways of authentication can be based on what you have and what you are. An example of what you have-authentication is the device you use to log on to for example an Internet bank. It presents you with a challenge, the device generates a response from the challenge and you send back the response. The what you are-authentication is usually based on some sort of biometric. It can be for example a fingerprint or voice patterns. Each of these have their own weaknesses, therefore they are often combined to create a stronger authentication. For example, Internet banks often require both the response from the device and a PIN number or password. This way they combine what you have (the device) with what you know (the PIN number) to get a stronger authentication [18].
