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.