Archive for May, 2010

Is Google Heading for Victory?

android_appsThere have been a number of heated debates in various media lately concerning Apple’s iPad, producing a variety of opinion ranging from highly critical on the one hand to positive and encouraging on the other. However, even with a significant amount of critical feedback, Apple still holds the leading position in the global market.

Recent statistics published extensively in various media outlets and on social networking platforms show quite an interesting tendency which might cause Apple to rethink some of their policies which seem become stricter and stricter every day. Google’s Android, which was merely an attempt to create a ‘copy’ of theiPhone OS, is suddenly taking the lead in  technology reviews and enjoying immense popularity among users (around 100,000 people signing up for it daily). Statistics also show that the Motorola Droid and Droid Eris are enjoying considerable success. So, what’s in store for us in the future and who is going to be the ultimate leader of the market?

The original war between the two operating systems – Microsoft and Apple – may give Google some hope for winning the mobile race. The fact that Apple insisted on running its Mac OS on Apple hardware only while Microsoft had no such restrictions contributed to Windows becoming “universal” and immensely popular among users worldwide.

However, it is not just users who will determine Google’s success. Developers are also quite likely to switch to Android.

The problem here lies in the nature of Apple’s handling of its applications. The fact that Apple has increased its control which resulted in many apps being rejected has discouraged many app developers from working on the platform.

The situation is also being aggravated by Apple’s fight with Flash. This has caused major criticism as Apple once again established itself as a “closed” platform. The introduction of the Android Froyo, which in contrast does support Flash has received positive feedback from developers.

Meanwhile, as far as this “battle” is concerned, the future remains uncertain. Apple is soon to launch its fourth-generation iPhone which will encompass a number of features  long-awaited by Apple’s customers. Even though this may not quite outstrip Android in sales, the rumors that the iPhone might soon be available to Verizon customers gives some hope that Apple will win back those who initially switched phones because of the rather unstable service from AT&T.

Time will tell if Android’s victory forecasts are justifiable. Meanwhile, let’s just wait and see what the giants have to offer to consolidate their position on the market.

Software Architecture and its Refactoring

Why change architecture?

The need to change corresponding software may arise in the process of solving a large number of tasks aimed at its modernization. Generally, changes in corresponding software may concern not only its code, but all the other artifacts connected with a transformed program system. One of the most significant issues in this respect is the change of program system architecture. The following scenarios requiring a change in the existing software architecture may serve as valid examples here:

- Transformations determined by functional changes of software. It is desirable that the implementation of the new functionality does not alter the existing system logic. It is also important that the complexity of the implementation of the new functionality into the existing system does not significantly exceed the complexity of the realization of this functionality within a new project. Good architecture makes it possible to reach the goals set. Therefore, changing the corresponding architecture is a good step forward towards the implementation of the new functionality which also simplifies further system evolution.

- Change of software platform. It is highly desirable that the change of software platform may have the smallest possible effect on the existing code; it should only involve changes in the narrow platform-dependant system layer. The separation of this layer is an architecture task. Its solution is always connected with the necessity of architecture change.

- Transformations caused by the reorganization of the company which carries out the development. Outsourcing is a very good example of such reorganization. The solution to use outsourcing is a typical step taken towards the optimization of production. Unfortunately, this step is often made difficult by the problem of separation and transfer of components for external development. Changing program system architecture makes it possible to ease the solution of this task.

This list of scenarios leading to the necessity of changing software architecture is not complete: the examples mentioned above are merely to demonstrate the large range of tasks which require such changes.

Differences between Architecture and Classical Refactoring

code refactoringWhen refactoring methodology is transferred to the architecture layer, there are a number of specific features which determine the change of method characteristics:

Objects. While making a transition from classic to architecture refactoring, the objects on which the operations are performed also undergo certain changes. In classic refactoring, such elements as class and class instance are among the entities to be worked on. Architecture refactoring is applied for systems and components. Different types of connections which emerge between objects are also distinguished in various refactoring types.

Scope of changes. Classic refactoring is applied exceptionally in lesser scale. Usually, the consequences of the application of a separate classic refactoring pattern are limited to several files. Architecture refactoring patters are applied to architecture components. As these patterns are projected backwards from the structural model level to a program code, the changes may cover a significantly greater size of the existing code. 

