Sun recently published an article on its website titled: "XML Client/Service and the Java Platform Take On .NET": With the emerging XML Client/Service technology, web applications can embody a rich user interface, reliable messaging, and performance comparable to .NET desktop applications while still retaining the zero-install deployment advantage of the web.

The article is certainly interesting. Though I am not sure of the relationship between Nexaweb and Sun Microsystem, Sun seems to be endorsing such a technology. If it is true, it would be really great for the industry.

Can this be XAML for J2EE (only a few years ahead of the arrival of XAML)?

The full article is at Sun's website here.

In related news: Brian Duff wrote about XAML in his blog, Why XAML is going to kick Swing (and SWT's) ass

Go to http://www.nexaweb.com/product_FAQ.htm and search for .NET . You will find that Nexaweb works with .NET too. As far as I understand, only the server side can be written in Java. What about the "The Nexaweb Client" side?

Regards,
Horia

Are you sure all browsers include java by default? Otherwise it's not zero-install.

Are you sure all browsers include java by default? Otherwise it's not zero-install.

No they don't. Some versions of XP don't have Java installed.

The point though is that this is compatible with Java 1.1 (the version of Java supported by every browser since IE/NS 4) so it should work with anything (even Explorer on XP).

As an aside, though, Sun's efforts from a year or so ago seem to be paying off. Most new PC's these days seem to be shipping with the current Sun JRE on them anyway (even the new Dell boxes my company recently bought had Java 1.4 on them out of the box).

They use only Java 1.1 which is installed on 95% of all computers. Even if Nexaweb can use .NET on the client it will take a long time before they reach 90-95%. It is a Garguatan task to evaluate all these new Rich-Clients framework but Nexaweb do semm to be the most robust and scalable.

Regards
Rolf Tollerud

What percentage of all computers runs .NET?

I really have no information but I would guess only 10-15%.

Ordinary Java applets made in 1.1 are also suddenly good candidates for "Rich Clients". Why? Because MS has recently made the Official Release of Microsoft J# Browser Controls Version 1.1 and with that you have a guarantee that your applets never will be obsolete. All Java 1.1 applets convert automatically to J#.NET.

Regards
Rolf Tollerud

From XP, Java isn't preinstalled on windows,so if want to use JRE you have to download java and install it.so many computers don't have java http://www.developerzone.biz/index.php?option=com_content&task=view&id=128&Itemid=36

Rolf Tollerud wrote:

They use only Java 1.1 which is installed on 95% of all computers.

Rolf, how do you generate a statistic like this? ;o)

Actually, MS did a pretty good job of killing Java on the client. Windows XP has been shipping for over 2.5 years. Other than a five-month window when SP1 was available for download, has it ever included a JVM?

The typical large enterprise is on an average 3-year desktop replacement cycle, and for more than 2 of the last 3 years, Windows has not included Java. If you want Java on the client, you *probably* need to install it.

If you manage all of the clients in your workgroup or intranet, you might be able to do this. For extranet and Internet apps, forget it.

It would have been great if the WORA promise of Java on the client were a reality when Polese and company started pushing it in 1995. But they underestimated the technical hurdles to deliver on that marketing promise, and MS certainly wasn't going to allow them a few years to backfill.

We aren't all doing web applications today because the technology is much better than a decade ago. We're doing it simply because *everyone* has a web browser. Not everyone has a JVM, or .NET framework, or Flash.


Jeff Dill
Isomorphic Software
www.isomorphic.com

A short unscientific survey of friends & family revealed that all have Java installed, many from games.

Before or later you have to download the JRE, for one program or other. Then I believe, as MS is always striving to be backwards compatible, if you install XP over win98/ME (not in a new catalog) your Java is still there.

So If Java "Rich Clients" fails at the desktop they can not blame it on MS! :)

Nexaweb is doing just what Sun/JCP should be doing. Bringing together XUL/SVG/Java at the desktop.

Regards
Rolf Tollerud

A short unscientific survey of friends & family revealed that all have Java installed, many from games.

So let's talk about the audience for J2EE applications, not games. Try a survey within corporate networks.

