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
-
Sun Published "XML Client/Service and Java Take On .NET" (47 messages)
- Posted by: Arthur Hekin
- Posted on: May 14 2004 18:37 EDT
Threaded Messages (47)
- Sun Published "XML Client/Service and Java Take On .NET" by Horia Muntean on May 17 2004 10:24 EDT
- Zero-Install? by Zhaohua Meng on May 17 2004 12:04 EDT
-
Zero-Install? by Mark N on May 17 2004 12:06 EDT
- Zero-Install? by Fred Bloggs on May 17 2004 12:31 EDT
-
Only 150K download by Rolf Tollerud on May 17 2004 12:33 EDT
-
Only 150K download by Tero Vaananen on May 17 2004 12:51 EDT
- Microsoft grants "ethernal life" to applets by Rolf Tollerud on May 17 2004 01:10 EDT
- Java isn't preinstalled on windows by jim woods on July 09 2006 02:28 EDT
-
Java is not zero-install by Jeff Dill on May 17 2004 02:34 EDT
-
look elsewhere for squirmy excuses by Rolf Tollerud on May 17 2004 03:36 EDT
-
look elsewhere for squirmy excuses by Jeff Dill on May 17 2004 05:00 EDT
-
JRE pervasive by Ethan Allen on May 17 2004 05:55 EDT
-
JRE pervasive by Jeff Dill on May 17 2004 06:57 EDT
-
Premature notice on the death of Java on Windows... by Scott Cranton on May 18 2004 10:04 EDT
-
Premature notice on the death of Java on Windows... by Jeff Dill on May 18 2004 01:36 EDT
- Premature notice on the death of Java on Windows... by Scott Cranton on May 18 2004 02:28 EDT
- hard to find qualified staff nowadays? by Rolf Tollerud on May 18 2004 02:32 EDT
-
Premature notice on the death of Java on Windows... by Jeff Dill on May 18 2004 01:36 EDT
-
Premature notice on the death of Java on Windows... by Scott Cranton on May 18 2004 10:04 EDT
-
JRE pervasive by Jeff Dill on May 17 2004 06:57 EDT
-
Nexaweb & Macromedia is too greedy by Rolf Tollerud on May 17 2004 06:25 EDT
- Nexaweb & Macromedia is too greedy -- not really by Jeff Dill on May 17 2004 08:10 EDT
-
look elsewhere for squirmy excuses by Mark N on May 18 2004 08:03 EDT
-
HTML apps are zero install by Jeff Dill on May 18 2004 11:51 EDT
-
HTML apps are zero install by Mark N on May 18 2004 05:36 EDT
-
just to refresh your memory by Rolf Tollerud on May 18 2004 06:02 EDT
-
http://www.techuser.net/index.php?id=47 by Jamie Schiner on May 18 2004 11:30 EDT
- Oldy but Goody by Mark N on May 19 2004 08:13 EDT
-
just to refresh your memory by Mark N on May 19 2004 08:11 EDT
- grow up people are morons by Rolf Tollerud on May 19 2004 09:07 EDT
-
http://www.techuser.net/index.php?id=47 by Jamie Schiner on May 18 2004 11:30 EDT
-
HTML apps are zero install by Scott Cranton on May 19 2004 08:35 EDT
- HTML apps are zero install by Mark N on May 19 2004 11:49 EDT
-
just to refresh your memory by Rolf Tollerud on May 18 2004 06:02 EDT
-
HTML apps are zero install by Mark N on May 18 2004 05:36 EDT
-
HTML apps are zero install by Jeff Dill on May 18 2004 11:51 EDT
-
JRE pervasive by Ethan Allen on May 17 2004 05:55 EDT
- look elsewhere for squirmy excuses by adrian cuthbert on May 17 2004 05:27 EDT
-
look elsewhere for squirmy excuses by Jeff Dill on May 17 2004 05:00 EDT
-
look elsewhere for squirmy excuses by Rolf Tollerud on May 17 2004 03:36 EDT
-
Only 150K download by Tero Vaananen on May 17 2004 12:51 EDT
- Re: Zero-Install? by Ronald Tetsuo Miura on May 17 2004 12:23 EDT
-
Zero-Install? by Mark N on May 17 2004 12:06 EDT
- I knew it by Jamie Schiner on May 17 2004 21:27 EDT
- Microsoft "They're cloners." Mozilla/Macromedia: "So are you." by Robert Dean on May 18 2004 18:03 EDT
- Examples of RIA in the Real World by David Levett on May 21 2004 03:50 EDT
- Zero-Install? by Zhaohua Meng on May 17 2004 12:04 EDT
- How about a vote for Java on the client? by adrian cuthbert on May 17 2004 12:32 EDT
- Sun Published "XML Client/Service and Java Take On .NET" by Mark N on May 17 2004 15:01 EDT
- Native (not java) XUL implementation by Danilo Rheinheimer on May 17 2004 18:16 EDT
- Design decisions about Nexaweb by Coach Wei on May 17 2004 21:03 EDT
- Design decisions about Nexaweb by Clifford Cheng on May 17 2004 23:31 EDT
- Re: Comparison with Thinlet by Coach Wei on May 18 2004 11:22 EDT
- Design decisions about Nexaweb by adrian cuthbert on May 18 2004 03:32 EDT
-
Design decisions about Nexaweb by Scott Cranton on May 18 2004 10:57 EDT
-
Design decisions about Nexaweb by adrian cuthbert on May 18 2004 02:52 EDT
- Design decisions about Nexaweb by Scott Cranton on May 18 2004 03:47 EDT
-
Design decisions about Nexaweb by adrian cuthbert on May 18 2004 02:52 EDT
-
Design decisions about Nexaweb by Scott Cranton on May 18 2004 10:57 EDT
- Design decisions about Nexaweb by Clifford Cheng on May 17 2004 23:31 EDT
- Nothing to do with .Net by Jonathan Gibbons on May 18 2004 03:35 EDT
- XForms may also play a role by Rafael Benito on May 18 2004 09:14 EDT
- What happend to HotJava browser? by Zhaohua Meng on May 18 2004 10:35 EDT
-
Sun Published "XML Client/Service and Java Take On .NET"[ Go to top ]
- Posted by: Horia Muntean
- Posted on: May 17 2004 10:24 EDT
- in response to Arthur Hekin
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 -
Zero-Install?[ Go to top ]
- Posted by: Zhaohua Meng
- Posted on: May 17 2004 12:04 EDT
- in response to Horia Muntean
Are you sure all browsers include java by default? Otherwise it's not zero-install. -
Zero-Install?[ Go to top ]
- Posted by: Mark N
- Posted on: May 17 2004 12:06 EDT
- in response to Zhaohua Meng
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. -
Zero-Install?[ Go to top ]
- Posted by: Fred Bloggs
- Posted on: May 17 2004 12:31 EDT
- in response to Mark N
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). -
Only 150K download[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: May 17 2004 12:33 EDT
- in response to Mark N
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 -
Only 150K download[ Go to top ]
- Posted by: Tero Vaananen
- Posted on: May 17 2004 12:51 EDT
- in response to Rolf Tollerud
What percentage of all computers runs .NET? -
Microsoft grants "ethernal life" to applets[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: May 17 2004 13:10 EDT
- in response to Tero Vaananen
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 -
Java isn't preinstalled on windows[ Go to top ]
- Posted by: jim woods
- Posted on: July 09 2006 02:28 EDT
- in response to Tero Vaananen
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 -
Java is not zero-install[ Go to top ]
- Posted by: Jeff Dill
- Posted on: May 17 2004 14:34 EDT
- in response to Rolf Tollerud
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 -
look elsewhere for squirmy excuses[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: May 17 2004 15:36 EDT
- in response to Jeff Dill
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 -
look elsewhere for squirmy excuses[ Go to top ]
- Posted by: Jeff Dill
- Posted on: May 17 2004 17:00 EDT
- in response to 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 -
JRE pervasive[ Go to top ]
- Posted by: Ethan Allen
- Posted on: May 17 2004 17:55 EDT
- in response to Jeff Dill
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. -
JRE pervasive[ Go to top ]
- Posted by: Jeff Dill
- Posted on: May 17 2004 18:57 EDT
- in response to Ethan Allen
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 -
Premature notice on the death of Java on Windows...[ Go to top ]
- Posted by: Scott Cranton
- Posted on: May 18 2004 10:04 EDT
- in response to Jeff Dill
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 -
Premature notice on the death of Java on Windows...[ Go to top ]
- Posted by: Jeff Dill
- Posted on: May 18 2004 13:36 EDT
- in response to Scott Cranton
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 -
Premature notice on the death of Java on Windows...[ Go to top ]
- Posted by: Scott Cranton
- Posted on: May 18 2004 14:28 EDT
- in response to Jeff Dill
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 -
hard to find qualified staff nowadays?[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: May 18 2004 14:32 EDT
- in response to Jeff Dill
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.) -
Nexaweb & Macromedia is too greedy[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: May 17 2004 18:25 EDT
- in response to Jeff Dill
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 -
Nexaweb & Macromedia is too greedy -- not really[ Go to top ]
- Posted by: Jeff Dill
- Posted on: May 17 2004 20:10 EDT
- in response to 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 -
look elsewhere for squirmy excuses[ Go to top ]
- Posted by: Mark N
- Posted on: May 18 2004 08:03 EDT
- in response to Jeff Dill
<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. -
HTML apps are zero install[ Go to top ]
- Posted by: Jeff Dill
- Posted on: May 18 2004 11:51 EDT
- in response to Mark N
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 -
HTML apps are zero install[ Go to top ]
- Posted by: Mark N
- Posted on: May 18 2004 17:36 EDT
- in response to Jeff Dill
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.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 -
just to refresh your memory[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: May 18 2004 18:02 EDT
- in response to Mark N
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?) -
http://www.techuser.net/index.php?id=47[ Go to top ]
- Posted by: Jamie Schiner
- Posted on: May 18 2004 23:30 EDT
- in response to Rolf Tollerud
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 -
Oldy but Goody[ Go to top ]
- Posted by: Mark N
- Posted on: May 19 2004 08:13 EDT
- in response to Jamie Schiner
Security in all mainstream operating systems is non-existent
Ever try breaking into RACF? -
just to refresh your memory[ Go to top ]
- Posted by: Mark N
- Posted on: May 19 2004 08:11 EDT
- in response to Rolf Tollerud
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 ..." -
grow up people are morons[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: May 19 2004 09:07 EDT
- in response to Mark N
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 -
HTML apps are zero install[ Go to top ]
- Posted by: Scott Cranton
- Posted on: May 19 2004 08:35 EDT
- in response to Mark N
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 -
HTML apps are zero install[ Go to top ]
- Posted by: Mark N
- Posted on: May 19 2004 11:49 EDT
- in response to Scott Cranton
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. -
look elsewhere for squirmy excuses[ Go to top ]
- Posted by: adrian cuthbert
- Posted on: May 17 2004 17:27 EDT
- in response to Rolf Tollerud
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. -
Re: Zero-Install?[ Go to top ]
- Posted by: Ronald Tetsuo Miura
- Posted on: May 17 2004 12:23 EDT
- in response to Zhaohua Meng
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.
-
I knew it[ Go to top ]
- Posted by: Jamie Schiner
- Posted on: May 17 2004 21:27 EDT
- in response to Horia Muntean
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 "They're cloners." Mozilla/Macromedia: "So are you."[ Go to top ]
- Posted by: Robert Dean
- Posted on: May 18 2004 18:03 EDT
- in response to Horia Muntean
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. -
Examples of RIA in the Real World[ Go to top ]
- Posted by: David Levett
- Posted on: May 21 2004 03:50 EDT
- in response to Horia Muntean
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 -
How about a vote for Java on the client?[ Go to top ]
- Posted by: adrian cuthbert
- Posted on: May 17 2004 12:32 EDT
- in response to Arthur Hekin
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? -
Sun Published "XML Client/Service and Java Take On .NET"[ Go to top ]
- Posted by: Mark N
- Posted on: May 17 2004 15:01 EDT
- in response to Arthur Hekin
Isn't there an OOS toolkit that does this same thing? -
Native (not java) XUL implementation[ Go to top ]
- Posted by: Danilo Rheinheimer
- Posted on: May 17 2004 18:16 EDT
- in response to Arthur Hekin
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). -
Design decisions about Nexaweb[ Go to top ]
- Posted by: Coach Wei
- Posted on: May 17 2004 21:03 EDT
- in response to Arthur Hekin
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 -
Design decisions about Nexaweb[ Go to top ]
- Posted by: Clifford Cheng
- Posted on: May 17 2004 23:31 EDT
- in response to Coach Wei
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 -
Re: Comparison with Thinlet[ Go to top ]
- Posted by: Coach Wei
- Posted on: May 18 2004 11:22 EDT
- in response to 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 -
Design decisions about Nexaweb[ Go to top ]
- Posted by: adrian cuthbert
- Posted on: May 18 2004 03:32 EDT
- in response to 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? -
Design decisions about Nexaweb[ Go to top ]
- Posted by: Scott Cranton
- Posted on: May 18 2004 10:57 EDT
- in response to adrian cuthbert
<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 -
Design decisions about Nexaweb[ Go to top ]
- Posted by: adrian cuthbert
- Posted on: May 18 2004 14:52 EDT
- in response to Scott Cranton
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. -
Design decisions about Nexaweb[ Go to top ]
- Posted by: Scott Cranton
- Posted on: May 18 2004 15:47 EDT
- in response to adrian cuthbert
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 -
Nothing to do with .Net[ Go to top ]
- Posted by: Jonathan Gibbons
- Posted on: May 18 2004 03:35 EDT
- in response to Arthur Hekin
"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 -
XForms may also play a role[ Go to top ]
- Posted by: Rafael Benito
- Posted on: May 18 2004 09:14 EDT
- in response to Arthur Hekin
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. -
What happend to HotJava browser?[ Go to top ]
- Posted by: Zhaohua Meng
- Posted on: May 18 2004 10:35 EDT
- in response to Rafael Benito
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?