SOA Models Upgrade. SOA Industry Models v.8.8. IBM Industry Models IBM Industry Models Development

Transcription

1 IBM Industry Models Development SOA Models Upgrade SOA Industry Models v.8.8 IBM Industry Models Licensed Materials - Property of IBM

2 Contents Contents...2 UPGRADING IBM PROCESS AND SERVICE MODELS...3 Planning the upgrade...4 Performing the upgrade...5 Preparing the customized UML models...5 Preparing the RSA workspace content for the upgrade...7 Upgrading the customized UML models...8 Upgrading the customized BPMN models...14 Upgrading the business vocabulary...16 Validating the upgraded model set...17 Generating the OPM IPS Product Modelling Guide Licensed Materials - Property of IBM

3 Upgrading IBM Process and Service Models Customised models based on some version of IBM Banking Process and Service (BPS) Models or IBM Insurance Process and Service (IPS) can be upgraded to incorporate business content and representational constructs found in a later version of the those models. This document describes the recommended upgrade procedure. Note, the upgrade procedure is the same for BPS and IPS, and for simplification, the acronym SOA (Service Oriented Architecture) is used throughout the document to refer to either set of models. Scope In short, an upgrade in this context signifies the transfer of new model content: from a released (out-of-the-box) version of the IBM SOA Models in the form associated with the for Standard Tooling deployment option into a set of models that came about by customisation of an older released version of IBM SOA Models in the form associated with the for Standard Tooling deployment option Only customised model upgrade is considered because the upgrade of un-customised models is trivial, consisting of simple replacement of the older released version of IBM SOA Models with the newer one. With regard to deployment options, there are two: for Standard Tooling and for m1. Starting with version 8.8 IBM SOA Models are only delivered in the form suitable for deploying to Standard Tooling, while older versions were delivered in both forms. If the merging of new content needs to take place between sets of models associated with different deployment options, a migration of content from one form to the other is required as part of the upgrade. However, migration procedures are outside of the scope of this topic. Also outside of its scope is the upgrade of models associated with the for m1 deployment option. Terminology For the sake of clarity, the involved model sets and individual models are from here on in the topic and its subtopics referred to only as: Old SOA A set of models that constitute a released (out-of-the-box) version of IBM SOA Models Working SOA A set of models that resulted from the customisation of Old SOA (this set of models is the upgrade target) New SOA A set of models that constitute a released (out-of-the-box) version of IBM SOA Models newer than Old SOA (this set of models contains the new content for the upgrade) Upgraded SOA The set of models produced by the upgrade Old model A model belonging to Old SOA Working model A model belonging to Working SOA New model A model belonging to New SOA Upgraded model A model belonging to Upgraded SOA The subtopics describe the stages of an SOA Models upgrade, in the order in which they should be undertaken. Licensed Materials - Property of IBM IPS Product Modelling Guide 3

4 Planning the upgrade A successful upgrade depends on proper handling of a number of factors and a well thought-out plan. Orchestrating model changes during upgrade Typically, there is a master Working SOA model set into which all changes made by modellers in an organisation are integrated. A master model and development freeze should be effected for the upgrade. A master model freeze means that modellers are not permitted to make updates to the master models. A development freeze further requires of them to integrate their modelling work into the master models before the freeze and to suspend work even on local copies of the models during the freeze. The only modification to the master SOA allowed during this freeze is the upgrade itself. In theory these measures are not obligatory, however, they are very highly recommended as their nonapplication would result in the need for more than one upgrade by possibly more than one person, involving high risk to the integrity and quality of the master models. Complying with tooling requirements The New SOA may rely on newer versions of tooling (RSA and IGC) than are in use currently in your organisation. If this is the case, upgrades of these tools must be performed before an upgrade of SOA can start. Pre-requisite tooling versions for the New SOA are stated in its product documentation. Deciding on the New SOA version Working SOA models should be upgraded to the newest available version of SOA, unless there is a good reason for upgrading to some other version. This minimises the number of upgrades that need to be performed in the long run and ensures the best level of support by the IBM Industry Models team. Understanding the Working models and the New models An SOA for Standard Tooling model set consists of three types of model: Rational Software Architect (RSA) Unified Modeling Language (UML) models These models are viewed and manipulated in RSA (they are contained in the RSA project found in the IBM SOA Models installation). In v8.8 the UML models are: Business Object Model (BOM) Interface Design Model (IDM) Transfer Object Model (TOM) Web Service Design Model (WSDM) Java Service Design Model (JSDM) Message Service Design Model (MSDM) Design Model Datatypes (DMD) RESTful API Design Model (RADM) The same UML models are included in older SOA versions except for RADM which is new in v8.8. In some cases those existing UML models would have been known under different names, see the following document: Renamed service models: ata/88/ren_ser_mod.html) Business Process Model and Notation (BPMN) models These models are shipped in two formats: RSA-native (contained in the RSA project found in the IBM SOA Models installation) and generic BPMN (located in thebpmn2.0 Files folder of the installation). The BPMN models are: Analysis Process Model (APM) Orchestration Process Model (OPM) An InfoSphere Information Governance Catalog (IGC) business vocabulary This model can be viewed and manipulated in IGC in IBM InfoSphere Information Server and can be viewed in RSA if IGC for Eclipse is installed (the vocabulary is delivered in an xml file, found in theinfosphere Business Glossary directory in the IBM SOA Models installation). 4 IPS Product Modelling Guide Licensed Materials - Property of IBM