as MS is always striving to be backwards compatible, if you install XP over win98/ME (not in a new catalog) your Java is still there.So If Java "Rich Clients" fails at the desktop they can not blame it on MS!

Rolf, do you work for Microsoft? :)

Nexaweb is doing just what Sun/JCP should be doing. Bringing together XUL/SVG/Java at the desktop.RegardsRolf Tollerud

Yes, but nothing new. Altio and Canoo have had robust products doing this for many years. XWT is an OSS offering with an applet-based runtime. Thinlet, Bambookit, Asperon, eNode--all of these guys offer Java rich clients. None has achieved broad adoption, because of the client installation/administration barrier.

Zero-install seems like a small factor, but if you think about it, it is one of the two core reasons that most new apps today are developed as web apps.

The other reason is *standards*. And we all want a standard for this. Microsoft and Macromedia are fighting to control it right now. The rest of us will support whatever the market adopts.


Jeff Dill
Isomorphic Software
www.smartclient.com

Part of the recent Sun-Microsoft agreement was that MS will again license the JVM and include it with Windows. I think this is a non-issue ...

>
The other reason is *standards*. And we all want a standard for this. Microsoft and Macromedia are fighting to control it right now. The rest of us will support whatever the market adopts.
>

Right on. But I think we should not disregard IBM ... IMO Macromedia does not seek to establish a standard with their high-cost proprietary product.

Part of the recent Sun-Microsoft agreement was that MS will again license the JVM and include it with Windows. I think this is a non-issue ...

When? Are they doing this now?

Regardless, about 200 million copies of Windows XP shipped so far without a JVM is certainly an issue. FYI, Microsoft just claimed more than 210 million copies of XP shipped, not counting corporate licenses.

IMO Macromedia does not seek to establish a standard with their high-cost proprietary product.

If you believe the numbers, Macromedia has the one of the three largest developer bases in the world. As a business, it would be negligent of them not to exploit that base to create a de facto standard.

Maybe you don't think that Macromedia's HTML and Flash developers are "real developers". But if Flex and Brady enable them to achieve better results than your average Java programmer, who cares?


Jeff Dill
Isomorphic Software
www.smartclient.com

Jeff,

Great to see other vendors in this space getting the word out...

I do feel the need to correct you on some of your statements regarding Java and versions of Windows.

Regardless, about 200 million copies of Windows XP shipped so far without a JVM is certainly an issue.

I'll grant you that Microsoft may have shipped 200+ million copies of Windows XP, *but* Windows XP does ship with the Microsoft JVM.

That said, Microsoft has removed MSJVM from Windows XP SP1a, which means that *if* someone does a clean install of a Microsoft provided Windows SP1a CD, they won't have Java; however if they upgrade from older versions of Windows they will keep their MSJVM. For the complete list of versions of Windows that ship out of the box with the MSJVM go to http://www.microsoft.com/mscorp/java/faq.asp towards the middle of the page it posts a list.

So I'd saw that most of those 200 million copies of Windows XP probably do have a JVM on them. That said, and to not mince words, you are correct that Microsoft has stopped including the MSJVM as of Windows XP SP1a.

The great news is that Sun has inked deals with Apple, Dell, HP, Lindows.com, Red Hat, Acer, Gateway, Samsung, Toshiba and Tsinghua Tongfang, all of whom will include the *latest* version of Java on machines they ship. See Sun's press release for more info http://www.sun.com/smi/Press/sunflash/2003-09/sunflash.20030923.1.html.

Sounds to me like not only will Java be on most client machines, but that new machines will include the more recent version of Java versus the old MSJVM. Doesn't sound quite like the dire situation you painted. ;-)

Scott Cranton
Nexaweb Technologies
www.nexaweb.com

All of the client-side presentation technologies--Java (AWT, Swing, SWT), Flash, DHTML, plug-ins, Avalon--have their strengths and weaknesses. As developers, we need to look at the hard facts, and at our requirements, and find the right match.

