aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Java Application Architecture Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Java Application Architecture " Watch "Java Application Architecture " New topic
Author

Java Application Architecture

paul nisset
Ranch Hand

Joined: May 13, 2009
Posts: 177

Hi Kirk,
Would you design an application differently based on the device it will be viewed on or would design a mobile application the same as a web application regardless ?
An example I have in mind would involve reports and the type of reports that would be available based on a device.
thanks,
Paul
William P O'Sullivan
Ranch Hand

Joined: Mar 28, 2012
Posts: 859

I can't speak for Kirk, but ...

That is the isolation aspect of architecture.

Well defined views or models can always be rendered effectively based upon the target device.

Today's devices are much more capable than even those of a year or so ago.

I remember having to check the incoming requests metdadata for resolutions!
Nowadays, let css or xslt transformations do that for you.


WP
paul nisset
Ranch Hand

Joined: May 13, 2009
Posts: 177
Thanks William.
Kirk Knoernschild
author
Ranch Hand

Joined: Apr 16, 2012
Posts: 41
Hello,

This is where you need true separation of client code and server code. The server code isn't an application per se, but web services that expose a RESTful API that's consumed by numerous client-side applications. Some of those client-side applications might be web applications on the desktop. Others might be client-side mobile web applications written entirely in HTML5/CSS3/JavaScript that use AJAX/JSON to pull back data from the services. Others might be client-side native mobile applications you develop using that native mobile SDKs (iOS SDK, Android SDK) that invoke the services.

Figure 6.6 in Chapter 6 on SOA and modularity illustrates this perfectly. Use modularity to maintain the internal integrity of your services just as you'd use modularity to maintain the internal integrity of a monolithic application. But the day of the monolithic application where client and server-side presentation, domain objects, and data access objects are all bundled together into a single application is quickly coming to an end. It's not a sustainable development model in a multi-channel world. Unfortunately, Chapter 6 isn't available for download. So for the first time this week, I'll tell you ... Buy the Book. Or win a copy.:-) The first six chapters lay this out for you. The rest of the book (i.e., the patterns) help you do it.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
paul nisset
Ranch Hand

Joined: May 13, 2009
Posts: 177
Thanks Kirk.
I was just starting look at the patterns on your web site.
One thing I think about my own applications is coordinating the relationship between objects and object reuse.

Applying this to services is a similar situation.
You want the service to be modular but to be useful, it has to be able to interact with other services.

The situation I mentioned about reports and devices is something I'm looking at now.
I have module that provides a report that provides many rows and columns that works on big screen but on a phone screen would be cumbersome.
So I am think of providing different/extra methods methods for reporting . Ie adding a method that only displays one record at a time that would work on a phone as well as a pc browser.

The book looks interesting.
Thanks.
Paul
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java Application Architecture