5 Some or all of the models in the Working SOA will have been customized. At the same time, these same models in the New SOA may have changed in comparison with the Old SOA. The changes brought about in the Old SOA by customisation (resulting in the Working SOA) and those in the New SOA when compared with the Old SOA may be conflictive in some areas. How these areas of the models are best included in the Upgraded SOA is a question that can be answered only if the business content and constructs in all the models are understood well. The What s new section in the documentation for a released version of the SOA lists all the differences between that SOA and the previous version. If the Old SOA (upon which the Working SOA is based) and the New SOA are not successive versions, more than one What s new topic must be studied for a complete picture of differences relevant to the planned upgrade. A thorough analysis of the content of the New SOA and how it relates to the Working SOA, with particular emphasis on identifying expected change conflicts, is essential for a successful upgrade. Performing the upgrade This topic describes in detail the practical steps that effect a full upgrade of an SOA Models set. The workflow in Figure 1 defines the order in which the upgrade steps should be performed. The parallel gateway (a diamond with a plus sign) indicates that the branches that follow it can be performed in parallel. The main significance of this in the context of an SOA Models upgrade is that the flows branching from such a gateway can be performed in any order. Parallel upgrading of the different models (if more than one person is involved) is also possible. The orchestration of such an approach is outside of the scope of this topic, but would be straightforward to plan and execute once the upgrade process is understood. Figure 1 Upgrade task ordering Preparing the customized UML models In some cases, preparation is needed before the compare and merge procedure can be applied to the UML models. For information on the sequencing of upgrade tasks, including this one, see Performing the upgrade. The following scenarios require special preparation. When the Working SOA is based on SOA Models v8.6 or older and transfer objects have been customized in the IDM In SOA Models v8.6 or older, transfer objects are located in the IDM, for example in package <<transfer objects>> B_IDM::com::ibm::ima::bps::Transfer Objects for BPS v8.6. and they are located in the Transfer Object Model (TOM) in v8.7 and newer, in package <<transfer objects>> B_TOM::com::ibm::ima::bps::Transfer Objects. If the Working SOA is based on a version with transfer objects in the IDM, these need to be moved to a TOM, because compare and merge works on a per-model basis and does not detect inter-model moves of content. Procedure To move IDM-based transfer objects to a TOM in the old and Working SOA: 1. Prepare an RSA workspace so that it contains the New SOA, the Old SOA and the Working SOA projects. Typically, you will be fetching the Working SOA using a source control system and Licensed Materials - Property of IBM IPS Product Modelling Guide 5