Right now we are talking specifically about client-side ubiquity (aka "zero install"), for which DHTML is the best you can do. But this is not important for many applications. Windows-only is sufficient for most. Java, Flash, and other plug-in installs are usually fine for intranet apps. A standard, ubiquitous client is really only required for extranet and Internet apps.

So, about those facts:

I'll grant you that Microsoft may have shipped 200+ million copies of Windows XP, *but* Windows XP does ship with the Microsoft JVM.

Actually, here is the reality:

Oct 25 2001 - Windows XP shipped with no JVM
Sep 9 2002 - Windows XP SP1 posted for download with the MSJVM
Feb 3 2003 - MSJVM is pulled from Windows XP SP1a (and all subsequent releases)

So a JVM was available for a 5-month window, in a downloadable service pack.

Thousands of independent sources on the web will confirm. Just Google "jvm in windows xp".

For the complete list of versions of Windows that ship out of the box with the MSJVM go to http://www.microsoft.com/mscorp/java/faq.asp towards the middle of the page it posts a list.

The brief service pack release qualifies XP for this list. At the bottom of that list see the note:

The MSJVM is not included with Windows XP SP1a, Windows XP SP2, Windows Server™ 2003, or any future Microsoft software.

Java was clearly killed on Windows. It will be reborn, based on recent Sun-OEM and Sun-MS agreement, but it will now co-exist with a more advanced Windows-only stack (using C#/CLR/Avalon). As far as Microsoft developers are concerned, the rebirth of Java on the client will be a non-event.

But is this a surprise? Of course Microsoft will dominate the client. Java dominates the server. This is TheServerSide, after all. :o)


Jeff Dill
Isomorphic Software
www.smartclient.com

Jeff,

Not sure where you were going with your post.

We seem to agree that:

- Java was and will be available on Windows (Mac, Linux, and UNIX) via the hardware or OS vendor

- Microsoft and Microsoft developers only care about Microsoft technologies (no surprise there)

I don't see anything wrong with letting the application developer choose the technolgy that is appropriate for their application. Java/non-Microsoft folk prefer Java; Microsoft shops prefer C#. Supporting both types of clients seems like a good thing. That's why Nexaweb made the design decision to support multiple client environments.

I certainly have no desire to get into religous debate about which technology is the best for any given medium; I leave that decision to the people developing the application.

Scott Cranton
Nexaweb Technologies
www.nexaweb.com

Why don't we look at it in this way.

If you have an employee that has not download Java long ago there is no idea to give him any application at all, because he will be too stupid to use it anyway! Better to get rid of him IMHO.

Regards
Rolf Tollerud
(Power users make the world go around.)

Jeff,

"So let's talk about the audience for J2EE applications, not games. Try a survey within corporate networks."

I am pretty sure that system administrators in corporations do not walk from PC to PC and downloads the JRE, but download only once and distribute locally. (allowed or not allowed).

"Yes, but nothing new. Altio and Canoo have had robust products doing this for many years. XWT is an OSS offering with an applet-based runtime. Thinlet, Bambookit, Asperon, eNode--all of these guys offer Java rich clients."
 
But none of these systems offers a competition to XAML. There is XUL/SVG that is the buzzword toujour.

But when Server-based pricing starts at $30,000 I am afraid that Nexaweb too has priced itself out of the market.

Regards
Rolf Tollerud

But when Server-based pricing starts at $30,000 I am afraid that Nexaweb too has priced itself out of the market.

For you, perhaps. But IMO, they offer more value than the typical app server did when it was selling for 30k/server.

Until these technologies become a commodity (like the app server has), their pricing will speak to the ROI. If you can save 30k in development/maintenance costs, or gain 30k in competitive advantage, it may make good sense. You have to take lock-in, training, and other platform risks & costs into account, of course.

I still want to know if you work for Microsoft. :)


Jeff Dill
Isomorphic Software
www.smartclient.com

<Yes, but nothing new. Altio and Canoo have had robust products doing this for many years. XWT is an OSS offering with an applet-based runtime. Thinlet, Bambookit, Asperon, eNode--all of these guys offer Java rich clients. None has achieved broad adoption, because of the client installation/administration barrier.

