Business Rules in Oracle SOA Suite 11g

At runtime, there may be many potential paths through a BPEL process, controlled by conditional statements such as switch or while activities. Typically, the business rules that govern which path to take at any given point are written as XPath expressions embedded within the appropriate activity.

Although this is an acceptable approach, we often find that while the process itself may be relatively static, the business rules embedded within the activities may change on a more frequent basis. This will require us to update the BPEL process and redeploy it, even though the process flow itself hasn't changed.

In addition, by embedding the rule directly within the decision point, we often end up having to reimplement the same rule every time it is used, either within the same process or across multiple processes. Apart from being inefficient, this can lead to inconsistent implementations of the rules, as well as requiring us to update the rules in multiple places every time it changes.

The Oracle Business Rules engine that comes as part of the SOA Suite provides a declarative mechanism for defining business rules externally to our application. This not only ensures that each rule is used in a consistent fashion, but in addition, it makes it simpler and quicker to modify. We only have to modify a rule once and can do this with almost immediate effect, thus increasing the agility of our solution.

For those of you familiar with 10gR3, you will notice that JDeveloper comes with a new rules editor which is a lot more intuitive and simpler to use than the old browser-based editor. In addition, 11gR1 introduces decision tables, which provide a spreadsheet-like format for defining rules. While still very much a developer-oriented tool, these improvements make the tool a lot friendlier for business analysts, allowing them to better understand the rules that have been written as well as make simple changes.

In this post, we shall look at the new rules editor and how we can use it to define a decisions service to automate the approval of leave requests. Then, once we've done this, we'll see how to invoke the rule from the leave approval BPEL process. We will first implement these as a standard set of rules and then examine how we can simplify these rules by using a decision table.

Business rule concepts

Before we implement our first rule, let's briefly introduce the key components which make up a business rule. These are:

• Facts: Represent the data or business objects that rules are applied to.
• Rules: A rule consists of two parts, namely, an IF part that consists of one or more tests to be applied to a fact(s), and a THEN part that lists the actions to be carried out, should the test evaluate to true.
• Rule Set: As the name implies, it is just a set of one or more related rules that are designed to work together.
• Dictionary: A dictionary is the container of all components that make up a business rule. It holds all the Facts, Rule Sets, and Rules for a business rule.

In addition, a dictionary may also contain decision tables, functions, variables, and constraints. We will introduce these in more detail later in this article.

To execute a business rule, you assert (submit) one or more facts to the rules engine. It will apply the rules to the facts, that is, each fact will be tested against the IF part of the rule, and if it evaluates to true, then it will perform the specified actions for that fact. This may result in the creation of new facts or the modification of existing facts (which may result in further rule evaluation).

XML facts

The rule engine supports four types of facts: Java Facts, XML Facts, RL Facts, and ADF Facts. The type of fact that you want to use typically depends on the context in which you will be using the rules engine.

For example, if you are calling the rule engine from Java, then you would work with Java Facts as this provides a more integrated way of combining the two components. As we are using the rule engine within a composite, it makes sense to use XML facts. The rule editor uses XML schemas to generate JAXB 2.0 classes, which are then imported to implement the corresponding XML facts. Using JAXB, particularly when used in conjunction with BPEL, places a number of constraints on how we define our XML schemas, including:

• Within BPEL, you can only define variables based on globally defined elements. Thus all input and output facts passed to the decision service must be defined as global elements within our XML schemas.
• When defining the input and output facts for any complexType (for example, tLeaveRequest), there can only be one global element of that type (for example, leaveRequest).
• The element naming convention for JAXB means that elements or types with underscores in their names can cause compilation errors.

Decision services

To invoke a business rule within a composite, we need to go through a number of steps. First, we must create a session with the rules engine, then we can assert one or more facts, before executing the ruleset and finally we can retrieve the results.

We do this via a decision service (or function). This is essentially a web-service wrapper around a rules dictionary, which takes care of managing the session with the rules engine as well as governing which ruleset we wish to apply.