6 importing the old and New SOA projects from the released files, as explained in the following document: Importing BPS UML and BPMN models into RSA /import_soa_rsa.html 2. Open each of the three projects (right-click on project then click Open Project) 3. Copy the TOM from the New SOA project to the Old SOA project and the Working SOA project by following these steps: a) In the Project Explorer view in RSA, make sure that the UML model files are displayed (click on the down-pointing triangle in the upper right corner of the Project Explorer view to see the View Menu and click Customize View, click on the Filters tab and make sure that UML Model Files is not selected, by de-selecting if needed, then click OK) b) Expand the New SOA project, then select the file B_TOM.emx and press Ctrl+C c) Select the Old SOA project and press Ctrl+V d) Select the Working SOA project and press Ctrl+V 4. To move the transfer object content from the IDM to the TOM, perform the following steps for both the old and the Working SOA. a) Open the IDM and the TOM in the old/working SOA project, by double-clicking on the model elements B_IDM and B_TOM b) Expand both models, then in each expand the <<namespace>>com package and its descendants, until you have expanded the <<transfer objects>> Transfer Objects package c) In the TOM, delete all the child elements of the<<transfer objects>> Transfer Objects package except for the<<common>> Common package (select the elements, then press Delete) d) Expand the<<common>> Common package and from it delete all its child elements e) In the IDM, select all the child elements of the<<transfer objects>> Transfer Objects package except for the<<common>> Common package, then drag the selection to the<<transfer objects>> Transfer Objects package in the TOM (it is important to drag and not cut and paste, as the latter may result in loss of information). Figure 2 shows these child elements being dragged to the TOM. f) In the IDM, select all the child elements of the<<common>> Common package except for the<<transfer object, base>> BaseTransferObject data type, then drag the selection to the<<common>> Common package in the TOM g) In the IDM, select the<<transfer object, base>> BaseTransferObject in the<<common>> Common package, then drag the selection to the<<transfer objects>> Transfer Objects package in the TOM h) Delete the<<transfer objects>> Transfer Objects package from the IDM 6 IPS Product Modelling Guide Licensed Materials - Property of IBM

7 Figure 2 Moving transfer object content from IDM to TOM Result The Working SOA based on an SOA Models version older than 8.7 and the corresponding Old SOA are prepared for the compare and merge upgrade procedure. Preparing the RSA workspace content for the upgrade This step involves preparing the four RSA-based model sets involved in the upgrade. For information on the sequencing of upgrade tasks, including this one, see Performing the upgrade (the parent topic). Procedure To prepare the RSA workspace content for the upgrade: 1. Prepare an RSA workspace so that it contains the New SOA, the Old SOA and the Working SOA projects. Typically, you will be fetching the Working SOA using a source control system and Licensed Materials - Property of IBM IPS Product Modelling Guide 7

8 importing the old and New SOA projects from the released files, as explained in the following document: Importing BPS UML and BPMN models into RSA /import_soa_rsa.html Or you may already have the three projects in a workspace, for example if you were performing a preparatory step described in Preparing the customized UML models. 2. Make a copy of the New SOA project and give it the name you want for the Upgraded SOA project (in the Project Explorer view in RSA, right-click the New SOA project, click Copy, right-click in the empty space in the Project Explorer view and click Paste, type the name for the Upgraded SOA project in the Project name field and click OK). This copy is the target project for upgraded models, i.e. the Upgraded SOA target project, which will contain the RSA-based portion of the Upgraded SOA at the end of the upgrade process. Figure 2 shows an example of an RSA workspace used for an upgrade. The workspace contains projects BPS87 for Standard Tooling (the Old SOA), Working - based on BPS87 for Standard Tooling (the Working SOA), BPS88 for Standard Tooling (the New SOA) and Upgrade target based on BPS88 for Standard Tooling (the project for the Upgraded SOA). The Upgrade target based on BPS88 for Standard Tooling is at this stage an exact copy of BPS88 for Standard Tooling. Figure 3 An upgrade RSA workspace, containing the four projects involved Result The RSA projects involved in the upgrade are fully prepared. Upgrading the customized UML models The UML models that have been customized in the Working SOA are upgraded using the RSA-native three-way compare and merge capabilities. For information on the sequencing of upgrade tasks, including this one, see Performing the upgrade (the parent topic). To upgrade the customised UML models by using the RSA-native compare and merge function, perform the following steps for each customized model. Procedure 1. Identify the model corresponding to the model you are upgrading in each of the projects. Keep in mind that model names may have changed between SOA Models versions. For example, if you are upgrading the Web Service Design Model (WSDM) to v8.8, in the old and Working SOA this model is called Service Design Model (SDM) and the model element isb_sdm, while in the new BPS it is called Web Service Design Model (WSDM) and the model element isb_wsdm, owing to the name change in v8.8. Figure 3 shows the four instances of WSDM in the example upgrade RSA workspace. 8 IPS Product Modelling Guide Licensed Materials - Property of IBM