It has more to do with the limited vision of developers and management, and the belief that [all] web apps make development/deployment easy. With WebStart and Clickonce, the pendulum has swung the other way, all things considered.

Web Apps are not Zero install. Consider the number of IE patches required each month.

Web Apps are not Zero install. Consider the number of IE patches required each month.

Considered. No connection whatsoever. Those are general system security patches, not software you need to install to make your applications run.


Jeff

Web Apps are not Zero install. Consider the number of IE patches required each month.

Considered. No connection whatsoever. Those are general system security patches, not software you need to install to make your applications run.Jeff

If they prevent viruses and you run in the browser - they are. And they usually require a reboot. In reality, they are no different. Just peoples mind.

Linux hacked 6 times more often than Windows

http://www.zdnet.com.au/news/software/0,2000061733,39116229,00.htm
An analysis of hacker attacks on online servers in January by security consultancy mi2g found that Linux servers were the most frequently violated, accounting for 13,654 successful attacks, or 80 per cent of the survey total. Windows ran a distant second with 2,005 attacks. A more specific analysis of government servers also found Linux more susceptible, accounting for 57 per cent of all breaches.

Regards
Rolf Tollerud
(done any EJB's today?)

Security in all mainstream operating systems is non-existent; however, things are especially bad for Windows. Windows happens to be the favorite target of worm and virus writers. Conventional wisdom suggests that the huge installed base of Windows helps spread the worms and viruses, and also makes it a highly attractive target for worm/virus writers. The installed base of Windows certainly has an undeniable effect on the prevalence of malware on Windows, but this is not all there is to it.

Worms and viruses are so stunningly effective on Windows only because Windows provides some atrocious functionality which makes it easy for worms to strike. It might seem counterintuitive but Windows Registry, and a misdesigned Windows Update are the primary culprits that create a hospitable environment for worms and other malware.

A typical Windows system follows a simple lifecycle: it starts out with a clean Windows installation, which gradually deteriorates as programs are installed, and uninstalled. Eventually, the Windows registry accumulates so much crud that the user is forced to do a clean install. When a user does a clean install that user's system loses all the previously applied security updates, and becomes a sitting duck for worms and other malware.

Things wouldn't be so bad if the user was able to update the new system with security patches painlessly, but Windows Update makes it very hard to do so. My personal experience with the killer duo is an enlightening example of how all of this works.

read the rest : http://www.techuser.net/index.php?id=47


Microsoft executive on Linux, 64-bit computing

http://www.computerworld.com.au/index.php?id=606261041&fp=16&fpid=0

 Security in all mainstream operating systems is non-existent

Ever try breaking into RACF?

Linux hacked 6 times more often than Windows http://www.zdnet.com.au/news/software/0,2000061733,39116229,00.htmAn analysis of hacker attacks on online servers in January by security consultancy mi2g found that Linux servers were the most frequently violated, accounting for 13,654 successful attacks, or 80 per cent of the survey total. Windows ran a distant second with 2,005 attacks. A more specific analysis of government servers also found Linux more susceptible, accounting for 57 per cent of all breaches. RegardsRolf Tollerud(done any EJB's today?)

The point of my post was not security record of an OS, but that running in the browser does require installs/updates.

Why is it that people are willing to install AOL, games, CD of 1000 freeware programs and other sundry software but we can't get them to do click through installs (to include updating their OS)?

As a sided note, I wonder how fast people knew about the "violated" security and it was fixed? There is more there than meets the eye. As is typical with reports like this. "The half truth and nothing but the half truth. So help me ..."

The point of my post was not security record of an OS, but that running in the browser does require installs/updates.

Sorry Mark I was too trigger happy.

Why is it that people are willing to install AOL, games, CD of 1000 freeware programs and other sundry software but we can't get them to do click through installs (to include updating their OS)?

Yes. I constantly get calls from children; Why can I not chat in Lunarstorm. how do I install Java so I can play at blip.se! But these calls all comes from people less the 9 year old.. As soon as they are 9-10 the calls stop coming..sometimes I have to call them ;)

So in the future I can not see any problem with once and for all downloading, that is when the new generation grew up!

