The typical software development lifecycle is comprised of multiple phases such as requirements, analysis, design, development, testing, and promotion. Within the Oracle SOA development lifecycle, deployment and runtime management tend to introduce certain complexities. As an SOA composite is being developed, it may reference an endpoint (effectively a fully qualified URL) on a development server. This reference will need to change as the composite is promoted to higher up environments such as test and production. For example, your developers may have developed code that processes payments against PayPal. Naturally, they would be pointing to the PayPal sandbox server at https://api.sandbox.paypal.com/2.0/ during development. What happens when this code is deployed to production? How are these references automatically updated to reference the PayPal production servers?
Oracle SOA Suite 11g offers comprehensive lifecycle management features starting from development, packaging, deployment, and post-deployment:
It offers the ability to deploy multiple versions of a given composite application and specify a default version from either JDeveloper, Oracle Enterprise Manager Fusion Middleware Control, or ant/WLST-based scripts.
Oracle SOA Suite tooling allows you to make/compile your composite applications and export a deployable SOA archive (SAR).
It has built-in capabilities to connect with versioning systems to version control your composite artifacts.
It offers configuration plans that are composite-wide to customize environment specific values, such as a web service URL that is different in the dev/test environment than in the actual production environment. With configuration plans, here are a few things you can modify:
WSDL and schema includes/imports and endpoints
Endpoints and imports in
Web Service Policies can be attached/detached to either composite endpoints
The following screenshot illustrates how a developer IDE such as JDeveloper (top-left) is used to build and compile SOA composites that can eventually be packed and deployed as a JAR file to the Oracle SOA Suite 11g infrastructure for execution. The composites along with their instances can be instantaneously managed and monitored from the Oracle Enterprise Manager Fusion Middleware Control console (bottom-left).
For managing your complete end-to-end lifecycle, you can also consider an enterprise repository solution such as the Oracle Enterprise Repository (OER), which integrates with JDeveloper and related tools. It provides a system of record for all SOA asset information, automatically detects usage of these artifacts, tracks compliance, as well as many other governance capabilities and features. OER focuses on the SOA governance aspect of the lifecycle, but is not part of Oracle SOA Suite 11g or its infrastructure. Additional information on Oracle Enterprise Repository can be found at http://www.oracle.com/technology/products/soa/repository/index.html.
One of the key principles of SOA is that systems are no longer built to last, but rather built to change. As an administrator of the Oracle SOA Suite 11g platform, you should expect more rapid and continuous changes by development teams in response to ever changing business requirements.
Being able to adapt to the changing business requirements is not only important once a system has gone live, but it is also equally important during development. This would mean expecting a greater number of builds, packaging, and deployments. The process of deployment involves piecing together multiple relevant components, compiling them, deploying the final package into a target environment, and finally running a series of tests to validate the build. This would have to be repeated in each environment until promoted to production. This process is manual, resource intensive, and highly error prone.
Automating application deployments is a practice that is widely adopted within the software industry to alleviate manual, resource intensive, and highly error prone processes.
Oracle SOA Suite 11g is unique in that it provides several ant scripts to assist in the compilation, build, and deployment of composites. These scripts can be executed manually, automated through custom scripts, or used from a continuous integration tool such as Hudson. As you read on, Chapter 2, Management of SOA Composite Applications of this book will cover details of how you can automate your composite build and deployment with ant scripts.
Think of a script which runs at regular time intervals or at the click of a button every time an administrator needs to deploy an application to the platform. By having automated build reports detailing the execution and/or issues of compilation and deployment, your time is freed up considerably to focus on other administrative activities. The following screenshot shows the continuous integration with the Oracle SOA Suite 11g platform:
The preceding screenshot shows the Hudson console for a build job and the output of an automated build, which is followed by an automated unit test. By leveraging continuous integration tools such as Hudson, the deployment and validation efforts required by the Oracle SOA Suite administrator are greatly reduced.