The wrapper allows a composite to assert one or more facts, execute a ruleset(s) against the asserted facts, retrieve the results, and then reset the session. This can be done within a single invocation of an operation or over multiple operations.

Leave approval business rule

For our first rule, we are going to build on Adding in Human Workflow. It's a simple process requiring every leave request to go to an individual's manager for approval. However, what we would like is a rule that automatically approves a request as long as it meets certain company guidelines.

To begin with, we will write a simple rule to automatically approve a leave request that is of the type Vacation and only for one day's duration. This is a pretty trivial example, but once we've done this, we will look at how to extend this rule to handle more complex examples.

Creating a decision service

Within JDeveloper, open up your LeaveApproval application. Open up the composite.xml file for the application and then from the Component Palette, drag-and-drop a Business Rule onto the composite, as shown in the following screenshot:

This will launch the Create Business Rules dialog, as shown in the following screenshot:

The first step is to give our dictionary a name, such as LeaveApprovalRules, and a corresponding <>bPackage name.

In addition, we need to specify the Input and Output facts that we will pass to our decision service. For our purpose, we will pass in a single leave request. The rule engine will then apply the rules that we define and update the status of the leave request to either Approved or Manual (to indicate the request needs to be manually approved).

So we need to define a single input fact and output fact, both of type leaveRequest. To do this, click on the plus symbol (marked in the preceding screenshot), and select Input.

This will bring up the standard Type Chooser window; browse the LeaveRequest.xsd and select leaveRequest. Do the same again to specify an Output fact.

Next, click the Advanced tab. Here we can see that JDeveloper has given the default name LeaveApprovalRules_DecisionService_1 to our decision service. Give it a more meaningful name such as LeaveApprovalDecisonService.

Now click OK. JDeveloper will inform you that it is creating the business rule dictionary for LeaveApprovalRules. Once completed, your composite should now look as shown in the following screenshot:

We are now ready to implement our business rules. Double-click on the LeaveApprovalRules component, and this will launch the rules editor, which is shown in the next screenshot.

Implementing our business rules

The rules editor allows you to view/edit the various components which make up your business rules. To select a particular component, such as Facts, Functions, Globals, and so on, just click on the corresponding tab down the left-hand side.

You will see that, by default, JDeveloper has created a skeleton rules dictionary-based on the inputs we just specified.

Select the Facts tab (as shown in the preceding screenshot). You will see that it contains two XML facts (TLeaveRequest and com.packtpub.schemas.leaverequest.ObjectFactory), which are based on the inputs/outputs we defined earlier as well as a set of standard Java facts, which are automatically included within a rules dictionary.

Next, select the Decision Functions tab. You will see that it contains a single decision function LeaveApprovalDecisonService (that is, the name we specified on the Advanced tab when creating our business rule).

We will introduce some of the other tabs later in this article, but for the time being, we will start by defining our first rule. By default, the rules editor will have created a single ruleset with the name Ruleset_1. Click on the Ruleset_1 tab to open up the ruleset within the editor.

Expand the ruleset to show its details by clicking on the plus symbol (circled in the following screenshot). We can see that the ruleset has three properties: Name, Description, and Effective Date.

The Effective Date enables us to specify a period in time for which the ruleset will be applied, allowing you to define multiple versions of the same ruleset. For example, a current ruleset and a future version that we wish to come into effect at a defined time in the future.

Rename the ruleset to something more meaningful, for example, Employee Leave Approval Policy; add a description if you want and ensure that Effective Date is set to Always Valid.

Adding a rule to our ruleset

To add a rule, click the green plus symbol on the top-right-hand corner, and select Create Rule, as shown in the following screenshot (alternatively click on the Create Rule button, circled in the following screenshot).

This will add a rule to our ruleset with the default name Rule_1, as shown in the following screenshot. Here, we can see that a rule consists of two parts, an IF part, which consists of one or more tests to be applied to a fact or facts, and a THEN part, which specifies the actions to be carried out, should the test evaluate to true.

