12.07.2015 Views

Migration of a Chosen Architectural Pattern to Service Oriented ...

Migration of a Chosen Architectural Pattern to Service Oriented ...

Migration of a Chosen Architectural Pattern to Service Oriented ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 5. Guidelines 137generation. OpenESB cannot parse such schemas and prompts informationthat included file was not found. The file exists, moreover it was includedvia Nebeans build-in menu. The way around is <strong>to</strong> copy content <strong>of</strong> includedschemas <strong>to</strong> a current schema but it is neither elegant nor easy <strong>to</strong> maintain,because each change <strong>to</strong> “base” schema requires copping <strong>of</strong> its content <strong>to</strong> thecurrent schema.5. Deprecated methods – since the migrated application was a few years old, itcontained a few deprecated methods related mainly <strong>to</strong> operation on dates.During project building a user is informed that there are some deprecatedmethods that may cause an error and this is only a warning, but whilethe project starts a method that calls a service and contains deprecatedmethods is simply skipped without any information. This is quite seriousproblem during migration, because it may occur that a significant part <strong>of</strong>API is deprecated. The problem can be eliminated relatively easy whenan <strong>of</strong>ficial API is used because the API provides not only information thata method is deprecated; it also provides information which method/classshould be used instead. Usage <strong>of</strong> non-<strong>of</strong>ficial API does not guarantee suchinformation.6. Schema namespaces – produces the most serious technology related problem,which was observed during the migration and it is related <strong>to</strong> variablecoping. Normally coping can be done in two ways.(a) The output variable <strong>of</strong> one activity is copied/casted <strong>to</strong> input variable<strong>of</strong> the second activity. It corresponds <strong>to</strong> Variable1 =Variable2.(b) Each element <strong>of</strong> Variable2 <strong>to</strong> copied <strong>to</strong> Variable1 manually. It corresponds<strong>to</strong> Variable1.element1= Variable2.element1 etc.The problem appears when two variables (Variable2 extends Variable1) arecasted (1st way) but they are from two different namespaces . It shouldwork, but usually it does not [40]. According <strong>to</strong> <strong>of</strong>ficial forum [41]: “Ourtype cast feature isn’t perfect yet. There are quite many restriction for usingit.” All the problems should be resolved in future versions (The problemoccurs with Netbeans 6.7.1). There are at least three possible workarounds.There are at least three possible workarounds. The first is <strong>to</strong> create a version<strong>of</strong> operation for each Variable1 extension and invoke directly appropriateoperation; the second is <strong>to</strong> add a flag that will allow BPEL process <strong>to</strong>invoke a proper operation. The last is <strong>to</strong> avoid different namespaces. Thefirst solution was tested and it works fine.<strong>Migration</strong> was finally accomplished according <strong>to</strong> the guideline, it occurred <strong>to</strong>be more difficult task that it was expected. The difficulties did not arrive fromguidelines adaptation problems but they were technology related. The technology,

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!