News:
- In an internet driven environment, it is imperative for a company to keep its product or business to the forefront of potential customers' minds. The ...
- A successful enterprise is all about constantly reinventing ways to work more efficiently. In today’s techno age, this translates to testing new too...
- The IT industry plays a pivotal role in providing application development solutions and custom software development to a wide range of industries, i...
- Royal Victorian Eye and Ear Hospital, 2010 Atcomm has been contracted to implement a complex IOP glaucoma management tool which will be distribut...
- We are pleased to announce another implementation of a CMS system for a large Melbourne based fitness center - Star Plate Studio. Atcomm has depl...
Wednesday, 16 September 2009 12:14
Managed Smart Clients
Managed Smart Clients
4.1 Container-Managed Applications
In the field of software engineering, the term container refers to specialized software that runs other software. For example,
The MIDP Application Management Software (AMS) is a container that installs, starts, pauses, stops, updates, and deletes MIDlet applications. In the CDC Personal Basis Profile, the Xlet programming model also features container-managed life-cycle methods.
A Java servlet engine is a container that invokes servlets and provides access to the HTTP context.
The Java Virtual Machine (JVM) itself is a container. It monitors Java applications for proper memory usage (garbage collector) and security.
In the next two sections, we will discuss the features and benefits of mobile containers.
4.1.1 Container Features
As mobile enterprise applications become mainstream, the complexity of smart clients grows. For example, fully commercial applications often require features such as user login, logging, transaction, and transparent data access. Without proper tools for code and service reuse, mobile developers have to duplicate those functionalities for every smart client. Wasting time reinventing the wheel is not only inefficient but also causes error-prone code.
Hence, it makes sense to make those common features available as services in software containers that run on mobile devices. An advanced…
Published in
Java Mobile Development
Wednesday, 16 September 2009 11:14
Is Mobile Java Ready for Enterprise?
2.1 Why Java?
Before Java was called Java, it was Oak–a programming language designed for TV set-top boxes and other devices (see "Resources"). Considering its deep roots in devices, there is no surprise that many philosophies and designs behind the
Java technology are perfectly suited for mobile applications. The advantages of the Java technology are as follows.
· Cross platform: This is very important in the diversified mobile device market. In a heterogeneous enterprise environment, the ability to develop and maintain a single client for all devices results in huge savings.
· Robust: Since Java applications are completely managed, the bytecode is verified before execution, and memory leaks are reclaimed by garbage collectors. Even if a Java application does crash, it is contained within the virtual machine. It will not affect other sensitive applications or data on the device.
· Secure: The Java runtime provides advanced security features through a domain-based security manager and standard security APIs.
· Object oriented: The Java language is a well-designed, object-oriented language with vast library support. There is a vast pool of existing Java developers.
· Wide adoption at the back end: It is relatively easy to make Java clients work with Java…
Published in
Java Mobile Development
Wednesday, 16 September 2009 11:05
Mobile Commerce
Mobile Commerce: Visions, Realities, and Opportunities
1.1 Mobile Commerce Value Propositions
A lesson we learned from the bust of dot-com bubbles is that a cool technology itself does not automatically translate into business success. Successful business models leverage new technology to create values and profits from ultimate customer satisfaction. So, what new values or cost savings can mobile technology create?
Unlike the PC-centric electronic commerce, mobile commerce is focused on personal experiences. A person carries a pervasive mobile device and gets information anytime, anywhere, from anyone. For the first time in history, a person's information access can be disassociated from her environment. For example, a traveler does not need to be in her office at a specific time to get ticket information. That unprecedented freedom of information could fundamentally affect all business categories. The next several sections provide a brief overview with examples.
1.1.1 Business to Consumer (B2C)
From a consumer's perspective, mobile commerce provides extreme convenience, speed, and personalization to access information services. Let's use a hypothetical stock trader example to illustrate how mobile commerce can change the way we consume information. A mobile stock trader can access markets around the world anytime, anywhere. He can take advantage of…
Published in
Java Mobile Development
Tuesday, 15 September 2009 13:11
J2EE Design Pattern - Enterprise Concurrency
Enterprise Concurrency
The most dramatic difference between an enterprise system and a "regular" application is the number of users it must serve. As a result, enterprise applications face problems that don't often occur on the desktop. A word processor, for example, doesn't have to handle two users making changes to one paragraph at the same time—at the most, it might have to notify the second user that the document is already in use.
Of course, all data-centric applications, whether they serve one user or 10,000, need to concern themselves with the validity of their data. An action that seems simple to the user ("Order a book") may require complex, choreographed activities within the application ("Check inventory, reserve stock, charge credit cards, arrange shipping, etc."). The more operations an application performs, the more likely one of those activities will fail—and when it does, the system must be able to carry on. Providing for this capability is easy in standalone applications: just don't save your changes if the mail merge fails. But if other users have been modifying the same databases at the same time, the brute-force approach to data integrity won't pan out.
A lot of ink has been spilled on…
Published in
Java
Tuesday, 15 September 2009 10:51
Database and Data Patterns
Database and Data Patterns
Storage is the one constant in enterprise development. Enterprise systems are, essentially, information management systems. To the user, the value of these applications comes from the centralization of information resources, which allows broader access and more flexible interaction. Of course, you can maintain an entire information model in memory, but that's not the best method: if someone trips over the cord, your business is back to square one. So production applications implement persistence, storing information to reliable media.
This chapter focuses on patterns for implementing and optimizing persistent storage in the business tier. The first section introduces some basic patterns for accessing persistent resources: the Data Access Object (DAO) pattern and the Procedure Access Object (PAO) pattern.
The rest of the chapter focuses on solving recurring problems in database-backed applications. Since Java object graphs generally store relations between objects directly, we need to translate Java's direct object-to-object relationships into something that we can store in a database. The solution is a primary key: a unique identifier associated with each logical entity in the database, which can be used to represent the relationships between objects. Since unique primary keys are so important to the database side of…
Published in
Java
Tuesday, 15 September 2009 10:07
J2EE Design Pattern - Tier Communications
Tier Communications
This chapter focuses on managing the communications between tiers using data transfer patterns. Our goal is to provide a basic vocabulary for talking about exchanging data between different components of the business tier and between the business tier and the presentation tier. Ultimately, we want to be able to do this in a well-structured, efficient, and flexible way.
7.1 Data Transfer Patterns
In an ideal world, every time we send data from one place to another, we would include all the information required for the current activity, with no waste and no need for the recipient to come back with questions. Anyone who has worked technical support is familiar with the situation: it's much easier to have the user explain the entire problem at once, with all the relevant detail, rather than have to ask a series of questions to determine whether the computer is on, if an error message was displayed, if the software was actually installed, and so forth. A single support person can handle more problems with fewer headaches.
In Java terms, this ideal could involve transferring a single object containing a complete bug report, rather than transmitting several individual objects for each aspect…
Published in
Java
Tuesday, 15 September 2009 08:29
JEE Design Patterns - Presentation Scalability
5.1 Scalability and Bottlenecks
Before we jump into the patterns, let's take a minute to discuss what we mean by a scalable system. Think of a web-based system as a request processor. Requests come in from the clients, and the clients wait until results are generated. Everything in between—whether it's simply returning the contents of a static file or generating a fully dynamic page—is the actual processing.
For a request processor, scalability is related to the number of requests that can be processed simultaneously. In a simple sense, scalability might be the ability to "survive" a certain number of hits at the same time, eventually delivering a proper response to each one, but we know from experience that this is not really the case. If a news site gets 10,000 simultaneous hits and responds to each of them within 3 seconds, we might say the site scales adequately, if not exceptionally. But if the same site gets 100,000 simultaneous hits, responding to each one within three minutes would not be acceptable.[1]
For developers, acceptable scalability might be related to what's going on behind the scenes: a dynamic page won't be expected to return as quickly as a static page. Users…
Published in
Java
Monday, 14 September 2009 14:40
Java Enterprise Design
1.1 Design Patterns
A design pattern is a recurring solution to a recurring problem. From a programming perspective, a pattern provides a set of specific interactions that can be applied to generic objects to solve a known problem. Good patterns strike a balance between the size of the problem they solve and the specificity with which they address the problem.
The simplest patterns may be summed up in no more than a sentence or two. Using a database to store information for a web site is a pattern, albeit a fairly high-level and obvious one. More complex patterns require more explanation, perhaps including the use of modeling languages or a variety of other forms of longer description.
Design patterns originated outside the computer industry, originally showing up in conventional (as opposed to computer systems) architecture. Architects of buildings and architects of software have more in common than one might initially think. Both professions require attention to detail, and each practitioner will see their work collapse around them if they make too many mistakes.
The book to read, if you're interested in the architectural origins of design patterns, is A Pattern Language: Towns, Buildings, Construction by Christopher Alexander (Oxford University Press).…
Published in
Java
Recent Posts
-
Compiled and Noncompiled Android Resources
-
Using resources, Content Providers, and Intents
-
Examining the Application Lifecycle
-
Exploring the Structure of an Android Application
-
Learning the Fundamental Components
-
Getting Your Feet Wet
-
Android Service Components
-
Developing an End-User Application with the Android SDK
-
Introducing the Android Computing Platform
-
Setting up a Successful Website