9 Licensed Materials - Property of IBM IPS Product Modelling Guide 9

10 Figure 4 The four RSA projects in the upgrade workspace, with the WSDM indicated in each project with a blue rectangle; in the old and Working SOA the model is called Service Design Model (SDM) 10 IPS Product Modelling Guide Licensed Materials - Property of IBM

11 2. Select the model in the Working SOA, the Old SOA and the upgrade target projects (you can make a multiple selection by holding down the Ctrl key), right click on the selection and click Compare With > Each Other. Figure 4 illustrates this for the example upgrade RSA workspace. Figure 5 Initiating the RSA-native three-way compare and merge function on the working, old and upgrade target models 3. When a dialog window pops up asking which resource you would like to use as the common ancestor in the three-way compare, click the name of the file containing the Old SOA project and click OK. Figure 5 shows this dialog for the WSDM in the example upgrade RSA workspace. Licensed Materials - Property of IBM IPS Product Modelling Guide 11

12 Figure 6 Selection of common ancestor for the three-way compare 4. If the Compare View in opened with the upgrade target as the Left contributor and the Working SOA as the Right contributor, click the Reorganize Contributors icon at the top right of the view. Figure 6 illustrates this scenario. The dialog that pops up allows you to specify the roles of the projects. Using the list and arrows, arrange the projects so that the Working SOA project is specified as the left contributor, the upgrade target project as the right contributor and the Old SOA project remains the ancestor. Click Restart. Figure 7 The Compare view with the upgrade target project as left contributor and Working SOA project as the right contributor 5. Look at the changes reported by the three-way compare and analyse them. They fall into three groups: conflicts, left changes and right changes. Each group can be viewed by clicking on the corresponding tab in the upper left pane of the RSA Compare view. For help with systematizing the analysis of the changes, which can be numerous, use the filter, sorting and structuring capabilities, which are accessed by clicking the top right button in the upper left pane of the RSA Compare view. The aim of the analysis is to decide how conflicts will be resolved and whether all or only some of the working and new content will be included in the merged model. 6. To merge the models, you first have to accept the changes that you want to include in the merged model. Typically, you will be accepting all the changes. To accept all the changes from the working model, click the Left Changes tab in the upper left pane of the Compare view, then rightclick Changes related to Left contributor > Accept All Changes from Left. Analogously, you can accept the changes from the new model by clicking the Right Changes tab. You may, however, 12 IPS Product Modelling Guide Licensed Materials - Property of IBM

13 decide that you want to accept only some of the changes. In this case, expand the Left Changes and Right Changes trees in the upper left pane and right-click individual items or subtrees, then clicking Accept or Reject according to the merge plan that was decided upon. In the Conflicts page in the upper left pane of the Compare view, each conflict is shown with two changes, the change from the working model and the change from the new model. Right-click on the conflict to specify how it should be resolved: the options on the pop-up menu are Resolve with Left Contributor, Resolve with Right Contributor and Ignore (Keep Ancestor s Value). Some conflicts may require editing of the models outside of the Compare session but these scenarios cannot be prescriptive and are not within the scope of this topic. View the compare and merge function not as an easy and complete solution, but rather only as an aid in the merge, which consists foremost of analysis, planning and solving the problems specific to the upgrade or a particular customized model. 7. In order for the new Industry Models Utilities to work with the upgraded model, you must accept any model name and keyword changes. Figure 7 shows the three items in the Compare view in RSA that relate to WSDM name and keyword changes. Figure 8 Changes relating to model name and keyword change for the WSDM, where the Right contributor in the compare is the new model 8. Once you have accepted or rejected all the changes, you are ready to save the merged model. Hover the mouse pointer over the buttons in the upper right corner of the upper right pane of the Compare view to find the Save as Right contributor button and click it. The merged model is then saved into the upgrade target project. 9. If the model being upgraded is BOM and the business vocabulary is not in use as part of the Working SOA, you should remove the Business Glossary profile from BOM. The reason for this is that even if the profile was removed before, it will have been included in the BOM again during the upgrade procedure. To remove the Business Glossary profile from BOM: a) In the Project Explorer view in RSA, select BOM in the upgrade target project b) In the Properties view, click the Profiles tab and select Business Glossary in the table c) Click Remove Profile, then click OK in the warning message dialog that appears Licensed Materials - Property of IBM IPS Product Modelling Guide 13

