Binary Spectrum Geeks at work

Here are some similarities, differences, advantages and disadvantages of architecting/developing applications in .NET over J2EE.To summarize these 2 technologies for a layman to understand would be:

 .NET – Relates to Productivity, Simplicity and “Out-of-the-box”.

J2EE – Relates to Flexibility, Complexity and “Do-it-yourself”.

1. To bring about a comparison with respect to the Architectural Philosophy, below are some of the points that have been identified:

            J2EE

 J2EE was created to give something better and more scalable than CGI or CORBA and to help standardize pervasive enterprise technologies such as message oriented middleware (MOM). As such, J2EE had some - great hits in Servlets instead of CGI,
- lackluster - EJBs instead of CORBA Hence the J2EE is a result of a powerful but also very complex framework.

Some of the big architectural advantages that one can enjoy when working on J2EE are the flexibility and the extensibility rendered by the J2EE API’s, which leaves ample room for open source innovations. Another noted feature is that J2EE can run on any platform.

Amidst all this a major concern would be the need for expensive application server to run its applications where they often add very little value relative to its license cost.

J2EE has limitless options for implementation of domain models backed by object-relational and cross-enterprise integration tools.

            .NET

            The major architectural additions to the .NET Framework were:

<!--[if !supportLists]-->·         <!--[endif]-->The "adoption" of the Java language as C#.NET

<!--[if !supportLists]-->·         <!--[endif]-->S.O.A.P. (Simple Object Access Protocol) and its native support for OO-to-XML

<!--[if !supportLists]-->·         <!--[endif]-->Re-design of VB into a VB.NET to make it, as Java/C# was, fully object oriented.

The architectural advantages identified here is that the focus is on the developer and hence is easy to work with, it follows a simplified transition path from the client-server to the enterprise development model. But unlike J2EE where it is platform independent, .NET is restrained to just one platform.

.NET has a harder time supporting database independent implementation of the domain model because of its less mature or mapping tools.

1. To bring about a comparison with respect to the Framework Components, below are some of the points that have been identified:

            .NET

 The major architectural components of the .NET framework that most of the developers use are ASP.NET pages, plain objects written in some .NET language, ADO objects and Web Services.

            J2EE

 J2EE design is heavily based on design and architectural patterns such as "MVC - Model View Controller", Facade, Factory, Layers which makes it somehow more complex to understand to the uninitiated.

In general, the most commonly used core components in J2EE are Servlets, JSP and JDBC for database access. These roughly correspond to "code behind", ASP.NET and ADO.NET components in .NET.

J2EE defines one or more sets of components for enterprise tasks that are not even defined in .NET. So in J2EE we have:

<!--[if !supportLists]-->·         <!--[endif]-->EJB for object remoting, message (as in MOM) processing and relational persistence

<!--[if !supportLists]-->·         <!--[endif]-->JMS for Message Oriented Middleware (MOM) abstraction

<!--[if !supportLists]-->·         <!--[endif]-->JDO for relational persistence

<!--[if !supportLists]-->·         <!--[endif]-->JCA for non-relational enterprise access

<!--[if !supportLists]-->·         <!--[endif]-->JAAS for security services and SSO abstraction and so on.

Not very many people write their web apps using Servlets and JSP only. Most of the J2EE developers use either aging but widely popular Struts framework, official J2EE JSF web framework, more recent and innovative Spring MVC or WebWork, etc.

1. To bring about a comparison with respect to the Web Components, below are some of the points that have been identified:

            .NET

 In general, ASP.NET is easy to work with; the tool support through Visual Studio product line is very good. There is also a very good set of components available for the common web development tasks.

Its code behind concept is easy to understand and it is flexible enough to extend through smart use of design patterns. I like how ASP.NET manages to keep configuration files and application settings under control. Unlike J2EE, there are no verbose xml files for every little component you want to use. You specifically configure only special cases and exceptions.

Another attractive feature is how Microsoft incorporated Atlas (their AJAX frameworks) into ASP.NET. Deployment of ASP.NET applications is very easy.

            Some of the concerns that have been identified with ASP.NET are:

<!--[if !supportLists]-->·         <!--[endif]-->The increased risk of code replication which in other terms increases code duplication and could create a significant maintenance burden.

<!--[if !supportLists]-->·         <!--[endif]-->Addition of data binding objects, including query definitions into the ASP.NET pages itself.

            J2EE

