Developers can create SOA services by using a number of different technologies. Oracle SOA Suite 12c provides us with the ability to run services that are developed as SOA composite applications (or simply SOA composites) and OSB services. Though both types of services are packaged in single deployable JAR files, they are very dissimilar technologies that are developed differently and are executed and managed in completely separate runtimes. However, the beauty of Fusion Middleware Control 12c is that the administrator is given a single consolidated view of runtime instances of these distinct services. Developers can harness the advantages of each of these separate technologies while the administrator can manage them collectively.
Composites can contain any number of service components, which include BPEL or BPMN processes, mediator services, human tasks and workflows, and business rules. They do not include OSB services, which are separately developed and deployed components. Together, SOA composite applications and OSB services can coexist and include logic that forms the foundation of SOA-based integrations.
Though the design and development of composites and services are not the ultimate responsibility of the Oracle SOA Suite 12c administrator, the deployment, monitoring, and management of their lifecycle are.
In this chapter, we will discuss the concepts that enable you to manage both SOA composites in the first half of the chapter, followed by OSB services in the latter half. The following topics are covered in this chapter:
- Managing SOA composite lifecycles
- Structuring SOA composites with partitions
- Managing OSB service lifecycles
Every SOA composite has a state, mode, and associated metadata. The state can be up (started) or down (shut down). The mode can either be active or retired. Metadata is stored in the Metadata Store (MDS), which is generally a database-backed repository used by Oracle SOA Suite 12c, and consists of information that includes the default revision number, last modification date, deployment and redeployment times, and instance runtime information. Before walking through how to manage the state and mode of SOA composites, we will begin by describing composite revisions.
When a
HelloWorld composite is deployed to on the server, a revision is required during the deployment. Thus, a service's WSDL can be accessed via a URL similar to the following, clearly indicating a revision of 1.0 after the composite name:
http://soahost1:8001/soa-infra/services/default/HelloWorld!1.0/HelloWorld.wsdl
However, there may be a case where a new version of the composite needs to be deployed and that this version has a different implementation from the existing one. Overwriting the existing version may not be the right option as it would break all the client applications that are already consuming the service. Thus, it makes sense to deploy the new composite using a different revision, such as revision 2.0, making both versions available simultaneously. The composite would, therefore, be accessible at a different URL, http://soahost1:8001/soa-infra/services/default/HelloWorld!2.0/HelloWorld.wsdl.
Now, the old and new services are both available and accessible. Clients accessing revision 1.0 of the SOA composite may transition to revision 2.0 at their own pace.
If multiple revisions of the same service are deployed, one of them must be specified as the default revision. This can be specified during the deployment time or can be changed at runtime by the administrator. The default revision would thus be accessed at a revision-independent URL, http://soahost1:8001/soa-infra/services/default/HelloWorld/HelloWorld.wsdl.
Typically, client applications will access the default revision. Revisions are advantageous in environments where maintaining old and new versions of the same SOA composite is required, particularly if it involves breaking changes or supporting clients that require backward portability.
As shown in the following screenshot, default revisions are indicated by a green dot in the list of SOA composites for a given partition:
Figure 4.1: Green dots are used to identify default revisions of a SOA composite
Partitions will be explained in detail later in this chapter.
If a SOA composite is not the default revision, the Set As Default... button will appear in the SOA composite page, as shown in the following screenshot. By clicking on this button, it is possible at this point to set the revision of this composite as the default revision if you want to.
Figure 4.2: The Set As Default button appears for non-default SOA composite revisions
If a default SOA composite application is undeployed, the default revision is automatically changed to the last deployed revision.
SOA composites are automatically started up when they are deployed. If a composite is shut down, all requests to the composite are rejected, including callbacks. New requests are not served and new instances are not created. However, all running instances are allowed to complete.
Though starting up and shutting down SOA composites via the console is extremely easy. If you require to start up or shut down multiple SOA composites, two approaches are available, which are discussed in detail later in this chapter:
- SOA composites deployed on the same partition can all be started up or all be shut down with a single operation
- Ant or WLST can be used to automate the startup and shutdown of SOA composites
To start up a single SOA composite from the console, proceed with the following steps:
- Log in to Fusion Middleware Control at
http://<adminhost>:7001/em. - On the navigator, expand SOA | soa-infra.
- Expand the partition (for example, default) and click on the SOA composite name and the revision (for example, HelloWorld [1.0]).
- Click on the Start Up... button, which will only appear if the SOA composite is already shut down, as shown in the following screenshot:
Figure 4.3: Starting up a SOA composite from Fusion Middleware Control
To shut down a single SOA composite from the console, proceed with the following steps:
- On the navigator, expand SOA | soa-infra.
- Expand the partition (for example, default), choose from the deployed SOA composites, and click on the composite name and the revision (for example, HelloWorld [1.0]).
- Click on the Shut Down... button, which will only appear if the SOA composite is already started up, as shown in the following screenshot:
Figure 4.4: Shutting down a SOA composite from Fusion Middleware Control
SOA composites have two modes—active and retired. These are often confused with SOA composite states, which can be up (started) and down (shut down).
SOA composites are automatically activated when they are deployed (in fact, they are also started up as well, so active and started SOA composites are really identical in nature). However, when a SOA composite is retired, new instances cannot be created. Existing instances, however, continue to completion. This includes instances that receive callbacks. The ability to receive callbacks and time-based waits is the primary difference between a retired SOA composite and a SOA composite that has been shut down.
To retire a single SOA composite from the console, perform the following steps:
- On the navigator, expand SOA | soa-infra.
- Expand the partition (for example, default) and click on the SOA composite name (for example, HelloWorld).
- Click on the Retire button, which will only appear if the SOA composite is already active.
To activate a single SOA composite from the console, go through the following steps:
- On the navigator, expand SOA | soa-infra.
- Expand the partition (for example, default) and click on the SOA composite name (for example, HelloWorld).
- Click on the Activate button, which will only appear if the SOA composite is already retired.
Every time a SOA composite application is invoked, a new instance of the composite is created. Every instance has a unique ID and its details can be retrieved from Fusion Middleware Control. All the instance ID types are explained in detail in Chapter 6, Monitoring Oracle SOA Suite 12c. Oracle SOA Suite 12c maintains an audit history of the instance that is saved in what is referred to as the dehydration store. Too much instance-related data requires additional storage, but more importantly, it impacts the performance of the console. Administrators are expected to delete completed instances periodically to control growth. We will discuss the management of instance data in Chapter 8, Managing the Database, but it may be worth briefly describing how to delete instances, thereby purging all data related to it, manually from Fusion Middleware Control as part of SOA composite management activities. Deleting instances is quite easy, as demonstrated in the following steps:
- On the navigator, expand SOA | soa-infra.
- Expand the partition (for example, default) and click on the SOA composite name (for example, HelloWorld).
- Click on the Instances tab.
- At this point, you can delete instances in one of the following two ways:
- Highlight the list of instances (press the Ctrl key and click on each SOA composite one by one) and click on the Delete Selected button.
- Click on the Delete With Options button. From here, you can delete instances older than a specific time or delete all instances within a time frame that have a certain state.
You can also bulk delete/purge SOA composite instances from the underlying database dehydration store through the use of SQL scripts. Again, this will be covered in more detail in Chapter 8, Managing the Database.