ESCANEO DE LA PÁGINA WEB BAJO LA HERRAMIENTA OWASP ZAP

The guidelines presented previously were a base for migration of the student’s project. Purpose of the this migration was didactic. It was meant to illustrate an example application of the guidelines. The migration was conducted according to the sequence listed above. As a result of migration, an asset storing process was created. This is also the only fully implemented process in the migrated project (see BPEL 5.19, deploy model 5.20). The migrated process consists of following steps:

1. Create Asset object via UI

2. Retrieve the highest stored Asset id in the database 3. Generate unique identifier for the entity

The migration process identified few technology related issues affecting the migration. The issues were following:

1. Encapsulation – The project had very poor implementation that even did not include encapsulation of properties of classes.All the properties were ac- cessible via <objectName>.<property>.Lack of access methods (get /set) did not allow migrate classes as there were. Additional implementation of access methods was enforced by openESB. In fact this is very minor issue because today Integrated Development Environments (IDE) allows gener- ating access methods automatically. The IDEs allow also to identify places in the code where a property is used explicitly. Both features helped to refactor code in required scope.

2. Redundant operations – Connection to a service requires creation of a ser- vice client in the application. Netbeans supports this activity by generation of stubs of services, ports, connections, operations and messages stubs au- tomatically. IDE will generate only stubs of classes that are inputs for operations or that are building blocks of operation input message. So far so good, but the problem arises in special circumstances as it was with migrated project, namely one of the classes extended the other (CrCom- puter extends CrAsset) and this sub class (CrComputer) was neither a part of any existing operation of Canonical Resource service nor a part of any message accepted by this service. So when a user wanted to pass CrCom- puter object through an operation which takes CrAsset as an argument (what is possible thanks to polymorphism), it was impossible because a stub for CrComputer was not created; consequently a user has no possibil- ity to use CrComputer stub at all. Creation of CrComputer stub manually does not work either because the IDE recognizes changes and before run, it rebuilds generated classes, besides there is no guaranty that autogenerated client does not depend on any “behind the scene” configuration files. The only possible solution was to create a “doing nothing” operation that takes CrComputer as an input- this operation ensures that the missing stub is generated properly.

3. Dependency refresh – IDE generates and refreshes automatically dependen- cies created during project development, at least in theory. It appeared several times that a part of removed dependency was left somewhere in a WSDL document, configuration file or somewhere else. Each case caused hard to find problems.

4. Schema inclusion – XML schema allows to include other schemas from the same or different namespace and use imported elements/complex types as own. The problem arises when a schema that imports other schemas is used in a WSDL document, this in turn is an input for automatic client

generation. OpenESB cannot parse such schemas and prompts information that included file was not found. The file exists, moreover it was included via Nebeans build-in menu. The way around is to copy content of included schemas to a current schema but it is neither elegant nor easy to maintain, because each change to “base” schema requires copping of its content to the current schema.

5. Deprecated methods – since the migrated application was a few years old, it contained a few deprecated methods related mainly to operation on dates. During project building a user is informed that there are some deprecated methods that may cause an error and this is only a warning, but while the project starts a method that calls a service and contains deprecated methods is simply skipped without any information. This is quite serious problem during migration, because it may occur that a significant part of API is deprecated. The problem can be eliminated relatively easy when an official API is used because the API provides not only information that a method is deprecated; it also provides information which method/class should be used instead. Usage of non-official API does not guarantee such information.

6. Schema namespaces – produces the most serious technology related prob- lem, which was observed during the migration and it is related to variable coping. Normally coping can be done in two ways.

(a) The output variable of one activity is copied/casted to input variable of the second activity. It corresponds to Variable1 =Variable2.

(b) Each element of Variable2 to copied to Variable1 manually. It corre- sponds to Variable1.element1= Variable2.element1 etc.

The problem appears when two variables (Variable2 extends Variable1) are casted (1st way) but they are from two different namespaces . It should work, but usually it does not [40]. According to official forum [41]: “Our type cast feature isn’t perfect yet. There are quite many restriction for using it.” All the problems should be resolved in future versions (The problem occurs with Netbeans 6.7.1). There are at least three possible workarounds. There are at least three possible workarounds. The first is to create a version of operation for each Variable1 extension and invoke directly appropriate operation; the second is to add a flag that will allow BPEL process to invoke a proper operation. The last is to avoid different namespaces. The first solution was tested and it works fine.

Migration was finally accomplished according to the guideline, it occurred to be more difficult task that it was expected. The difficulties did not arrive from guidelines adaptation problems but they were technology related. The technology,

namely vendor implementation, played more significant role than it was expected. This fact underlines a role of vendor selection and in the same time it questions vendor diversity as SOA advantage. Additionally, application of some guidelines did not bring any result because there was no related code ( see figure 5.21 for the result architecture ).