Regards
Rolf Tollerud

Granting that there is no such thing, technically, as "zero-install", carrying your argument further one also needs to install the OS as well ;-), is there any value in making the initial and subsequent deployment of an application easier (approaching the idealized zero-install)?

What would be a better term for what we've been calling "zero-install"?

Scott Cranton
Nexaweb Technologies

Granting that there is no such thing, technically, as "zero-install", carrying your argument further one also needs to install the OS as well ;-), is there any value in making the initial and subsequent deployment of an application easier (approaching the idealized zero-install)?What would be a better term for what we've been calling "zero-install"?Scott CrantonNexaweb Technologies

I think there is. Nothing is 100% (at least in computing) - I think you've said that - so to say "All Web apps" or "All Thick Clients" is ludicrous.

For those with broadband - installing the JRE and then using Web started applications is easy (excluding the occassional proxy/firewall/no-rights issue). If someone is one the "web" and doesn't have broadband - well get off because there is no way to keep Windows (or any other OS) up-to-date. They're just asking for trouble.

I agree that downloading the JRE is getting easier, more common and is only required once. And I appreciate the fact that Nexaweb are using XUL and SVG and not inventing standards of their own. But I miss the part where they are bringing Java to the desktop. They may able to use Java but we, application developers, are not.

HTML applications are "zero install" thin-client applications -- Both Java and .NET client applications have a heavy client-side footprint and require a significant download. In addition to solving the obvious network bandwidth issue, zero-install translates directly to significantly lower maintenance and support costs.

Once I read the heading I knew M$ paid hounds will be repling to this thread
M$ hound Rolf is surely here, please dont throws bones at him.

Microsoft's Jim Allchin once said that open source coders aren't innovative because they rely on proprietary products to clone from. For all the hype surrounding XAML, at its core it is similar to an open source technology that has been around for years: XUL from the Mozilla.

I have been reading this thread and other similar ones with a great deal of interest and am pleased to see so much active and constructive discussion on the pros and cons, benefits and approaches to delivering Rich Internet Applications. Having been working on a product in this space for the past nine years it is comforting to see that patience eventually pays off.

Much of the discussion has centred around the various technologies that are being employed to deliver a richer user experience. Coach Wei in his article does a good job of introducing some of the history, reasons and motivation behind RIA. I also enjoyed his earlier post on "Design decisions about Nexaweb" having been through similar thought processes myself. Jeff Dill has argued fairly on the benefits of using a DHTML approach rather than using Java on the client, and I would echo his comments about pricing, something which we too have spent a great deal of time considering.

When application servers were first available, there was much discussion about the need for such a piece of software. After all we could write our own thread management and database connection pooling algorithms and surely embedding them natively in a server side code would be much more efficient. We have learnt however that there are many advantages to using a dedicated platform for coordinating the various activities involved in managing the server side processing behind web applications. Today, virtually every web application of significant size runs on top of some form of application server whether it be on a .Net, J2EE or other platform. In essence, RIA is offering a similar platform or framework for managing and rendering the pixel-end of applications, delivering similar values of scalability, robustness and cross platform deployment.

Rather than add to the discussion on the pros and cons of an individual technology, though I am certainly passionate enough about this and have my own opinions on the merits of each solution, I thought it might be useful to illustrate a few examples of where we at Altio have deployed Rich Internet Applications. It is not intended as a sales pitch, though like Coach I must disclose a dedicated interest in my company. I wanted to give some idea of the maturity that RIA technology has reached over the past few years and offer inspiration to those considering adopting it for their own projects.

A number of global investment banks are building and deploying mission-critical risk management, realtime trading and analysis applications using RIA. These often involve the display of market data rate information at over 1000 updates each second, user interfaces displaying tens of thousands of rows of data that needs to be filtered and sorted instantly on demand and displayed in a rich variety of 2D and 3D charts. Initially considered for offering enhanced trading capabilities to their major customers over extranets, the technology has proven itself to be robust and scalable enough to replace hand coded C and C++ applications on the trader's desktop. As you might imagine, they require highly secure and reliable communications. In one of our applications that has been live for about a year hosted by a major financial exchange, an average single trade is worth well in excess of $100 million.

