esb_deploy - Progress Sonic ESB Deployment Guide 8.5 - Product ...

More documents

Recommendations

Info

Chapter 1: Introduction Developing on Sonic Workbenches The Sonic Workbench development environment decouples developers from the deployment architecture so that they can focus on the business application’s functionality. A Sonic Workbench is a domain where developers upload development artifacts without having to maintain configuration objects. Generic components relieve the developer from managing the configuration objects that host and run the services and processes created. Source Control Repository 1. Update View 2. Checkouts 4. Checkins As illustrated, the development flow is: Sonic Workbench Development Licenses Eclipse Workspace - Projects - Source files 1. A developer on a Sonic Workbench connected to a source control repository loads or updates the latest version or view of projects in their current work branch as specified by the release manager. 2. The developer checks out files that will be changed. 3. Build, Upload, Run & Debug Workbench Directory Service - dev endpoints - dev containers - custom classes 3. After making changes and building projects in the workspace, and uploading them to the Workbench’s domain creates instances that simulate deployment and binds the ESB artifacts to default endpoints, connections, and containers. Sonic Workbench provides run, test, and debug facilities to unit test the changed application. 4. When complete, the developer checks in the checked out files of the projects to the source control repository to resolve conflicts with other developers’ changes, to back up source files, and to transfer and update the project on a different Workbench. While deployment can occur on a developer’s Workbench, typically one person is the release manager. Note Each Workbench container caches a new copy of a file for each invocation of the service if a required file is located in the sonicfs:///workspace directory. This is by design, because the workspace directory is only intended for development. To stop the container from caching a new copy of a file for each invocation of the service, move the file outside of the workspace directory within the Directory Service storage, for example: sonicfs:///MyFolder/ 24 Progress Sonic ESB Deployment Guide 8.5
Deploying to Developer Integration Testing Stages of Deployment When all the developers’ check in their changes in and resolve any checkin conflicts, the release manager can initiate the deployment process, as shown in the following illustration. Source Control Repository Developer Integration Testing Deployment Licenses Clean DS image Selected technique for building and mapping ESB Artifacts Scripted build of source files into JARs Deployment Domain Manager Import ESB Artifacts Clean Target by Refreshing from Clean DS Directory Service The release manager might use one of the Sonic Workbench techniques for deployment (described in Chapter 2, “Exporting ESB Artifacts for Deployment,”) to access and build the projects in the branch that are moving to deployment. Two build functions occur, one to package and prepare the ESB artifacts to be tested, and the other to compile and package the classes used by the services and processes. When both succeed, the output is staged for import into the test environment. You should perform integration testing on a simple, uncomplicated domain, referred to in this document as a ‘clean Directory Service’ or clean DS. (How to set up and refresh a clean DS is discussed in “Using the Build Strategy on a Static Target Domain” on page 87.) After refreshing the integration test environment with a clean DS, you should delete any JARs imported in prior test runs. While the integration test environment is similar to Sonic Workbench’s underlying domain, you must modify the naming patterns and paths in the Workbench environment for deployment domains. The Sonic mapping tools (discussed in Chapter 3, “Mapping Progress Sonic ESB Deployment Guide 8.5 25 Import JARs Clean Target by Deleting Compiled JARs
Page 1 and 2: ® ® PROGRESS® SONIC® Sonic ESB
Page 3 and 4: the redistribution, if any, must in
Page 5 and 6: the relevant code modules. All Righ
Page 7 and 8: OF USE, DATA, OR PROFITS; OR BUSINE
Page 9: products derived from this software
Page 12 and 13: Contents Using the Deployment Expor
Page 14 and 15: Contents Chapter 7: Updating a Revi
Page 16 and 17: Preface About This Guide This guide
Page 18 and 19: Preface Progress Sonic Documentatio
Page 20 and 21: Preface 20 Progress Sonic ESB Deplo
Page 22 and 23: Chapter 1: Introduction Roles in Re
Page 26 and 27: Chapter 1: Introduction ESB Artifac
Page 28 and 29: Chapter 1: Introduction Different P
Page 30 and 31: Chapter 1: Introduction 30 Progress
Page 32 and 33: Chapter 2: Exporting ESB Artifacts
Page 60 and 61: Chapter 3: Mapping ESB Artifacts to
Page 74 and 75:
Chapter 3: Mapping ESB Artifacts to
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Chapter 4: Analyzing ESB Artifacts
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 106 and 107:
Chapter 5: Importing Deployment Art
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Chapter 6: Adapting Imported Servic
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Chapter 7: Updating a Revised Deplo
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
Chapter 8: Distributed Deployment a
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 154 and 155:
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
Index ESBWS WSDL files external to
Page 164:
Index 164 Progress Sonic ESB Deploy
show all

esb_deploy - Progress Sonic ESB Deployment Guide 8.5 - Product ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?