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 Mar 15, 2013

Why, Where, and How JavaFX Makes Sense

A new article by Björn Müller, now up on otn/java, titled “Why, Where, and How JavaFX Makes Sense” incisively explores the intricacies of when, where, and how JavaFX is a good technology fit.

Müller writes:
 “Our experience proves that implementing an employee desktop front end with native technology is a valid approach and that JavaFX is a good fit.

* JavaFX is available on the leading desktop operating systems (Windows, Linux, and Mac OS X)
* Although it has gone through some painful changes, its evolution proves its vendor’s level of commitment.
* As the successor to Swing, it is being used by an increasing number of Java developers. Regardless of its future, it will benefit from a strong developer community.
* Compared to Swing, it provides a clear and clean architecture and features many enhancements: styling, event management, transitions, scene graph—to name a few.
* It provides the possibility of developing up-to-date user interfaces with animations, multitouch, and the like.
* It is based on a clear and clean language: Java.
* It provides all the professional Java tooling required to debug, analyze, profile, and log a client application.
* It enables a simple app-like installation on the client side, without any prerequisites.”

Müller provides a nuanced discussion of the kinds of architecture in which JavaFX should be embedded, its uses with JavaServer Faces, and reports on his own experiences using JavaFX.

Have a look at the article here.

Tuesday Aug 14, 2012

Enterprise JavaFX Deployment with LightView: Part 3 now on otn/java

A new article by Java Champion Adam Bien, now up on otn/java, titled “Enterprise JavaFX Deployment with LightView: Part 3,” explores ways to use Maven 3 to build and deploy the LightView application in all available deployment modes. In addition, Bien shows how to sign and deploy LightView with a Java EE 6 application.

Bien explains the basics:

“LightView uses the HTTP (REST) protocol to communicate with the back-end server. For the realization of back-end communication, an external library—the Jersey client—is used. LightView connects with the back end (LightFish) at startup time, so it is not suitable to lazy-load the Jersey dependencies for optimization purposes. Furthermore, multiple JAR files are hard to handle for standalone applications; you have to set up the class path correctly and keep all the moving parts consistent. The most convenient way to deploy Java (and JavaFX) applications is simply by starting them with java -jar my-killer-app.jar and deploying a single file that contains all the dependencies.”

He shows how the class files are packaged with the javafxpackager, which is shipped with the JavaFX 2 SDK, using the exec-maven-plugin and explains the core tasks achieved by Maven and describes the what javafxpackager does behind the scenes. He then shows how the LightView application operates and interacts with LightFish.

Bien concludes by emphasizing that the richness of JavaFX lies in the fact that it is another Java library. “Because JavaFX is ‘just’ an additional Java library, all of the established build, test, and deployment infrastructure can be reused. You can develop JavaFX applications using any integrated development environment (IDE) you like. And best of all, you can use a single language in a project, from the Java EE back end to the JavaFX front end.”

Check out the article here.

Tuesday Jul 03, 2012

The Enterprise Side of JavaFX: Part Two

A new article, part of a three-part series, now up on the front page of otn/java, by Java Champion Adam Bien, titled “The Enterprise Side of JavaFX,” shows developers how to implement the LightView UI dashboard with JavaFX 2. Bien explains that “the RESTful back end of the LightView application comes with a rudimentary HTML page that is used to start/stop the monitoring service, set the snapshot interval, and activate/deactivate the GlassFish monitoring capabilities.”

He explains that “the configuration view implemented in the org.lightview.view.Browser component is needed only to start or stop the monitoring process or set the monitoring interval.”

Bien concludes his article with a general summary of the principles applied:

“JavaFX encourages encapsulation without forcing you to build models for each visual component. With the availability of bindable properties, the boundary between the view and the model can be reduced to an expressive set of bindable properties. Wrapping JavaFX components with ordinary Java classes further reduces the complexity. Instead of dealing with low-level JavaFX mechanics all the time, you can build simple components and break down the complexity of the presentation logic into understandable pieces. CSS skinning further helps with the separation of the code that is needed for the implementation of the presentation logic and the visual appearance of the application on the screen. You can adjust significant portions of an application's look and feel directly in CSS files without touching the actual source code.”

Check out the article here.

Tuesday Apr 24, 2012

Spring to Java EE Migration – Part 4, the Finale

In a new article, now up on otn/java, titled “Spring to Java EE Migration, Part 4,” David Heffelfinger presents the final part of his series in which he demonstrates the ease of migration from the Spring Framework to Java EE. Here he compares equivalent functionality in Java EE and Spring in areas such as MVC design pattern implementation, data access, transaction management, and dependency injection.

He concludes the series with these remarks:

“In this series of articles, we developed a Java EE version of Spring’s Pet Clinic application. We saw how the advanced tooling provided by NetBeans enables us to quickly develop a Java EE application…. Once we were done building the Java EE version of the application, we compared it with the Spring version, noting that the original version has several dependencies whereas the Java EE version has none, because it takes advantage of all the services provided by the Java EE application server.