To give the rule a more meaningful name, simply click on the name and enter a new name (for example, One Day Vacation). By clicking on the element, you can also add a description for the rule.

Creating the IF clause

For our leave approval rule, we need to define two tests, one to check that the request is only for a day in duration, which we can do by checking that the start date equals the end date, and the second to check that the request is of type Vacation.

To define the first test, click on <insert test>. This will add the line = = under the IF statement where we can define the test condition.

Click on the first . This will display a drop-down list listing the valid facts and their attributes that we can test. From here, we can select the value to be tested, for example, TLeaveRequest.startDate in our case.

Next from the operator drop-down list, select the test to be applied to the first operand (== in our case). We can either choose to compare it to a specified value or a second Operand. For our purpose, we want to check that the request.startDate equals the request.endDate, so click on the operand and select this from the drop-down list.

To create our second test, we follow pretty much the same process. This time we want to test that the operand leaveRequest.leaveType is equal to the value Vacation, so select the right-hand operator and type this in directly:

Note, the rule editor has automatically inserted an and clause between our two tests. If you click on this, you have the option of changing this to an or clause.

Creating the Then clause

Now that we have defined our test, we need to define the action to take if the test evaluates to true. Click on . This will display a drop-down list where you need to specify the Action Type you wish to carry out.

The rule editor allows us to choose from the following action types:

• assert new: We use this to create and assert a new fact, for example, a new LeaveRequest. Once asserted, the new fact will be evaluated by the rules engine against the ruleset.
• modify: We can use this to either assign a value to a variable or a fact attribute; in our case we want to assign a status of Approved to the requestStatus property.
• retract: This enables you to retract any of the facts matched in the pattern (for example, TLeaveRequest) so that it will no longer be evaluated as part of the ruleset.
• call: This allows you to call a function to perform one or more actions.

The actions assert new and retract are important when we are dealing with rulesets that deal with multiple interdependent facts, as this allows us to control which facts are being evaluated by the rule engine at any particular time.

For our purposes, we want to update the status of our leave, so select modify. Our rule should now look as shown in the following screenshot:

The next step is to specify the fact to be modified. Click on the <target> element and you will be presented with a list of facts that are within scope. In our case, this will only be the TLeaveRequest that has just been matched by the IF clause, so select this. Our rule will now appear, as shown in the following screenshot:

We now need to specify the properties we wish to modify, click on <add property> to open the Properties dialog. This will display a list of all the facts properties, allowing us to modify them as appropriate.

Select the Value cell for requestStatus. From here, you can directly enter a value, select a value from the drop-down list, or launch the expression builder. For our purposes, just enter the string Approved, as shown in the following screenshot, and then click Close.

We don't need to specify values for any of the other properties, as the rules engine will only update those properties where a new value has been specified.

This completes the definition of our first rule. The next step is to wire it into our BPEL process.

Event Delivery Network with Oracle SOA Suite 11g

Creating truly decoupled composite SOA applications requires a complete separation of the service consumer and the service provider.This is typically achieved through the use of asynchronous messaging.In an asynchronous messaging pattern, applications can perform in a"fire and forget" mode. This removes the need of an application to know details of the application on the other side. Additionally, it also improves resource utilization as applications are not holding onto resources until the interaction is complete. On the other hand, this introduces complexities of creating and managing message queues and topics. It requires that both the publisher of the message and the consumer use the same messaging technology. Each messaging system also has its own constraints on the types of programming languages and environments that can use the service.
In a service-oriented world, this tight coupling to the implementation of the underlying messaging system is at odds with the fundamental requirement of implementation independence. What's needed is a level of abstraction that allows applications to generate an event using business terms and associate a business object in an implementation‑independent form.
Oracle SOA Suite 11g addresses this with the introduction of anew feature in the form of the Event Delivery Network.

Introducing events

