My ADF Experiences : 2015

Thursday, July 16, 2015

Formatting a String in Java

Below is an example how we can format a string in a java class:

StringBuilder stringBuilderMessage = new StringBuilder("<html><body>");

String panelHeading = "Heading";

String panelMessage = " Hello ";

stringBuilderMessage .append(""+panelHeading +"");

stringBuilderMessage .append(""+panelMessage +"");

stringBuilderMessage .append("</body></html>");

String formatedMessage = stringBuilderMessage.toString();

this.addFacesMessageWithMessageText(formatedMessage, FacesMessage.SEVERITY_INFO, null);

public static void addFacesMessageWithMessageText(String messageTxt, FacesMessage.Severity severity,

UIComponent component) {

FacesContext fcontxt = FacesContext.getCurrentInstance();

FacesMessage fm = new FacesMessage(severity, "", messageTxt);

if (component == null) {

fcontxt.addMessage(null, fm);

} else {

fcontxt.addMessage(component.getClientId(), fm);

}

Wednesday, May 20, 2015

Difference between RESTful and SOAP web services

Simple Object Access Protocol (SOAP) and REpresentational State Transfer (REST) are two different ways to access a web service.

SOAP is a standards-based Web services access protocol that has been around for a while and enjoys all of the benefits of long-term use. Originally developed by Microsoft, SOAP really isn’t as simple as the acronym would suggest.

REST is the newcomer to the block. It seeks to fix the problems with SOAP and provide a truly simple method of accessing Web services. However, sometimes SOAP is actually easier to use; sometimes REST has problems of its own. Both techniques have issues to consider when deciding which protocol to use.

SOAP and REST share similarities over the HTTP protocol, SOAP is a more rigid set of messaging patterns than REST. The rules in SOAP are important because without these rules, you can’t achieve any level of standardization. REST as an architecture style does not require processing and is naturally more flexible. Both SOAP and REST rely on well-established rules that everyone has agreed to abide by in the interest of exchanging information.

Overview of SOAP:

SOAP relies exclusively on XML to provide messaging services.
Replaced older technologies that didnt work well on the Internet, such as Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). These technologies fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet.
SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets.
Part of the magic is the Web Services Description Language (WSDL). This is another file that’s associated with SOAP. It provides a definition of how the Web service works, so that when you create a reference to it, the IDE can completely automate the process. So, the difficulty of using SOAP depends to a large degree on the language you use.

Overview of REST:

REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases.
REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.
Unlike SOAP, REST doesn’t have to use XML to provide the response. You can find REST-based Web services that output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can obtain the output you need in a form that’s easy to parse within the language you need for your application.
As an example of working with REST, you could create a URL for Weather Underground. The API’s documentation page shows an example URL of http://api.wunderground.com/api/Your_Key/conditions/q/CA/San_Francisco.json. The information you receive in return is a JSON formatted document containing the weather for San Francisco. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application.

Deciding Between SOAP and REST

Before you spend hours fretting over the choice between SOAP and REST, consider that some Web services support one and some the other. Unless you plan to create your own Web service, the decision of which protocol to use may already be made for you. Extremely few Web services, such as Amazon, support both. The focus of your decision often centers on which Web service best meets your needs, rather than which protocol to use.

Soap Vs Rest

SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:

Language, platform, and transport independent (REST requires use of HTTP)
Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
Standardized
Provides significant pre-build extensibility in the form of the WS* standards
Built-in error handling
Automation when used with certain language products

REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:

No expensive tools require to interact with the Web service
Smaller learning curve
Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
Fast (no extensive processing required)
Closer to other Web technologies in design philosophy

Wednesday, May 13, 2015

Oracle ADF Architecture

In simple:

Applications built with the best practices using the Fusion web technology stack acheive a clean seperation of business logic, page navigation, and user interface by adhering to a Model-View-Controller architecture.

The model layer represents the data values related to the current page, along with the model-level business rules, security and application logic used against the data values.
The view layer contains the UI pages used to view or modify that data.
The controller layer processes the user input and determines page navigation.
The business service layer handles data access and encapsulates the business logic.

The other modules that make up for Fusion web application technology stack are :

ADF Business Components: which simplify building the business services.
ADF Faces: which offers a rich library of ajax-enabled UI components for web applications built with JSFs.
ADF Controller: Which integrates JSF with ADF Model, ADF Controller extends the standard JSF controller by providing additional functionality, such as resuable task-flows that pass control not only between the JSF pages, but also between other activities, for instance method calls or other task flows. The ADF Controller also works with the data model to ensure the proper data is used for each request or region.

Source : Developers Guide

My ADF Experiences