14 Result d) Click on BOM again and press Ctrl+S to save the model The merged model, including working and new model content, is in the upgrade target project. You may still have manual modifications to make to the upgraded model, depending on the issues found during the compare and merge session. Upgrading the customized BPMN models The upgrade of Business Process Model and Notation (BPMN) models involves the comparison and merging at the level of directory structures and files. For information on the sequencing of upgrade tasks, including this one, see Performing the upgrade (the parent topic). The upgrade procedure described in this topic should be applied to the Analysis Process Model (APM) if it was customized and to the Orchestration Process Model (OPM) only if it was customized directly, that is, by manual modification of the OPM model. If the customized OPM was generated from a customized APM it should not be upgraded using this procedure but generated at the end of the upgrade (step Generating the OPM). Procedure To upgrade the directly customised BPMN models, perform the following steps for each model. 1. For this step you will need a directory and file compare utility such as WinMerge, BeyondCompare or the Linux diff command (the examples in this topic were prepared using the diff command, which can be run under Cygwin in MS Windows, as it provides fairly generic output). Use the utility to recursively compare the model folder (B_APM or B_OPM) in the Old SOA with the model folder in upgrade target project and then with the model folder in the Working SOA. Regardless of what method you use, the aim is to form a picture of the files that have been added or deleted and files that have different content in the two compared models. Figure 8 shows the diff command comparison of the APM in the Old SOA project with the APM in the upgrade target project (which at this stage still contains the APM from the New SOA), for the example introduced in Preparing the RSA workspace content for the upgrade. Figure 9 shows the comparison between the APS in the old and Working SOA project, for the same example. The results of the comparison indicate that 5 files or directories have been added or deleted and that 543 files have been modified in the New SOA, when compared with the Old SOA. Also, three files have been added or deleted and three files modified in the Working SOA, when compared with the Old SOA. Figure 9 Comparison between the APM folders in the Old SOA and the upgrade target projects of the example 14 IPS Product Modelling Guide Licensed Materials - Property of IBM

15 Figure 10 Comparison between APM folder in the Old SOA and the Working SOA projects of the example upgrade Analyse the file additions and deletions to find pairs that actually represent file name changes or file moves from one directory to another. Close inspection of additions and deletions in the comparison results for the New SOA against the Old SOA in the example in Figure 8 shows that there are two addition-deletion pairs in fact representing file name changes and one that is a move of a file to a new folder. Similarly, in the Working SOA one addition-deletion pair (shown in Figure 9) represents a move of a file to a different folder. In the Working SOA there is also a genuine new file. 2. Once you have identified these false additions and deletions, re-name and move files so as to achieve the same directory and file hierarchy in all three models for these files. Typically, you will want the resulting hierarchy to include all the file names and locations introduced in the new and Working SOA. Some of these changes in the new and working model may turn out to be in conflict, in which case you must resolve them as appropriate with respect to the Working SOA purpose. 3. Repeat the comparisons performed in Step 1. This time the results should only report genuine file additions and deletions, as well as file differences. Use the results from this step in the following steps. You will find that using a visual tool makes the analysis of the results easier than the basic output produced by the diff command. 4. You do not need to do anything for files that have been deleted from both the working and the New SOA, or for files that have changed in the New SOA but not in the Working SOA. These are properly represented in the upgrade target project. 5. For each file found to have been newly added in the Working SOA, copy the file into the upgrade target project, into the same APM folder in which it is located in the Working SOA 6. For each file found to have changed in the Working SOA but not in the New SOA, replace the file in the New SOA with the file from the Working SOA 7. Each file found to have been deleted from either the working or New SOA but not from the other poses a conflict and you must make a decision based on the specific file purpose and its content as to whether you want to delete or retain it in the upgraded model. This is particularly true if a file has been deleted in the New SOA but was customized in the Working SOA. 8. Finally, any file that has changed in both the working and the New SOA, you must create a merged file that includes changes from both. This is not straightforward as none of the available methods involves a visual representation of changes such as RSA provides during the comparison of UML models. One method for comparing and merging BPMN files is to use the RSA three-way compare between the old, working and new BPMN file, with the old file as the ancestor in the comparison. The procedure is described in Upgrading the customized UML models. The main difference between using this method for UML and BPMN content is that the RSA Compare includes visual representations of changes relating to diagrams when comparing UML models but not when comparing BPMN models. Owing to the diagram-centred nature of BPMN, the absence of a visual representation makes understanding changes and, in particular, conflicts very difficult. Figure 11 Licensed Materials - Property of IBM IPS Product Modelling Guide 15