The Event Delivery Network (EDN) in Oracle SOA Suite 11g provides a declarative way to use a publish/subscribe model to generate and consume business events without worrying about the underlying message infrastructure.
Developers only need to produce or consume events without having to deal with any particular messaging API like JMS, AQ, and MQ, and so on. Consuming an event means expressing an interest in the occurrence of a specific situation,while producing an event means advertising this occurrence.
Using the same concepts that are used in Web Service Definition Language (WSDL), EDN uses an XML-based Event Definition Language, which allows you to define the event and its associated,strongly typed data. This definition is then registered with the SOA Infrastructure and is available to all composites to publish or subscribe.

This allows for a fully-declarative, business-oriented, rather than developer-oriented approach for using events in a SOA application.

Another feature of EDN is the ability to publish and subscribe to these events from a variety of programming environments such as Java, PL/SQL, SOA Composites, and ADF-BC applications.

With EDN, Oracle has fostered the concept of events in the context of SCA, and this has given birth to an additional SCA specification:the "Assembly Model Specification Extensions for Event Processing and Pub/Sub". Since EDN in Oracle SOA Suite 11g predates the specification, you will find differences in the details, but the concepts are the same and EDN will eventually be aligned with the standard that emerges from the specification.

Creating and managing event definitions

Events are defined using an Event Definition Language (EDL),an XML schema used to build business event definitions. An EDL consists of the following:

• A global name.
• Custom headers: These can be used for content-based routing without having to parse the XML payload and apply XPath queries to get at the value to be used for the routing decisions. For instance, one can put the purchase order type in the custom header. This easily accessible custom header could then be used to efficiently decide how to process delivered events.
• Payload definition: Typically this is an XML schema for the business data that needs to accompany the event. For example, a "NewPO"event's payload definition will be a schema for a purchase order.

Event definitions can be created declaratively in JDeveloper in a couple of different ways depending on triggering conditions.
To publish events from a SOA composite, one would create new event definitions and register them with the SOA Infrastructure. It is this option that you will be able to try out later in this article during the hands-on exercise.

If you want to raise events on one or more database operations such as insertion of a new row or update of an existing one, you can use ADF-BC to define these events. ApplicationDevelopment Framework(ADF), a model-view-controller pattern based UI development framework for creating Rich Internet Applications (RIAs) and BusinessComponents(BC), an object-relational mapping tool, provide an easy way to define events. ADF-BC has built-in support for associating these events with database actions like insert, delete, and modify. For example, an event called "NewCustomerAdded" could be generated every time a new customer record is inserted into the database.

Registered events, their subscribers, and any faulted deliveries can all be tracked and monitored using the Oracle Enterprise Manager, in the same fashion that you would be managing and monitoring other aspects of your SOA infrastructure.

Consuming events from the Event Delivery Network

The first step to consume an event is to discover its definition. Event definitions can be stored locally in a composite or globally on the server—in either case, they can be discovered through the JDeveloper resource catalogue.

To subscribe to an event within an SOA composite application,you start by defining a Mediator component, selecting the event of interest from a list of registered events in the network.
To further refine a subscription, and narrow down the information you will receive, you can define an XPath-based filter on your subscriptions. For example, for an event named "NewPOCreated", you could either subscribe to all "NewPOCreated" events (default when no filter is defined) or only those where the order amount is more than a million dollars (by defining an XPath-based filter on the order amount field within the payload).

Use of Event Delivery Network (EDN) and POProcessing

Let's try out a simple EDN use case. We will extend a POProcessing example.

In order to follow the tutorial in this article you must have installed the product and learned how to use the WebLogic console to configure the JMS adapter and define queues and connection factories.

To illustrate the usage of events, you modify the existing POProcessing composite to accept new orders from two sources: the Web Service interface, which you have already implemented, and another application that will publish events to indicate new orders.

Modifying the composite to consume events

In this step, you modify the POProcessing composite to use EDN. You add a new mediator component called receivePO, which subscribes to an event called NewPO and sends the received PO to the routePO service.