Finally, we compared how to implement similar functionality such as MVC and DAO implementation, transaction management, and dependency injection with Spring and Java EE. In every case with Spring, some XML configuration needs to be done besides adding annotations to the code. Java EE relies on convention, and in most cases, no XML configuration is needed in order to implement these services.

Although newer versions of Spring rely a lot less on explicit XML configuration than earlier versions, there are always a few little lines here and there that we need to add to an XML configuration file in order to get most of the Spring annotations to work, violating the DRY (don’t repeat yourself) principle...

Additionally, Spring applications tend to have several dependencies, because they are meant to run in a “lightweight” Servlet container such as Tomcat or Jetty and these containers don’t provide all the required functionality. In contrast, Java EE applications are meant to be deployed in a full-blown Java EE 6 application server such as Oracle GlassFish Server...

For these reasons, I always recommend Java EE over Spring for enterprise application development.”

Have a look at the article here.

Monday Apr 16, 2012

Best Practices for JavaFX 2.0 Enterprise Applications

A new article, up on otn/java, by Java Champion, Oracle Java Evangelist, and JavaFX expert Jim Weaver, titled "Best Practices for JavaFX 2.0 Enterprise Applications (Part One),” explores best practices for developing enterprise applications in JavaFX 2.0.

Weaver illustrates his points by examining a sample application named TweetBrowser which contains the following:

* “A Toolbar containing a TextField and a couple of Button controls for searching and navigating tweets obtained from the Twitter REST API.
* A ListView whose cells contain representations of the tweets. Each tweet is represented by a subclass of ListCell that contains an ImageView for the profile picture and Hyperlink controls that enable the user to navigate to screen names, hashtags, and Web links.
* A ProgressIndicator that spins when a search is performed and a WebView that displays the Web page associated with a Web link in a tweet.”

The TweetBrowser project, which Weaver invites the reader to download, contains the code for the application, portions of which he highlights throughout the article. Techniques and best practices used in the TweetBrowser application include:

    “Invoking an application via Java Web Start from the application’s home page
    Ensuring only one instance of the application is started
    Binding the UI to the model”

Weaver concludes the article by observing that, “Implementing techniques such as invoking an application via Java Web Start from the application’s home page, ensuring only one instance of the application is started, and binding the UI to the model make life easier for both the user and the developer."

Please stay tuned for Part Two of this series where Jim will explore more techniques and best practices used in the TweetBrowser example application.

You'll find Part One 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.

Tuesday Oct 18, 2011

Java Champion Michael Hüttermann on Best Agile ALM Practices

Michael HüttermannJavaOne 2011 - Java Champion and Agile ALM expert Michael Hüttermann gave a session, "Agile Application Lifecycle Management (18180)" on Tues., Oct. 4, designed to help Java developers integrate flexible agile practices and lightweight tools into software development phases. Hüttermann is the author of Agile ALM and CEO of Systemtechnologie Hüttermann. 

He covered:

* Task-based development for aligning activities with tasks, resulting in traceable artifacts

* Advanced continuous integration, which involves frequently and systematically integrating, building, and testing applications

* Agile approaches to release, configuration, deployment, and requirements management

* State-of-the-art-tool chains

The standard criticism of ALM is that it causes vendor lock-in, which increases the overall cost of an application, leaving developers with the challenge of balancing the pluses and minuses of Agile ALM. While Hüttermann admits that this has traditionally been true, his conception of Agile ALM results in flexible, high-quality processes and tool chains that are sufficiently open to change to avoid lock-in. By relying on lightweight tool chains, developers can improve flexibility because they can readily replace small units of the overall infrastructure without touching other parts. One of the main purposes of Agile ALM is to minimize accidental complexity.

Among the take-aways from the session:

* Continuous integration (CI) refers to the automation of the build, test, and release process with the goal of integrating the activities of colleagues and the work items others produce. This can result in a build ecosystem in which a new-code commit directly triggers a continuous build.

* Agile ALM defines task-based activities that are aligned with requirements, which means the activities are linked to requirements and all changes are traceable to their requirements.

* Agile ALM Tools are no longer cumbersome, monolithic vehicles that can restrict development. They need no longer cover all facets of the ALM ecosystem. Mashups of lightweight, focused, service-oriented, customizable tools are gaining momentum. Developers should feel free to switch from one tool to another.

Agile ALM aficionados should check out the forthcoming Java Magazine article by Hüttermann, set for publication in the November/December issue. If you haven't registered for the magazine, run, don't walk. It's free!

And be on the look out for a forthcoming otn/java interview with Hüttermann as well.

Finally, this JavaOne 2011 presentation can also be viewed @ http://parleys.com/d/2666.

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
24
25
26
27
28
29
30
   
       
Today