RESULTADO DE RIESGOS Y VULNERABILIDADES ENCONTRADAS

RQ 1 What are the existing techniques of migration toward SOA?

According to Z.Zhang and H.Yang there are three types of migration to SOA [84]: White–Box, Grey–Box and Black–Box. Each type is characterised by dif- ferent properties. The list below presents example techniques classified to those three types of migration( see chapter number 2).

1. White box–This technique needs deep insight view into existing code and documentation of the migrated system. Example: SMART[49]

2. Gray box–This approach is a mix of white and black box techniques. Ap- plication of the technique requires analysis of code of the application and the system with subsystems. Example: Taxonomy Analysis[84].

3. Black box–The technique treats the migrated system as a black box. Mi- gration according this technique bases upon analysis of system’s input and output. Example: Wrapping[23]

There are also some attempts of migration toward SOA based on architectural pattern applied in the migrated systems. Some patterns like Pipe–and–Filters are already part of SOA[70]. Other patterns like Client–Server have prototypes of frameworks automating migration to SOA [36]. There are also some attempts of migration of MVC[73][67][28][78], PCBMER[52] or Peer–to–Peer[69].

In addition to those works, a standard (Architectural–Driven Modernisation) of modernisation of systems was identified. The standard considers migration of systems as a form of modernisation. The standard consists of seven substandards. At the time being, only two substandards are defined. The third substandard (issued in 2009) is especially important in context of this work. The standard is named“Pattern Recognition” and is meant to identify patterns and anti–patterns in order to identify requirements and opportunities for transformation(see section 2.2.1).

RQ.2 What are drawbacks and advantages of identified techniques of migration toward SOA?

The presented techniques of migration have different approach to migration. Their advantages and drawbacks are consequences of the way how they treat the migrated system. Some of advantages and drawbacks were identified while estab- lishing context of the work (see section 1.1) while others were identified during studying related works (see sections 2.1.2, 2.1.3 and 2.1.5 ). Here only the main advantages and drawbacks are mentioned. See respective sections for full list of advantages and drawbacks. The sections for particular techniques are mentioned below.

SMART was classified as a White–Box technique. It generates a lot of docu- mentation but it also gives a deep insight view into the system (see 2.1.2 for more information ).

Taxonomy Analysis was classified as a Gray–Box technique. The main advan- tage of the technique is the fact that relationships between services are identified during identification of services. Application of the technique also gives a deep understanding of the system and relationship between its element. The draw- back is that the technique is executed both on code and documentation of the system. The problem here is with documentation that may not be maintained and the result of the analysis many be misleading(see 2.1.3 for more information). Wrapping is the last colour technique. This Black–Box technique is very spe- cific because it does not require analysis of the code of the system. It treats the system as a black box. Unfortunately, application of the technique requires well

elaborated and consequently maintained documentation in order to identify all input–output pairs and use cases to cover(see 2.1.5 for more information).

In addition to those drawback. The presented techniques do not use architec- tural pattern built into migrated system.

RQ.3 What process employ in order to select the pattern for migration?

There are many architectural pattern. Selection of the pattern for migration needs to be structured and conducted in a way that allows to remove successively patterns that do not fulfil current criteria. The selection of the final pattern is conducted according to following steps:

1. Selection of literature sources

2. Selection of architectural patterns from the literature sources 3. Removal of patterns that exist in only one source

4. Assignment of architectural patterns to selected category 5. Selection of representatives for categories

6. Removal of rarely interacting patterns 7. Prefeasibility study

8. Final Selection

More detailed information about all the steps is presented in chapter 3

RQ.4 Which pattern should be chosen for migration?

Model–View –Controller is the pattern for migration. The pattern was selected because it passed process of selection. MVC was mentioned in revised publication and occurred to be the most generic from within its category. The pattern is also applied with other patterns (see table 3.6). Finally, the pattern was found to be in scope of researches related to migration to SOA (see section 3.4.1)

RQ.5 What elements should be the building blocks of the target archi- tecture?

The target architecture consists of identified SOA architectural pattern. The full list of pattern is presented in table 4.3. Detailed description of the patterns is presented in section 4.6.1

RQ.6 How the target architecture should look like?

The target architecture is a SOA architecture that consist of identified SOA architectural patterns. The architecture is presented in figure 4.4. Motivation behind the structure of architecture is presented in section 4.6.2. The elaborated target architecture divides the system into layers. The layers revolve around interaction with users, applied business processes and basic services. Additionally the architecture presents schemas and policies as parts of the system that should be accessible by services from all layers of the target architecture.

RQ.7 How to translate the selected architectural pattern into the tar- get architecture?

Following steps are proposed for migration from MVC to SOA. 1. Convert MVC into layers

2. Choose main communication protocol 3. Unify used schemas

4. Unify policies

5. Identify and wrap into services all coarse grained utilities 6. Identify and encapsulate access to any external resource 7. Identify and wrap into services all entity related code 8. Identify and wrap into services business rules

9. Provide inventory endpoints to basic services

10. Identify all business processes within the legacy application

11. Identify all statefull services and decide if their state can be deferred 12. Identify current points of access to the migrated system

13. Identify all the places in user interface where a continuous feedback from application to end user is provided

What is important here, each step of migration introduces into the architecture one SOA architectural pattern. Detailed description of guidelines is presented in section 5.2.1. Section 5.4 presents example application of the guidelines.

RQ.8 What are the drawback and advantages of the new technique ?

Information about advantages and drawbacks is presented in section 5.5.3. The most important advantage is that the guidelines consider architectural pat- terns applied in migrated architecture. The most significant drawback is limita- tion of application. The guidelines are applicable only for systems that do not use functions provided by MVC supporting frameworks.

The elaborated guidelines are implementation of White–Box technique. The most important advantage of the guidelines is solution for the drawback that that exist in identified White–Box, Grey–Box and Black–Box techniques, namely“The technique does not consider architectural patterns that are applied in architecture of migrated systems”.