Defining the event

1. Open the POProcessing application in JDeveloper and open composite.xml,and click on the Event Definition Creation icon: 
   
   
   
   
    
2. In the Event Definition Creationwindow, enter POEvents as the name of the event definition. Accept the namespace value generated.
   
   Event names are fully qualified names, which means the combination of a namespace and the event name together identify a unique event. For instance, the event called NewCustomerAdded with name space http://schemas.oracle.com/events/edl/POEvents is different than the event with the same name but under a different namespace, for example, event NewCustomerAdded with namespace http://schemas.oracle.com/event/edl/CRMEvents.
    
3. Add a new event by clicking on the + icon.
4. Select the PuchaseOrder element from the po.xsd file using the chooser.
5. Enter NewPO as the name of the event and click on OK to close the Add an Eventwindow.
   
   
6. Click on OK to complete the event definition.
7. Close the POEvents.edl panel.
8. Save all.
   You have just created a new event called POEvent. It is now available to this and other composites to subscribe to or publish. Whenever this event is delivered,it will also carry with it a document for the new purchase order.

Subscribing to the NewPO event 

1. Drag-and-drop a Mediator component on to the composite.
2. Name the mediator receiveNewPO.
3. Select Subscribe to Events for the Template.
4. Click on the + to add an event. Select the NewPO event from the Event Chooser window.
   
   
   
5. Click on OK to accept and create the mediator.
6. Save all.
7. Connect the receiveNewPO mediator to the routePO mediator:
   
   
   
   
8. Double-click on the receiveNewPO mediator and define a new transformation map. In the transformation-map, map the all the fields from the source to the target.
9. Close the mediator and save all.

  Deploying and Testing

1. Deploy the POProcessing composite tothe server.
2. Browse to the EM console at http://localhost:7001/em.
3. Right-click on folder soa-infra (soa_server1)under folder SOA:
   
   
   
   
4. Click on item Business Events.
5. You should see the Business Events management page with the NewPO event listed in the Events
   
   
   
   
6. Select the event and click on the Test…button to publish the event.
7. In the pop-up window, enter the following XML and click on Publish:
   
   
   
   
8. You should get a "The Event published successfully" message.
9. Click on soa-infra in the navigation panel on the left to get the soa-infra dashboard.
10. Click on the POProcessing composite to view new instances. You should see an instance created for processing the event you just published. Click on the instance ID to view the flowtrace.
    
    
    
    This was just one way of publishing an event and will typically be used as away to test the composite. In most cases, the events will be published from a number of sources—from a Mediator, from PL/SQL by calling the EDN_PUBLISH_EVENT stored function or from a Java class using the EDNAPI. An ADF-BC application can also publish events based on database insert, update, and delete operations.
    

Summary

You cannot really build comprehensive SOA applications without business events. Traditionally, this requirement has been fulfilled by message-oriented-middleware(MOM). However, MOM-based solutions don't necessarily fit very well within a service-oriented architecture. They are low-level technical solutions that provide no business semantics, whereas one of the main objectives of creating services is to provide business functions using semantics that are better understood by business analysts.

With EDN, Oracle SOA Suite 11g fills this gap by providing an event-handling solution that allows creation and use of events using business semantics, without the publisher or subscriber of the event ever having to worry about the mechanics of messaging.

As you have seen in this short lab, events are created in away that directly maps to actual business events, in this case creation of a new purchase order. The process of subscribing to this event was done declaratively without having to configure any messaging queues or topics.

How to convert Java Object to XML - JAXB Example

JAXB, stands for Java API for XML Binding or sometimes Java Architecture for XML Binding is a decade old technology to directly convert a Java object into XML document (marshaling) and back to XML file into Java object(unmarshalling).It uses combination of annotations and getters and setters to marshal Java object into XML.

What is JAXB?

JAXB actually defines the behavior of a standard set of tools and interfaces that automatically generate Java class files from XML schema, remember JAXB is actually a framework and/or an architecture, not an implementation.