Description of changes. Methods of classic refactoring can be illustrated with static models of language and code fragments. It is more convenient to use specialized structural models and tools which support reverse engineering for the description of architecture refactoring.

Testing. Transformations are considered correct if they don’t cause the change in the general “behavior” of a program system. The availability of a sufficient number of unit tests allows for the verification of the correctness of transformation. This makes unit testing one of the key aspects of classic refactoring. Architecture refactoring is also faced with the task of automated verification of the correctness of transformations. Unit tests allow the developer to be assured the changes are correct even when architecture refactoring is applied. At the same time, it is presently unclear how effectively unit testing works with architecture refactoring methods. In fact, this is determined by the difference in the scope of changes at classic and architecture refactoring.

Specific Features of State-of-the-Art Tools for the Creation of Java-Applications

There are a number of specifics of tools for the creation of Java-applications which are interesting in terms of finding corporate solutions. Among them are: tools for enhancing productivity of developers; tools for supporting team operations; support for various stages of the application life cycle – preceding the creation of applications codes (such as requirements management, data and application modeling), and those following it (testing, implementation and maintenance); possibilities for  reusing models and codes; support of tools and standards for the creation of distributed applications and their integration (including the support of J2EE standard and XML Web-services); and creation of mobile solutions with the support of J2ME standard.

Tools for the development of Java-applications usually have various means of enhancing the work productivity of programmers.

Other uses which may not seem as obvious  ware refactoring tools for the automatic introduction of concomitant changes in the code at the redesignation of classes (for example, changing the code containing links to a redesignated class); changing of the parameters of methods; automated addition of constructions “try….catch” around the code block with the account of possible exceptions which can appear when the methods which the block contains are requested, and other actions connected with the automatic introduction of changes into the code which is important for collective work on large projects and for the code reuse. Useful specific features of Java-instruments are tools for the creation of testing classes, tools for converting SQLJ1 files into a Java-code, various tools simplifying the generation of tests and application supply, and also the availability of masters for the creation of web applications, web services, code generation based on WSDL2-descriptions.

uml modelling

As far as the support of the application design goes, it is important to point out that the creation of Java applications on the scale that modern businesses require is practically unimaginable now without the application of UML modeling tools. Such tools can be included in the product composition, or can be supported on at interface level. Here, the most preferred option is for UML modeling tools to be represented by modules embedded in the development environment and supporting a synchronized or simultaneous alteration of models and codes.

It is important for all products competing in Java application development to be able to create EJB (Enterprise Java Beans). These are the objects accomplished under the supervision of application servers supporting the J2EE specification.

This possibility is important for applications of this tool in B2C (online product sales, booking tickets and hotels), B2B (virtual trading platforms and online auctions), and B2E  markets(corporate portals). Very often corporate solutions have configurations containing several application servers or various cluster configurations. Manufacturers of Java instruments frequently make their own application servers, yet many support the creation of EJB objects and other application servers of other manufacturers.enterprise java beans

One more important feature typical of the majority of Java application development tools is the support of the creation of mobile solutions based on J2ME specifications. The support of the creation of mobile solutions can be realized in a variety of ways, ranging from the addition of extra masters and classes to the creation of specialized editions of Java application development tools, including those for separate types of mobile devices.

As a rule, modern tools for the creation of Java applications support the development of applications for several different platforms – usually Windows, Linux, Solaris and sometimes others.

In conclusion, quite often the tools for Java application development itself can be supplied both separately and as part of a set of tools which typically contain UML modeling tools, application server development tools and tools for the commission of EJB and often others, too (for example, tools for the creation of user interfaces of Web applications or optimizing application productivity).

Next-Generation Approach to the J2EE Mobile Application Container

