Stopping and Starting SOA Suite Components
Recently Oracle put out a preview of the SOA Suite (Overview: http://otn.oracle.com/soa, Download: http://www.oracle.com/technology/software/products/ias/soapreview.html).
The reason this packaging was created is, while all of the components in the SOA Suite in general are available as stand-alone products for those starting tactical projects, what seemed to happen in real life was most implementation projects almost inevitably required each of the components during some point in their lifecycle. Pre-integrating them and packaging them together eliminates the need to integrate your enabling technologies and lets you focus on creating business value while at the same time letting you only use exactly what you need.
To give a sense of this here are some simple use cases. A customer might start with a project to automate a simple business process with BPEL (Oracle BPEL Process Manager) to prove SOA is real and then realize they want to separate out the business rules into a rules engine (Oracle Business Rules) because their business policies frequently change. Or, after successfully automating a process, they want to secure key services in a managable fashion with WS-Security (Oracle Web Services Manager). Or, rather than using BPEL to do both the connectivity and process logic, they want a more formal intermediation layer connecting and routing to their backend systems (Oracle ESB).
To facilitate all approaches - use only one component (buy stand-alone components), grow organically as your project matures (add to your stand-alone buy) or start with all the pieces together, Oracle SOA Suite was created. The pieces in the SOA Suite are the Oracle BPEL Process Manager, Oracle Web Services Manager, Oracle Business Rules, Oracle Enterprise Service Bus and Oracle BAM. This can be run on Oracle Application Server or other application servers and comes along with the JDeveloper IDE. Optional to this is the Oracle Service Registry. This offering is complemented by those serious about business process management by the Oracle Business Process Analysis Suite.
A long opening story to get to the subject of this post which is some managability Oracle has added around the components of SOA Suite when installed altogether. The end result is once you install the SOA Suite - a one click install for developers as this picture shows (more complex deployment topologies available in the advanced install option):
you will find all 5 major components of the SOA Suite (Rules, BPEL PM, WSM and ESB) installed.
As you might imagine given it is Oracle, each of these products are simply a set of J2EE applications running the the application server you have decided to deploy them on. Because in the one click install developer mode the SOA Suite is deployed on a single instance of the application server, that can end up being a reasonably large number of J2EE applications (each component is typically 2 or more J2EE applications) with not much to distinguish them should you decide to start or stop one or more of the components.
To help make this about as trivial as possible, what the Application Server Control console team did was categorize the sub-applications of each SOA component so that when the user goes to do an application server administrative operation on, for example, the BPEL PM, they see a category called BPEL PM. And when they go to do an administrative operation on the rules engine, they see a category called Rules. And likewise for Web Services Manager and ESB. The picture below gives a sense of this:
As you can see it is pretty trivial to select one of the components and start, stop and even undeploy it should you not need it in a particular development or deployment environment. If you drill down a little further, you will see the underlying applications of each SOA component. If you are an administrator of those components these will be meaningful (e.g. in Web services manager the subcomponents are the core runtime, the management console, the policy manager and the gateway); if not, you likely don't care.
Clearly, this level of detail is typically important to your application server administrator or a technical developer rather than the analyst building rules, processes, policies or bus infrastructure. As you might imagine, each of these components have a more context aware console that you can get to from the SOA Suite lauch console (below):
so you can edit business rules, service policies, business processes and service bus characteristics.
This system view from the application server perspective is a taste of some of the integration work that was done to make working with these components as a unit, particularly during a development cycle, very clean and easy in the 10.1.3.1 release.
