Thursday Oct 03, 2013

Hands on with Oracle Java Cloud Service in Java Magazine

The latest issue of Java Magazine, which takes as its theme “Seize the Cloud,” has an article by IndicThreads founder Harshad Oak, titled “Hands on with Oracle Java Cloud Service, Part One,” that provides an introduction to Oracle’s platform-as-a-service (PaaS) Java offerings. PaaS is about renting a software platform and running a custom business application on it, thus enabling developers to focus on the business application and not have to worry about the hardware or core software platform, according to Oak.

Oak points out that, “Java EE has been the primary software platform for enterprise and server-side development for more than a decade, and it is increasingly the platform of choice even on the cloud.”

He explains that Oracle’s cloud push began in 2011, and has subsequently launched several cloud solutions that support more than 25 million cloud users worldwide. “Oracle Java Cloud Service and Oracle Database Cloud Service have been Oracle’s most visible PaaS solutions so far,” comments Oak. “Oracle’s other PaaS offerings are Oracle  Developer Cloud Service, Oracle Storage Cloud Service, and Oracle Messaging Cloud Service. Oracle Developer Cloud Service simplifies development with an automatically provisioned development platform that supports the complete development lifecycle. Oracle Storage Cloud Service enables businesses to store and manage digital content in the cloud. Oracle Messaging Cloud Service provides an infrastructure that enables communication between software components by sending and receiving messages via a single messaging API, establishing a dynamic, automated business workflow environment.”

All in all, the article examines the Java PaaS space and presents guidelines in selecting a Java PaaS service. It offers a basic description of Oracle’s Java PaaS solution—Oracle Java Cloud Service—and its capabilities. Looking ahead, Part 2 will go deeper into Oracle Java Cloud Service by showing how to develop and deploy a Java EE application on it.

Check out the latest issue of Java Magazine.

Friday Jun 07, 2013

New Messaging Features in JMS 2.0

Part Two of Nigel Deakin’s series on JMS 2.0 (Java Message Service), titled “What's New in JMS 2.0, Part Two—New Messaging Features,” is now up on otn/java. While Part One looked at new ease-of-use features introduced in JMS 2.0, Part Two explores five important new messaging features.

First, a new kind of topic subscription called a shared subscription now allows for multiple consumers on the same topic subscription.

Second, developers can now specify a delivery delay on a message so that the JMS provider will not deliver the message until after the specified delivery delay has elapsed

Third, with JMS 2.0, users can send a message asynchronously. As Deakin explains, “This feature is available for applications running in Java SE or the Java EE application client container. It is not available to applications that run in the Java EE Web or EJB container.” According to Deakin, “When a message is sent asynchronously, the send method sends the message to the server and then returns control to the application without waiting for a reply from the server. Instead of being blocked unproductively while the JMS client waits for a reply, the application can do something useful, such as sending a further message or performing some processing.”

Deakin explains that there are two main ways in which you might use an asynchronous send in an application:

* To allow the application to do something else (such as update the display or write to a database) during the interval when it would otherwise be waiting for a reply from the server

* To allow a large number of messages to be sent in succession without waiting for a reply from the server after each message

Fourth, JMS 2.0 allows applications that receive a message to determine how many times the message has been redelivered.

And finally, a Java EE application that needs to receive messages asynchronously does so using an MDB, or message-driven bean, which is configured by specifying a number of configuration properties. Check out the article here.

Wednesday Feb 15, 2012

GlassFish Adds Agility to Java EE Deployment

A new article by Julien Ponge on the front page of otn/java, titled “Adding Some Agility to Java EE Application Deployment with GlassFish,” reports on four noteworthy features in GlassFish that increase agility to Java EE application deployment.

* Session data preservation across redeployments

* Servlet fragments

* Application-scoped resources

* Application versioning

The article relies on a running example called TaskEE, a simple task list application that functions as a deployable application in which tasks are stored in a volatile Web session. Ponge shows how to morph TaskEE into TaskEEPA in order to store tasks in a relational database rather than a Web session.

Directly from the article:
“Deploying and managing Java Platform, Enterprise Edition (Java EE) applications seems like a fairly established activity. Applications can be deployed, undeployed, and upgraded through a combination of deployment and undeployment. Applications use various types of resources, such as JDBC connection pools or Java Message Service (JMS) destinations. Such resources need to be created, configured, and administered using an application server means, such as configuration files, command-line tools, and graphical interfaces. While the tasks do not vary much from one Java EE application server to another, each one is free to provide a broader set of features that make the developer’s and the infrastructure team’s jobs more enjoyable.”

Read the complete article here.

Monday Jan 09, 2012

Interfaces on Demand with CDI and EJB 3.1

A new article by Java Champion Adam Bien, up on otn/java, “Interfaces on Demand with CDI and EJB 3.1” explains that since Java EE 6, interfaces are no longer required by the container in order to realize common use cases, thus enabling developers to use them more consciously and strategically for the realization of business logic. Bien shows how interfaces can now be used as vehicles for encapsulation or abstraction, as they were originally intended.

From the article:

“There is nothing wrong with the abstraction of every implementation with an interface if such an approach can be clearly justified, but interfaces become dubious when you have to introduce artificial naming conventions to avoid name clashes…
Interfaces should be introduced only as a contract for already existing classes, for the realization of Strategy or Bridge patterns, or when you need to design an API, such as Java Database Connectivity (JDBC), Java Message Service (JMS), and so on. In typical business applications, this occurs in only a fraction of all cases.”
Read the complete article here.


About

Insider News from the Java Team at Oracle!

duke
javeone logo
Links


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
5
6
7
12
13
17
18
19
20
22
23
24
25
26
27
28
29
30
   
       
Today