Managing composite application lifecycles

A typical software development lifecycle is comprised of multiple phases such as requirement gathering, analysis, design, development, testing, and promotion. Within the Oracle SOA development lifecycle, deployment and runtime management tend to introduce certain complexities. The following screenshot shows a simple HelloWorld SOA composite application in Oracle JDeveloper 12c that is implemented using a BPEL component:

Figure 1.2: Developing a HelloWorld SOA application using BPEL in Oracle JDeveloper

As a 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 when the composite is promoted to higher environments such as test and production.

For example, your developers may have designed a SOA composite that processes payments by calling PayPal's API service. Naturally, they would be referencing PayPal's sandbox server (For example, https://api.sandbox.paypal.com/2.0) during development. What happens when this same SOA composite is deployed to production? How are these references automatically updated to utilize PayPal's production servers? How about timeout settings and other properties that differ from environment to environment?

Oracle SOA Suite 12c offers comprehensive lifecycle management features starting from development all through packaging, deployment, and post-deployment management:

• The ability to deploy multiple versions of a given composite application and specify a default version from either Oracle 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 Service Archive (SAR).

  Note

  A SAR is a deployment unit that describes the SOA composite application. The SAR packages service components, such as BPEL/BPMN processes, business rules, human tasks, and Mediator routing services in a single deployable application.

• Built-in capabilities to connect with versioning systems to version control your composite artifacts.
• 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, many runtime properties can be modified including:
  • Schema references and imports
  • Service endpoints in composite.xml
  • Properties of referenced components such as adapters
  • Attaching and detaching security policies to composite endpoints

Figure 1.3 illustrates how a developer IDE such as JDeveloper (top-left corner) is used to build and compile SOA composites that can eventually be packed and deployed as SAR files to the Oracle SOA Suite 12c infrastructure for execution. The composites along with their instances can be instantaneously managed and monitored from Oracle Enterprise Manager Fusion Middleware Control (bottom-left corner).

Figure 1.3: A typical Oracle SOA Suite 12c application lifecycle

Note

Oracle Service Bus development is now integrated in Oracle JDeveloper 12c and no longer requires the separately installed Eclipse IDE for OSB development.