In our last post, we have seen how to install the Oracle SOA Suite. Before we get in to the development of the Oracle SOA Suite, its mandatory to understand the few components, one of its Service Component Architecture.
What is Application ?
An Application is as a set of software components working together. All of these components might be built using the same technology, or they might use different technologies. They might run inside the same operating system process, in different processes on the same machine, or across two or more connected machines.
However an application is organized, two things are required: a way to create components and a mechanism for describing how those components work together.
What is SCA ?
Service Component Architecture (SCA) defines a general approach to doing both of these things. Now owned by OASIS, SCA was originally created by a group of vendors, including BEA, IBM, Oracle, SAP, and others. The SCA specifications define how to create components and how to combine those components into complete applications.
The components in an SCA application might be built with Java or other languages using SCA-defined programming models, or they might be built using other technologies, such as the Business Process Execution Language (BPEL) or the Spring Framework. Whatever component technology is used, SCA defines a common assembly mechanism to specify how those components are combined into applications.
Every SCA application is built from one or more components. In a simple application, the components could be Java classes running in a single process, and their interactions might rely on Java interfaces exposed by those classes.
In a slightly more complex case, the Java classes in this application might be running on different machines, relying on some communication mechanism to interact with one another. In a still more complex case, the application might contain a few components implemented as Java classes, others written in C++, and still others defined using BPEL, all spread across a group of machines.
In all of these situations, the same fundamental issues exist: There must be a way to define components and to describe how they interact. And in an increasingly service-oriented world, those interactions should be modeled as services, cleanly separating the implementation technology from the function that’s provided.
To do this, SCA defines a generalized notion of a component. It also specifies how those components can be combined into larger structures called composites. The below shows how a simple composite built from three SCA components might look.
A composite is a logical construct: Its components can run in a single process on a single computer or be distributed across multiple processes on multiple computers. A complete application might be constructed from just one composite, as in the example shown here, or it could combine several different composites. The components making up each composite might all use the same technology, or they might be built using different technologies—either option is possible.
An SCA application can be accessed by software from the non-SCA world, such as a Java Server Page (JSP), a Web services client, or anything else. Components in an SCA application can also access data, just like any other application. One option for this is to use Service Data Objects (SDO), perhaps in concert with a standard Java data access technology such as JDBC or Java EE 5’s Java Persistence API (JPA). An SCA component can also use JDBC, JPA, or something else directly—the SCA specifications don’t mandate any particular choice.
An SCA composite is typically described in an associated configuration file, the name of which ends in .composite. This file uses an XML-based format called the Service Component Definition Language (SCDL, commonly pronounced “skiddle”) to describe the components this composite contains and specify how they relate to one another. For the three-component composite shown above, the basic structure of its SCDL configuration would look like this:
An SCA component is a simple thing. Whatever technology is used to create it, every component has the same fundamental parts, as shown below.
Each component typically implements some business logic, exposed as one or more services. A service, represented by a green chevron in the figure, provides some number of operations that can be accessed by the component’s client. How services are described depends on the technology that’s used to implement the component. A Java component, for example, might describe its services using ordinary Java interfaces, while a component implemented in BPEL would likely describe its services using the Web Services Description Language (WSDL).
Along with providing services to its own clients, a component might also rely on services provided by other components in its domain or by software outside its domain. To describe this, a component can indicate the services it relies on using references. Shown as a purple chevron in the figure above, each reference defines an interface containing operations that this component needs to invoke.
Services and references let a component communicate with other software. By design, however, they say nothing about how that communication happens. Specifying this is the job of bindings.
In our next post, we will understand what is BPEL. Stay tuned