In order to compete effectively with traditional enterprise application technologies such as legacy client/server development tools, RIA must support applications that are considerably larger and more complicated than the average web page-based application. Over the past year we have worked on five applications that have in excess of 1000 screens, some of which need to run efficiently over a shared 64K ISDN connection and are deployed to between 2000 and 20,000 concurrent users accross LAN and WAN networks within a corporation. We have at least 4 applications that are being delivered to between 100,000 and 500,000 users, which may seem small numbers for a web site, but is large compared to most rich traditional client/server applications.

Another sign of the maturity of the technology is the robustness of the platform in daily use. Even as recently as three years ago, some well-known commercial application servers were 'less reliable' than might be desired for enterprise applications. We have a number of mission-critical applications that have been deployed for over two years in fault-tolerant server clusters with a better than 99.995% uptime (less than one hour in 2 years).

I believe there are valid arguments for each of the technologies employed to develop Rich Internet Applications, and am pleased to see that market demand for the technologies has increased dramatically over the past year thanks to the efforts of companies like Altio, Macromedia, Laszlo, Nexaweb, Isomorphic and many others including eventually Microsoft. Analysts estimate that by 2006, more than one third of all applications will be developed using RIA. There is a place for traditional web page-based applications, but even today the vast majority of enterprise applications are built or maintained using traditional tools and not deployed as web pages.

We are but at the tip of the iceberg of what is possible with RIA, and I would encourage extensive continued debate on the technologies employed. Most of all however, I would encourage you to try one or more of the RIA platforms and find out first-hand the benefits of being able to offer a richer and more delightful user experience for your applications.

David Levett
Founder and CTO, Altio
CTO, Integra SP
http://www.altio.com
Weblog: http://david.levett.net

There has just been a TSS discussion about Macromedia's Flex, in my mind Nexaweb raises the same issue, How about a vote for Java on the client?

Isn't there an OOS toolkit that does this same thing?

XUL or technologies like Nexaweb are a very good idea.
But the problem with them are the need a big JVM installed on the client (at least the implementations I know).
I think what we need is a XUL client written in some language like C (or C++, Delphi). This can be very light and easy to install (or not install at all, just one small file to download and run).

In jumping into this thread, I think it would be helpful to explain some of the rational I went through in making the technology decision I did for the Nexaweb product. Hopefully, I won't be too sales-y, though I do believe in the product ;-)

The original design center for the Nexaweb product was based on need for a managed client environment that wouldn't require an install, and would allow users to extend using standard programming languages. I should also mention that the Nexaweb client is also targeted at connected, occasionally connected, and offline clients (including mobile devices like Compaq iPAQ), with little to no change in the application code.

Initially (in 1999 and 2000) I started with DHTML. I was a really good DHTML developer (in 1999, I wrote a WORD Processor and Excel Spreadsheet using pure DHTML/Javascript, both look like MSOffice. I worked with DynAPI from its initial creation and there were a couple of other players like Desktop.com and WebOS.com who both used DHTML to create some kind of rich UI for web apps, both failed). When we built the first version of product, I realized scripting-language based enterprise applications are totally unmanageable from the code maintenance perspective and suffer from major performance issues---learned from hard lessons.

After then I seriously evaluated all client-side options: which technology is the right one to bet on? I chose Java as it is industry strength, but also pervasive on our target client platforms: Win 95 through Win XP, Linux, Mac, Solaris, and other UNIXes. Out of the box all of those platforms ship with a Web Browser (IE, Netscape, Mozilla, or Safari) and some sort of Java VM (Microsoft, SUN, or IBM). The Nexaweb client was designed to provide a uniform environment for the user, hiding all of the web browser and JVM differences. Looking back, Java both as a pervasive platform and as a standard, robust programming language for creating applications is really compelling.