The package java.xml.bind provides a runtime binding framework for clients to marshal, unmarshal and validate XML file in Java. BTW, JAXB is not the only option to parse XML in Java, you can always use SAX or DOM parser or JAXP API to convert XML to Java object and vice-versa.

How to use JAXB in Java

Let's see how you can use JAXB to create XML document from Java classes This is how JAXB works, let's say you have a Item object that needs to be converted to XML document, all you need to do is create a class Item with getters and annotate them appropriately as shown below :

Then you create a marshaller from JAXBContext class and ask it to convert an instance of class Item into XML, as shown below :

This will print following XML String into your console :

You can see how easy it is to convert a Java object to XML using JAXB. You don't need to worry about mapping types, opening tag, closing tag or doing anything related to XML by hand.

Important Points to Remember

1. Your Java class must have a no-argument constructor, otherwise JAXB will not able to marshal it. You will get following Exception :
   
   


2. Always remember to annotate your Java class with @XmlRootElement annotation, this would be your main tag in XML and each property using @XmlElement, they will appear as child element of the main tag.

Here is the complete Java program to convert a Java object to XML file using JAXB API :

Mediator in Oracle SOA Suite 11g

Mediator, as the name implies, mediates the message flow.

SOA is all about message flows between disparate systems, and mediators play an important role in this. It forms the communication layer between the services, thus providing a kind of service virtualization and decoupling between the interacting services.

It basically intercepts the message flow between the services and offer various capabilities as listed below

• Message Routing : This is the ability to channel a request to a particular service provider based on the message. You may define rules to select the target service among the available services based on the content in the message(static routing) or based on an external rules engine(dynamic routing)


• Message Validation: Messages can be checked against a schematron file for its validity. This helps in invoking the target services only with the right message(as each and every invocation in an enterprise is costly)


• Message Filtering : You may filter the messages based on its content


• Message Transformation : This is the ability to convert the structure and format of the incoming service request to the structure and format expected by the service provider.

Transformation is one of the key capabilities of the Mediators.

Mediators are also a way to change the interaction patterns, i.e. you can convert a message call from sync to async, a 2-way to a one-way, etc.

Mediators are a way to enable Event Delivery Architecture in your composite. They have the capability to publish an event as well as subscribe for an event.

However, mediators form the communication layer only within a composite. If the interactions go across composites, Enterprise Service Bus comes to the rescue. We'll discuss about ESB later.

Oracle ADF Architecture Overview

Oracle ADF (Application Development Framework) is an end-to-end Java EE framework from Oracle that built on top of the MVC based JSF (Java Server Faces) framework. It simplifies application development by providing out-of-the-box infrastructure services and providing a visual & declarative development experience. ADF is directly supported and enabled by Oracle JDeveloper IDE. ADF forms are the foundation for WebCenter Portal's components and services.

By using oracle ADF, web applications development, ADF desktop applications development, Java SOA applications development and adf mobile applications development have become much more fast and productive with new functions.

Benefits of Oracle ADF:

Some of ADF benefits are mentioned below