j2ee mobile softwareJ2EE in its current state needs custom coding to support mobile applications development. A large number of challenges involved in mobile application development can be resolved, provided the developer is equipped with the right set of resources at the J2EE infrastructure level, and the need to write the custom code and patches is eliminated. It is possible to significantly extend J2EE technology with the following services to simplify and enhance mobile application development:

  • Transformation Engine: A scalable engine that applies attributes and features of devices such as device profiles. This transformation engine may have an XML or DOM interface and must also allow for overriding the look and feel.
  • Device Profiling and Personalization Manager: A device profile and personalization manager which models devices with the application of a set of attributes (e.g. screen size, memory, keyboard layout, display capabilities) and the capability to provide applications and content.
  • Memory and Cashing Manager: A stable memory and cashing manager to make an optimal separation and cache the content based on mobile device profiles with links to the server-side cached content.
  • Session Manager: A session manager meeting the needs of mobile devices and accommodating multi-modal sessions, and handling the intermittent connectivity of wireless networks.
  • J2EE Standardization: Support for existing J2EE standards and development methodologies.
  • Data Access Manager: A data access manager leveraging the existing J2EE data access methodologies and integrating to existing Java middle-tier tightly at the API-level.
  • Message and Notification Manager: A message and notification server which simplifies synchronous and asynchronous notification generation, transmission, reception, and administration.

The construction of a container to provide components for satisfying all of these requirements in an integrated fashion is significantly valuable. If such services/components were available separately, there would still be a significant amount of coding needed to integrate these APIs in a servlet and use them in standard development methodologies. For instance, the servlet developer still has to retrieve the device profile and personalization object, storing them in the session, calling the transformation engine, passing the session information, and then calling the cache manger, creating the appropriate links, and storing this additional content in the session as well.

A container which could manage these services and offer support for standard J2EE development methodologies, if provided, can surely manage the real power of these services. For example, such a container could allow for the development of “actions” or content in the form of Java (DOM) or XML. The session information would be managed and readily available in any action residing in the container. The developer would simply create an action in JSP or Java and need not manage the calling of the services as the profile object and device personalization objects would be instance variables in the container. The mobile action container can also pool objects and may distribute and manage the service across different JVMs or even across different servers. Each server would provide a specific service.

The application would be made future-proof with the help of such a container which would provide clear separation between the application and server code. This container may be realized within the servlet or EJB containers, or be worked out as a new J2EE container.

New Model for Corporate Applications

Flexible components form basis for the J2EE applied model. This simplifies the development of powerful applications. It allows utilization of all the advantages of Java technology in all J2EE applications, namely scalability, transferability and easy programming.

j2ee enterprise software
BluePrints Design Guidelines from Sun Microsystems for the J2EE platform describe the application model and uses. The J2EE model was developed on the basis of the Java 2 Platform, Enterprise Edition, and simplifies the principles of the development of scalable and widely accessible Internet and Intranet applications.

Here we ask: what functions are missing from Java 2 Platform, Enterprise Edition? The solution of various complex tasks to be performed by corporate applications, namely the management of business operations, life cycle, the merging of resources are all already embedded in the platform and are performed automatically for all supported constituents. So what should be the primary emphasis for developers in terms of solving tasks related to new functions? Most likely business logic and user interface.

There is yet another advantage of J2EE which is in the fact that the application model includes levels of functional possibilities in certain types of constituents. Business logic is included in Enterprise Java Beans (EJB) constituents. The interaction with a client can be realized by means of ordinary HL webpages, by means of webpages using applets based on Java technologies, Java Servlets API or JavaServer Pages technologies, or by means of autonomous Java applications. The components interact openly, using various standards, like HL, XML, HTTP, SSL, RMI, etc.

The possibility of a multiple use of J2EE constituents offers enterprise software developers and IT organizations a compatible choice. J2EE will allow them to collect applications from the combination of standard, widely accessible constituents and of their own customized constituents. It is assumed that a number of standardized functional capabilities of J2EE will be able to carry out a wide range of tasks, from the development of generally business applied constituents to the solution of problems for vertical markets.

This means that an e-commerce website can be designed with the application of a combination of ready-made EJB constituents for the (organization of work of a consumer basket); modified EJB constituents for the creation of specialized services for a client and completely new levels with the JavaServer Pages application technology which will make the website unique.

This approach to creating a website means that less time will be required for its development, and better quality of performance, maintainability, and transferability within the limits of a wide range of platforms will be achieved. Among the major advantages of such an approach are improved performance by the programmer, computer resource utilization strategy  and a substantially increased ROI from technology.