To create an application, developers just need to use XML to create UI and write standard JavaBeans (we call them Managed Client Objects or MCO) for client-side logic. Nexaweb handles all of the issues with deploying MCOs, when needed, to the client. This way the user writes standard Java code, and their client-side logic, if needed, can be deployed on the vast majority of clients. The base Nexaweb client is about 150KB, which provides the initial environment for all our UI widgets, charts, SVG support, MCO runtime, as well as our reliable messaging infrastructure.

There is also a compatible .NET client as some of our users want much tighter desktop integration with Windows / .NET, and some users want to write MCOs in C# versus Java. It has nothing to do with our technology preferences, we've had great success with Java to date, its about providing what our customers are asking for.

At the risk of sounding too much like marketing... The reason we choose XML as our UI markup language was to explicitly allow us to support multiple client platform technologies like Java and .NET.


---Coach Wei
Nexaweb Technologies Inc.
www.nexaweb.com

Hi Coach,

"To create an application, developers just need to use XML to create UI and write standard JavaBeans (we call them Managed Client Objects or MCO) for client-side logic."

How does this product compare to Thinlet (www.thinlet.com) which is also XUL-based but open-source and free?

Clifford Cheng

Hi Coach,"To create an application, developers just need to use XML to create UI and write standard JavaBeans (we call them Managed Client Objects or MCO) for client-side logic."How does this product compare to Thinlet (www.thinlet.com) which is also XUL-based but open-source and free?Clifford Cheng

Hi Clifford:

There are various open source projects like thinlet. I personally find Thinlet quite interesting. It would be an unfair comparison between Nexaweb and Thinlet because they two have different design goals. High level speaking, Nexaweb is a distributed computing system that includes a server component, a client runtime and a reliable/bi-direction messaging layer. All of these three are required for enterprise scale computing. For example, how can you gaurantee your user's form submission actually get sent to the server? How do you gaurantee the order of message arrival? how do you handle hudrends of transactions per second over the wire? how do you handle a table with 8000 rows? what are the memory and performance impact of scaling up to complex non-linear workflow, large data set and so on? Nexaweb is designed to address such enterprise requirements. There is also a big programming model difference. Nexaweb is fairly centered around XML. Your application can be written using JSP/Servlet/XML without having a single line of Java code on the client side, if you like. Then there is a development tool difference. Nexaweb provides an eclipse-based visual development environment.

On the other side, there are also some similarities on the client side: NexawebClient and Thinlet are both fairly lightweight and small footprint; both are based on JDK1.1 and can run on most of the platforms and browsers in a zero-install fashion. etc.


---Coach Wei

To create an application, developers just need to use XML to create UI and write standard JavaBeans (we call them Managed Client Objects or MCO) for client-side logic. Nexaweb handles all of the issues with deploying MCOs, when needed, to the client. This way the user writes standard Java code, and their client-side logic, if needed, can be deployed on the vast majority of clients.

Thanks for that, so application developers really do get to put their Java onto the client!
Can you point to anymore information about what can be done this way? For example if the MCO is holding client state, presumably it persists through a number of pages - how is that specified? Can a page extract information from the MCO for the UI, eg filling in a list? Can an MCO manipulate the UI, and if so what model does the UI present? Is an MCO getter allowed to communicate across the web? Are MCOs restricted to being written in JDK 1.1 and if so will that change in the future?

<Thanks for that, so application developers really do get to put their Java onto the client! Can you point to anymore information about what can be done this way? For example if the MCO is holding client state, presumably it persists through a number of pages - how is that specified? Can a page extract information from the MCO for the UI, eg filling in a list? Can an MCO manipulate the UI, and if so what model does the UI present? Is an MCO getter allowed to communicate across the web? Are MCOs restricted to being written in JDK 1.1 and if so will that change in the future?

Great questions!

Since the Nexaweb UI is specified via XML, the natural model is DOM. Nexaweb exposes client side and server side access to the DOM for a given client session. The MCO has full access to that DOM, allowing it to interrogate and modify, as appropriate, for your application. The Server can, optionally, also maintain a copy of the client DOM allowing your server-side code (JSP/Servlet typically) to interogate and *modify* the client UI state without the application developer having to worry about bundling up data to be shipped back and forth.