• ADF provides unified access to back-end technologies like databases, web services, XML, CSV, BPEL, and many more technologies.
• ADF provides data binding to connect UI (User Interface) with back-end data controls.
• ADF provides more than 100 data aware JSF view components. ADF Faces includes data visualization components, which are Flash- and PNG-enabled components capable of rendering dynamic charts, graphs, gauges, and other graphics that provide a real-time view of underlying data.
• By using oracle ADF, developers can choose different technologies to implement each of Oracle ADF‘s layers with same productive development experience.
• ADF has JAAS security model which gives facilities to developers and administrators full control over all aspects of ADF application security. Developers can define users and roles and assign various authorizations to them. Privileges can be assigned at the business service layer, the controller layer or the UI layer.
• ADF provides declarative customization and personalization of applications according to specific user requirements. A layer called MDS – MetaData Services – allows developers to customize XML definitions that Oracle ADF relies on and use different versions for different users. users can personalize the interface of their application.
• ADF allows developers to implement modifications in business rules, page flows, page layouts and other items that ADF persist in XML format. These modifications will be applied at run time based on the user that logs into the application.
• You can create your own look and feel by implementing skins for ADF Faces components. Oracle provides a stand-alone skin editor, where you can decoratively create and modify your skins.
• The ADF Faces framework allows the user to move data from one location to another by dragging and dropping one component onto another.
• The ADF Faces framework includes server-side push that allows you to provide real-time data updates for ADF Faces components.
• ADF has Widespread Ajax support. Many ADF Faces components have ajax-style functionality implemented natively. For example, the ADF Faces table components allow the sort the table by clicking a column header, selection of one or more rows and even expand specific rows in the table, this is all done without requiring the page to be submitted to the server. This functionality is implemented as partial page rendering (PPR).
• The ADF Faces library provides over 150 RIA ( Rich Internet Application ) components including geometry managed layout components, text and selection components, menus, sortable and hierarchical data tables and trees, in-page dialogs and general controls.

Oracle ADF (Application Development Framework) architecture

Oracle ADF implements MVC (Model-View-Controller) design patterns and further separates the model layer from the business services to enable service-oriented development of applications. Separating applications into these three layers simplifies maintenance and reuse of components across applications. The independence of each layer from the others results in a loosely coupled, Service Oriented Architecture (SOA).

The Oracle ADF architecture is consist on following four layers:

1. The Business Services layer - provides access to data from various sources and handles business logic.
2. The Model layer - provides an abstraction layer on top of the Business Services layer, enabling the View and Controller layers to work with different implementations of Business Services in a consistent way.
3. The Controller layer - provides a mechanism to control the flow of the Web application.
4. The View layer - provides the user interface of the application.

Oracle ADF lets developers choose the technology they prefer to use when implementing each of the layers. The ADF diagram showing above, shows various options provided for developers when building Oracle ADF applications. Oracle ADF model Layer integrates the various components of Java EE applications which makes the applications development so flexible. EJB, Web Services, JavaBeans, JPA / EclipseLink / TopLink objects and many others can all be used as Business Services for the Oracle ADF Model.

ADF View layers may consist on Web based interfaces implemented with JSF, Desktop Swing applications, MS Office front ends and interfaces for mobile devices.

The ADF Business Services Layer

The ADF Business Services layer manages interaction with a data persistence layer. It provides such services as data persistence, transaction management, object / relational mapping and business logic execution.

The Business Services layer can be implemented in Oracle ADF Business Components, Java classes, EJB, Web services and JPA objects. Data can be consumed directly from files (XML or CSV) and from REST service.

Oracle ADF Controller Layer

The ADF controller layer manages the ADF applications flow and handles user input. For example, when you click a Search button on a page, the controller determines what action to perform for a search and where to navigate the results page.

There are two controller options for web-based applications in JDeveloper:
a) Standard JSF controller
b) ADF Controller which extends the JSF controller functionality.

Whichever controller you use, you will typically design application flow by laying out pages and navigation rules on a diagram. With the ADF controller, application's flow may break into smaller, reusable task flows; include non-visual components like method calls, decision points and creation of "page fragment" flows that run inside a region of a single containing page. This approach encourages maximum reusability for user interface fragments and simplified integration into portals and mashup applications.

Oracle ADF View Layer

Oracle ADF View layer represents the application user interfaces. Oracle ADF support multi-channel access to business services allowing you to reuse your business services and access them from a Web client, a client-server swing desktop based application, Microsoft Excel spreadsheets, or a mobile devices such as a smart-phone. Oracle ADF offers a rich set of more than 150 Ajax enabled JSF components which simplified the creation of dynamic and appealing user interfaces.

Oracle ADF Model Layer

Oracle ADF model layer connects the business services to the other layers objects. ADF Model layer sits on top of business services, it provides a single access interface to any type of business service.