|
|
Java strikes back
Posted On August 20, 2003 by Ramdas S filed under Java , Miscellaneous
It was a dream come true experience for developers entrapped in the world of proprietary systems. It meant freedom, openness, idealism, power, creativity and much more to developers who simply grabbed the technology with both hands. It was the language of the Internet- where many a cyber dreams bloomed. Many businesses rode on waves created by this Storm in a Coffee Cup. It took some of its competition by surprise, and before the world realized it revolutionised Internet computing. Java was truly a revolutionary language, platform and infrastructure for next level businesses.
The dot-coms flourished on the Java platform. New embedded technologies were envisioned, and the infrastructure was expected to build e-businesses across the globe. Then came the crash, and the recession! When the business models that rode the Internet wave crashed, there was an automatic allergy to technologies that built it! Suddenly the lovers turned detractors. Admirers turned critics and rave reviews became harsh criticisms.
It left many a Java fan appalled. With thousands of specialists jobless, the technology suddenly lost the charm. The competition seized the opportunity and sharpened the initiatives. New products were hyped as Java killers, and many spelt doom for Java platform. Vendors who built products around Java bit the dust. Many more were rendered jobless.
Analysts, editors, writers, and consultants were asked the question… will Java survive? The truth is that it has survived. And a bigger truth is that it has become even stronger. And it is striking back with a vengeance, where it hurts the competition the most. In this special edition we look at Java, and how it returns back to the limelight with a vengeance…..
Java - The Road Ahead
Java has not been withered by the storms of hype and anti-hype. It is proved itself as a strong and mature technology, and is moving on. Java represents the trend of computers where different components that make up a computing standard, can exist independent of each other. Just like the transition from mainframes to personal computers, from client server architecture to Open Systems based on Java has revolutionized the world of information technology.
In 2003, Java is about to face its biggest challenge. Microsoft's .Net platform has evolved out of its e-brochure existence, and is today shipping in a stable form. Apart from these areas Java needs to show clear road maps to the development community in some of the most happening technology spaces. We take a look at the future of Java and the challenges ahead.
Web Services
Web Services is the most talked about trend in information technology. It is hyped as the next wave of Internet computing. What does Java offer for the growing XML Web Services market?
Critics of Web Services feel that Web Services is nothing but distributed computing on a set of new standards and infrastructure. That is a simple way of defining and understanding the technology. At its core are technologies such as XML, SOAP, UDDI and WSDL. Java Community Process (JCP) has adopted these standards into future Java based web services. However the biggest challenge is going to be support for asynchronous-based computing, which is another key ingredient.
Distributed computing, especially across the Internet, deals with end points that are potentially unreliable and with networks that have qualities of service that vary widely and can't be relied upon. A system that will support asynchronous programming at its core is critical. Perhaps most important is the idea of extending these qualities to an external layer that is services-based and course-grained. In Web Services you call services and you pass XML. It does work and then gets back to you. That constrains the developer toward an architecture that will work and scale. Hence getting the Java platform to support asynchronous programming is the first and biggest challenge in the road ahead. Currently no platform supports true asynchrous standards.
Almost all vendors supporting the Java cause have their own versions of Web Services architectures based on J2EE. IBM for example is calling its Web Service model, Dynamic e-Business, which is built around the J2EE architecture. The fact remains that the majority of customers who have adopted e-business into their business infrastructure are in the initial stages of deployment.
Most of them are using Internet either for publishing or for doing some e-commerce activity. The more serious application integration has still not caught up with the majority of users. Most analysts feel that the real benefits are there in enterprise wide application integration using Internet technologies. Web services are really about integration, and what makes it work is the Web effect-you get to the point where Web services are a new type of Web standard, and it is hence hyped up.
Opportunities for developing applications become much greater, and that leads to the need for tools. J2EE tools are still way too complicated for the great mass of people who'll write applications for the Web. Hence the need for the hour is easy-to-use, non-cryptic, rapid application tools to write web applications. If the Java community fails to deliver easy-to-use tools, then Microsoft will walk away with the cake in the race of Web Services. The community will benefit if they can develop tools that are as easy to use as Visual Studio.net. To address the need for ease of development, vendors such as BEA and Silverstream are almost turning into tool vendors from enterprise application developers.
Making the Java Developers life easier
A complaint among many Java programmers is that Java is a little too difficult to master! While programming for the client in JavaScript is elementary, adapting to the architecture's more complex features such as Enterprise Java Beans and Java Message Services is a hard task for many programmers.
If Java has to make an impact in the Web Services market place, then implementing and deploying Java based solutions has to be an easier job.
But it's not just making the Java pieces easier; it's also about making the higher-level business functionality easier-a development environment where you can not only program with Java but also do personalization and to develop content.
This is where vendors such as Borland and IBM have come forward and built tools like J Builder, which helps J2EE developers use the platform more efficiently. What we would like to see however is more tools that are cheap and have wizards like Microsoft tools that can create applications in a jiffy.
More Standards for Application Integration
Since it is clear that Application Integration over the web, using XML service, is the next big opportunity, the need for clear standards that hold good for J2EE has to exist. While there are several proposals on and several standards existing, the situation is still not clear.
Microsoft has built the solution smartly on existing 'open' standards, which are acceptable to everybody. They are making money on tying the customer to the operating system and additional licensing business. Unfortunately no single vendor owns J2EE, and can only leverage on application server and development tool licensing business. Many critics find the Java Cryptic Architecture not too good for implementing Web Services due to lack of bandwidth. However, many feel that JCA is a back end technology good enough to plug into J2EE based infrastructure.
Hence a typical J2EE vendor has two choices. They can either build a solution on Java based SOAP, XML and other standards or use the messaging standards in Java. At any cost J2EE needs to have fixed standards for Web Services, based on which vendors can innovate further.
Interoperability is another need of the hour. Java development is robust, thanks to the community model, but it is slow because too many vendors are involved in decision making.
Moving the Java Standard forward
Yet another challenge within the Java community is to take the Java standards forward. Putting source code out into the marketplace and not submitting what you do to a standards organization is not driving innovation or helping the community work together.
One of the best-known development tools for Java is the Java IDE from IBM Eclipse. Eclipse is now managed by a consortium and is open and is expected to be a standard. However, moving technologies developed by vendors in to the Open Source world, and having that managed by a consortium, has its problems. While standards built around the technology will be stable, the process of standardization is time consuming. In the recent JCP meetings, members are now seeking implementation of standards within specific frameworks.
Once Standards are built, innovations happen faster, and then more products are available for customers to deploy on Java platform. So the Java Community must look at standardization much faster.
The Wireless and Mobile challenges
The big opportunity lies in the world of Wireless and mobile devices. With all third generation mobile phones having the capabilities to be a programming device, the market is huge. The original idea of Java being a platform independent operating system is paying dividends in the market. You cannot ignore the competition, since Microsoft follows the same approach it takes in any market. But all these handsets have different form factors, different capabilities, different provisioning mechanisms, different networks, and different semantics for their messages. All that makes it very hard for the wireless-application world to get the same Web effect we were discussing earlier.
The fact that J2ME has made such inroads already gives Java platform one base of stability on the client. The fact that community has a standardized application platform with J2EE, creates another huge step. The Open Mobile Alliance, which has been promoted by vendors such as Nokia among others, is trying to set standards so that Java can be implemented easily on mobile phones across the space.
However at present the handset market is largely a consumer market, and what sells are games and applications surrounding entertainment, which includes contests, polls etc. Nevertheless serious business applications seem to be a far away story.
While applications such as SMS and MMS are catching on there is still no business app, which can be used. The Java platform for the mobile devices needs to evolve further to integrate business apps. The key point is that Java vendors need to provide people with technology and a framework that will allow them to build applications. However many of the problems, need to be addressed by the wireless industry, and is not a community problem.
Embedded Space
Embedded market has been dominated for long by proprietary system vendors. Java on a chip is a reality. However there are few standards again that is being developed for embedded devices. The community may have an excuse again that embedded space is complicated with needs of specific industries being different. But the opportunity is huge, and developers need to look at solutions on J2EE for this market seriously.
Conclusion
Some of the developers we spoke to are actually seeking language independent solutions. Not everyone wants to code in Java, and is looking out whether the Java community can provide something like Common Language Runtime (CLR) as .Net. The future may see Java more as a platform rather than a programming language.
The bottom line of study revolved mostly on faster standardization. It is tough in a community where there are many voices to be heard. But when you are pitted against a company, which has clear goals and can push standards faster, the Company versus Community war becomes unbalanced.
In 2003, we hope that Java comes in with better standards for the new opportunities such as Web Services and Wireless.
The dot-coms flourished on the Java platform. New embedded technologies were envisioned, and the infrastructure was expected to build e-businesses across the globe. Then came the crash, and the recession! When the business models that rode the Internet wave crashed, there was an automatic allergy to technologies that built it! Suddenly the lovers turned detractors. Admirers turned critics and rave reviews became harsh criticisms.
It left many a Java fan appalled. With thousands of specialists jobless, the technology suddenly lost the charm. The competition seized the opportunity and sharpened the initiatives. New products were hyped as Java killers, and many spelt doom for Java platform. Vendors who built products around Java bit the dust. Many more were rendered jobless.
Analysts, editors, writers, and consultants were asked the question… will Java survive? The truth is that it has survived. And a bigger truth is that it has become even stronger. And it is striking back with a vengeance, where it hurts the competition the most. In this special edition we look at Java, and how it returns back to the limelight with a vengeance…..
Java - The Road Ahead
Java has not been withered by the storms of hype and anti-hype. It is proved itself as a strong and mature technology, and is moving on. Java represents the trend of computers where different components that make up a computing standard, can exist independent of each other. Just like the transition from mainframes to personal computers, from client server architecture to Open Systems based on Java has revolutionized the world of information technology.
In 2003, Java is about to face its biggest challenge. Microsoft's .Net platform has evolved out of its e-brochure existence, and is today shipping in a stable form. Apart from these areas Java needs to show clear road maps to the development community in some of the most happening technology spaces. We take a look at the future of Java and the challenges ahead.
Web Services
Web Services is the most talked about trend in information technology. It is hyped as the next wave of Internet computing. What does Java offer for the growing XML Web Services market?
Critics of Web Services feel that Web Services is nothing but distributed computing on a set of new standards and infrastructure. That is a simple way of defining and understanding the technology. At its core are technologies such as XML, SOAP, UDDI and WSDL. Java Community Process (JCP) has adopted these standards into future Java based web services. However the biggest challenge is going to be support for asynchronous-based computing, which is another key ingredient.
Distributed computing, especially across the Internet, deals with end points that are potentially unreliable and with networks that have qualities of service that vary widely and can't be relied upon. A system that will support asynchronous programming at its core is critical. Perhaps most important is the idea of extending these qualities to an external layer that is services-based and course-grained. In Web Services you call services and you pass XML. It does work and then gets back to you. That constrains the developer toward an architecture that will work and scale. Hence getting the Java platform to support asynchronous programming is the first and biggest challenge in the road ahead. Currently no platform supports true asynchrous standards.
Almost all vendors supporting the Java cause have their own versions of Web Services architectures based on J2EE. IBM for example is calling its Web Service model, Dynamic e-Business, which is built around the J2EE architecture. The fact remains that the majority of customers who have adopted e-business into their business infrastructure are in the initial stages of deployment.
Most of them are using Internet either for publishing or for doing some e-commerce activity. The more serious application integration has still not caught up with the majority of users. Most analysts feel that the real benefits are there in enterprise wide application integration using Internet technologies. Web services are really about integration, and what makes it work is the Web effect-you get to the point where Web services are a new type of Web standard, and it is hence hyped up.
Opportunities for developing applications become much greater, and that leads to the need for tools. J2EE tools are still way too complicated for the great mass of people who'll write applications for the Web. Hence the need for the hour is easy-to-use, non-cryptic, rapid application tools to write web applications. If the Java community fails to deliver easy-to-use tools, then Microsoft will walk away with the cake in the race of Web Services. The community will benefit if they can develop tools that are as easy to use as Visual Studio.net. To address the need for ease of development, vendors such as BEA and Silverstream are almost turning into tool vendors from enterprise application developers.
Making the Java Developers life easier
A complaint among many Java programmers is that Java is a little too difficult to master! While programming for the client in JavaScript is elementary, adapting to the architecture's more complex features such as Enterprise Java Beans and Java Message Services is a hard task for many programmers.
If Java has to make an impact in the Web Services market place, then implementing and deploying Java based solutions has to be an easier job.
But it's not just making the Java pieces easier; it's also about making the higher-level business functionality easier-a development environment where you can not only program with Java but also do personalization and to develop content.
This is where vendors such as Borland and IBM have come forward and built tools like J Builder, which helps J2EE developers use the platform more efficiently. What we would like to see however is more tools that are cheap and have wizards like Microsoft tools that can create applications in a jiffy.
More Standards for Application Integration
Since it is clear that Application Integration over the web, using XML service, is the next big opportunity, the need for clear standards that hold good for J2EE has to exist. While there are several proposals on and several standards existing, the situation is still not clear.
Microsoft has built the solution smartly on existing 'open' standards, which are acceptable to everybody. They are making money on tying the customer to the operating system and additional licensing business. Unfortunately no single vendor owns J2EE, and can only leverage on application server and development tool licensing business. Many critics find the Java Cryptic Architecture not too good for implementing Web Services due to lack of bandwidth. However, many feel that JCA is a back end technology good enough to plug into J2EE based infrastructure.
Hence a typical J2EE vendor has two choices. They can either build a solution on Java based SOAP, XML and other standards or use the messaging standards in Java. At any cost J2EE needs to have fixed standards for Web Services, based on which vendors can innovate further.
Interoperability is another need of the hour. Java development is robust, thanks to the community model, but it is slow because too many vendors are involved in decision making.
Moving the Java Standard forward
Yet another challenge within the Java community is to take the Java standards forward. Putting source code out into the marketplace and not submitting what you do to a standards organization is not driving innovation or helping the community work together.
One of the best-known development tools for Java is the Java IDE from IBM Eclipse. Eclipse is now managed by a consortium and is open and is expected to be a standard. However, moving technologies developed by vendors in to the Open Source world, and having that managed by a consortium, has its problems. While standards built around the technology will be stable, the process of standardization is time consuming. In the recent JCP meetings, members are now seeking implementation of standards within specific frameworks.
Once Standards are built, innovations happen faster, and then more products are available for customers to deploy on Java platform. So the Java Community must look at standardization much faster.
The Wireless and Mobile challenges
The big opportunity lies in the world of Wireless and mobile devices. With all third generation mobile phones having the capabilities to be a programming device, the market is huge. The original idea of Java being a platform independent operating system is paying dividends in the market. You cannot ignore the competition, since Microsoft follows the same approach it takes in any market. But all these handsets have different form factors, different capabilities, different provisioning mechanisms, different networks, and different semantics for their messages. All that makes it very hard for the wireless-application world to get the same Web effect we were discussing earlier.
The fact that J2ME has made such inroads already gives Java platform one base of stability on the client. The fact that community has a standardized application platform with J2EE, creates another huge step. The Open Mobile Alliance, which has been promoted by vendors such as Nokia among others, is trying to set standards so that Java can be implemented easily on mobile phones across the space.
However at present the handset market is largely a consumer market, and what sells are games and applications surrounding entertainment, which includes contests, polls etc. Nevertheless serious business applications seem to be a far away story.
While applications such as SMS and MMS are catching on there is still no business app, which can be used. The Java platform for the mobile devices needs to evolve further to integrate business apps. The key point is that Java vendors need to provide people with technology and a framework that will allow them to build applications. However many of the problems, need to be addressed by the wireless industry, and is not a community problem.
Embedded Space
Embedded market has been dominated for long by proprietary system vendors. Java on a chip is a reality. However there are few standards again that is being developed for embedded devices. The community may have an excuse again that embedded space is complicated with needs of specific industries being different. But the opportunity is huge, and developers need to look at solutions on J2EE for this market seriously.
Conclusion
Some of the developers we spoke to are actually seeking language independent solutions. Not everyone wants to code in Java, and is looking out whether the Java community can provide something like Common Language Runtime (CLR) as .Net. The future may see Java more as a platform rather than a programming language.
The bottom line of study revolved mostly on faster standardization. It is tough in a community where there are many voices to be heard. But when you are pitted against a company, which has clear goals and can push standards faster, the Company versus Community war becomes unbalanced.
In 2003, we hope that Java comes in with better standards for the new opportunities such as Web Services and Wireless.