Nexaweb provides client APIs (Services) that allow the MCO to make network requests, publish/subscribe to reliable messaging, access a client side data cache, etc.

MCO state is maintained as normal variables within your Java class. Nexaweb's client doesn't so much use a page metaphor as a session DOM; that client DOM is modified via interactions with the Server, the user via the XML UI, and MCOs. As long as that MCO reference exists in the client DOM, the MCO instance will exist, and hence the MCO instance variable data.

The XML markup can call MCO methods in response to UI events or through explicit calls.

Nexaweb doesn't require that MCOs be Java 1.1, its an application design decision. If the application needs to work as broadly as possible, you'd need to restrict the MCO to Java 1.1 so that it will run within the MSJVM (based on 1.1.4, I believe) shipped with Win 95. If you "know" you're clients are using JRE 1.4.2_04, then write the MCOs to that spec. Nexaweb harmonizes most of the version incompatibility by providing a consistent UI mechanism across the VM versions, which is arguable the hard bit.

For more information (shameless plug ;-) you can always go to www.nexaweb.com, where we have more information, and demos that you can run from your own browser.

Hope this helps,

Scott Cranton
Nexaweb Technologies
www.nexaweb.com

For more information (shameless plug ;-) you can always go to www.nexaweb.com, where we have more information, and demos that you can run from your own browser.

Can you be a bit more specific? I've scoured the web-site, checked out the demos, but I can find virtually nothing that discusses managed code running on the browser.

I don't want to turn this thread into a full-blown sales pitch for Nexaweb, so I'd suggest we take a deeper product conversation off-line.

The short answer is that the Java Nexaweb client will, on-demand, download MCOs (Java class files) as they are referenced within the client DOM. The Java MCO is just a plain old Java class, no implements or extends. This Java class will be hosted within the client-side VM with full access to the Nexaweb client APIs and the Java libraries available on that client. This MCO is constrained by the security policy of the container the Nexaweb client is hosted in (generally as an applet within the browser, but Nexaweb also has a standalone client for direct desktop deployment or on mobile devices).

The most obvious use case for MCOs is that of client-side field validation. Our customers have also used MCOs as client-side listeners for Nexaweb's reliable messaging infrastructure, allowing the client to handle server pushed events. MCOs have also been used to create highly specialized UI widgets.

Hope this helps,

Scott Cranton
Nexaweb Technologies
www.nexaweb.com

"When XML Client/Service (XCS) technology is combined with J2EE, J2EE gains the following benefits compared with .NET"

This has nothing to do with .Net. Read it instead as 'Our gui renderer uses a set of bespoke widgets to render a bespoke xml gui description, reducing the lines of code you need, but coupling you to us (the vendor) really tightly'. And vendor lock-in is why we all use Java, right?

Jonathan

IMHO, Java is not the important issue here. The important factor is the richness of the XML dialect you use to define the user interface. XForms seems to be a step ahead in this direction. It separates data from control logic and presentation. It can provide more powerful local processing capabilities than other XML dialects with no scripting. Since it is designed to be embedded in other markup language, it does not cover presentation.

We have developed a product for PDAs based on this standard (www.datamovil.info) but we developed our own presentation layer based on simplified CSS wit XML syntaxis (it is developed in Java-Personal Profile).

I think that the developers comunity has two problems with the web. It is not well-suited for enterprise transactional applications (it was never thought for that purpose) and the number of additions to the original idea has mad "web pages" unmaintainable. They are a mesh of scripting, data, logic and pressentation all mixed up. It is a crap from a software engineering point of view.

I think something new is needed, and having a universal client with a declarative language for the user interface definition, makes a lot of sense to me. At the end there should be a new "browser" for enterprise applications, I think SUN should have had realized this a long time ago.

Rafael Benito
SATEC, S.A.

I think something new is needed, and having a universal client with a declarative language for the user interface definition, makes a lot of sense to me. At the end there should be a new "browser" for enterprise applications, I think SUN should have had realized this a long time ago.Rafael BenitoSATEC, S.A.

Agreed. Why Sun stopped developing HotJava browser?