16 shows an example of a three-way compare being initiated on BPMN files. This method is recommended in the case where there are no conflicts and changes from the Left and from the Right can be accepted without analysis to create the upgraded BPMN file. Figure 11 Initiating the RSA three-way compare between files representing the same BPMN process in the Old SOA, upgrade target and Working SOA projects Another method is to perform a text-file comparison between the files and merge changes at that level. This is recommended only when changes are minor, for example name changes. Finally, if either of these comparison methods show that there are conflicts between the changes to the working and new file, the BPMN files can be opened in RSA and the file contained in the upgrade target project edited manually so that the customizations are added to it in the same way as they were added to the old file. Result The APM in the upgrade target project is now upgraded. Upgrading the business vocabulary The upgrade of the Business Vocabulary makes use of the InfoSphere Information Governance Catalog (IGC) native compare and merge capabilities. For information on the sequencing of upgrade tasks, including this one, see Performing the upgrade. 16 IPS Product Modelling Guide Licensed Materials - Property of IBM

17 If the business vocabulary is in use as part of the Working SOA, it should be upgraded. The upgrade process is described in the following documents: Upgrading the business vocabulary m/upg/is/upg_bus_voc.html Example procedure to directly upgrade a published Business Glossary m/upg/is/exa_pro_dir.html In preparation for the validation of the entire Working SOA, if you have upgraded the vocabulary you now have to load it into RSA, as explained in the following document: Importing the vocabulary into RSA _vocab_rsa.html Validating the upgraded model set Upgraded models should be validated and any validation problems dealt with before the master working models are replaced with the upgraded models. For information on the sequencing of upgrade tasks, including this one, see Performing the upgrade. Validation of SOA models are explained in the following documents: Validating Industry Models in RSA (for UML and BPMN models) o_gui/val_im_rsa.html and Validating Industry Models in IGC (for the business vocabulary) o_gui/val_im_ibg.html All the models in the Upgraded SOA should be validated, except in some cases, the OPM. The models that were not customized in the Working SOA and were simply copied from the New SOA into the Upgraded SOA should be validated, because they may have inter-model relationships, contributing to overall model set integrity, or lack thereof. The OPM validation should not be performed at this stage if the OPM had not been customized directly in the Working SOA but the APM had been customized. In this case, the OPM in the upgrade target project is identical to the new OPM and does not agree with the other models, which resulted from merges of customized and new content. The OPM should be validated after it is generated (step Generating the OPM). The other models should be validated before OPM generation, if it is taking place, as this validation is required as part of the OPM generation procedure anyway. Generating the OPM The upgraded OPM is generated from the upgraded APM in the case that the Orchestration Process Model (OPM) was not directly customized in the Working SOA but the Analysis Process Model (APM) was customized. For information on the sequencing of upgrade tasks, including this one, see Performing the upgrade (the parent topic). To generate the OPM in the upgrade target project in RSA (see Preparing the RSA workspace content for the upgrade), follow the instructions from the following document: APM to OPM Transform Utility o_gui/apm_opm_tra.html Once the OPM is generated in the upgrade target project, it should be validated as explained at Validating Industry Models in RSA o_gui/val_im_rsa.html Licensed Materials - Property of IBM IPS Product Modelling Guide 17