Servlets came as a better, faster, more expressive replacement for then popular CGI-BIN. They are very POST/GET and HTTP parameters oriented. API is easy to work with but it is very bare. It could be categorized in the following procedural format:

            Request, Response, Session and Context.

            The advantages that are seen in its use are:

<!--[if !supportLists]-->·         <!--[endif]-->Portability

<!--[if !supportLists]-->·         <!--[endif]-->Extensibility

<!--[if !supportLists]-->·         <!--[endif]-->Richness and Sophistication of available Value Add Open Source Frameworks

            Some of the issues that have been identified with J2EE are:

<!--[if !supportLists]-->·         <!--[endif]-->Complexity of the deployment model

<!--[if !supportLists]-->·         <!--[endif]-->Bareness of the core API

<!--[if !supportLists]-->·         <!--[endif]-->Over-saturation with choices

<!--[if !supportLists]-->·         <!--[endif]-->Need for application server.

 The Author Hermon Peter is a Software Engineer at Binary Spectrum.

Posted by Ashok Kumar at 12:52 PM | Permalink | Comments (1) | TrackBacks (0)

Mobile..

Mobile..

Mobile..

In today’s scenario - a very common name, a technology which in recent years has seen growth in leaps and bounds. As the economics of demand set in, competition between the various Mobile Manufacturing companies hots up. Complementing all this is the new generations of competent mobile application developers, who are making their dream come true.

The most commonly used mobile application development platforms are

1. Sun’s Java 2 Platform Micro Edition – J2ME, and
2. .NET Compact Framework (CF)

 Both have their own advantages and disadvantages,

J2ME, which has been around for quite a while, is the platform of choice for the application developers, as it is beholds the same JAVA motto, “Compile Once, Run Anywhere” and this holds true for mobile application development. J2ME developers can write their code without worrying about cross-platform portability.

In recent years Microsoft has extended its .NET environment to the Windows operating system based mobile devices with the .NET Compact Framework (CF). .Net CF runs only on one operating system – Windows.

For the Mobile Application Developers, how do these two platforms measure up? What are the strengths and weaknesses, of each platform? And Last but not the least, which of these is the best suited platform for developing and deploying your mobile application?

To answer these questions lets examine Bluetooth – a very important emerging standard for wireless integration of small devices. It is said that the “sky is the limit” in terms of applications that will be available in the not so distant future. The JSR-82 specification standardizes a set of Java APIs to allow Java-enabled devices to integrate into a Bluetooth environment.

The Java Bluetooth API basically relies on the Java Generic Connection Framework (JGCF), which has been around for a long time. One of the main advantages is that the Bluetooth API can be made accessible for a broader range of systems as the technological advances occur.

The Java APIs for Bluetooth defines two packages:

1. javax.bluetooth - for the core Bluetooth API, and
2. javax.obex -for the Object Exchange (OBEX) protocol.

All Bluetooth applications need these components for:

1. Stack initialization,
2. Device management,
3. Device discovery,
4. Service discovery, and
5. Communication.

As per the JSR 82 specifications, a Bluetooth system should have a Bluetooth Control Center (BCC). The BCC, is defined as the heart of a Bluetooth System, it allows a user or the OEM (Original Equipment Manufacturer) to define specific values for certain configuration parameters in a stack. In particular, it would be used in a stack initialization.

The API is intended to provide the following capabilities:

            1. Discover devices and services

            2. Register services

            3. Establish connections( it may be OBEX, L2CAP or RFCOMM) , and finally

            4. Conduct these activities in a secure fashion

The Mobile Information Device Profile (MIDP) is a specification which standardizes Java on embedded devices and is a part of Java Micro Edition Framework (J2ME framework). MIDP devices are expected to be the most prevalent class of devices to incorporate the above said specifications, and the specification allows for the coexistence of Bluetooth APIs and MIDP. This specification was developed under the Java Community Process, and is known as the JSR 82.

We conclude that the J2ME framework is, with its enriched Features, is one of the most widely used. Sun’s J2ME wireless toolkit 2.2 has a Bluetooth simulator and also supports OBEX and is the basic available development Kit for J2ME applications.

The Author Somnath Das is a Software Engineer at Binary Spectrum .

Posted by Ashok Kumar at 08:50 AM | Permalink | Comments (1) | TrackBacks (0)