Java servlet on browsers: dying or kicking ?

[SL@maxis]

What is the current state of java servlet support by major browsers ?

Is it a dying technology or still alive and kicking ?

Thanks.

 

[Arne Vajhøj]

What is the current state of java servlet support by major browsers ?

Is it a dying technology or still alive and kicking ?

Servlets is server side technology and therefore "supported"
by all browsers.

If you mean applets, then I believe that all modern
PC browsers support it, but that smartphone browsers
do not support it.

(applet support = Java plugin available)

Java applets are definitely not in fashion. RIA
are typical done with Flash/Flex or HTML/CSS/JS/AJAX
today.

Java applets are still used occasionally, because the
ability to sign them and give them client PC access are
useful/necessary in some contexts.

Some internet usage and a lot of intranet usage.

Arne

 

[Lew]

What is the current state of java [sic] servlet support by major browsers ?

No browser supports servlets.

Is it a dying technology or still alive and kicking ?

Very much still kicking.

 

[SL@maxis]

Servlets is server side technology and therefore "supported"
by all browsers.

If you mean applets, then I believe that all modern
PC browsers support it, but that smartphone browsers
do not support it.

(applet support = Java plugin available)

Java applets are definitely not in fashion. RIA
are typical done with Flash/Flex or HTML/CSS/JS/AJAX
today.

Java applets are still used occasionally, because the
ability to sign them and give them client PC access are
useful/necessary in some contexts.

Some internet usage and a lot of intranet usage.

Ha, my mistake; "servlet" should actually be "applet". Thanks for
correcting me.

 

[Robert Klemme]

SL@maxis wrote:

Very much still kicking.

Which one? Browsers, servlets or applets? ;-)

Cheers

robert

 

[Eric Sosman]

Which one? Browsers, servlets or applets? ;-)

Kicklets. They still have the ballslets to fight for
their rightslets, defending their nichelets against all
threatlets, patriotically emptying their wallets and spilling
their platelets.

Happy holidayslets to you.

 

[Robert Klemme]

Kicklets. They still have the ballslets to fight for
their rightslets, defending their nichelets against all
threatlets, patriotically emptying their wallets and spilling
their platelets.

Happy holidayslets to you.

Eric, thanks for making my day! *chuckle*

All the best

robert

 

[Lew]

Which one? Browsers, servlets or applets? ;-)

I took the antecedent to be servlets, I assume they already know the
answer to browsers, and since then I've seen that they actually meant
applets.

 

[Kevin McMurtrie]

Ha, my mistake; "servlet" should actually be "applet". Thanks for
correcting me.

Definitely in decline. HTML 5 + WebSockets can make fully interactive
applications that look and feel native. The improvements are so great
that the dreaded workflow and business logic tier can be moved from the
server side to the client side. Moving that tier to the client takes a
HUGE load off the server, making the server a pure number cruncher and
data service.

Some Servlet engines have WebSocket support built in. Jetty converts
the protocol upgrade request into a servlet call for a WebSocket
handler. Adding WebSocket support is not much different from adding a
new method handler to your servlet. Your WebSocket then sends and
receives messages to communicate with the client.

I still shudder when recalling my time writing applets. Sun's attempts
at making GUI APIs is the stuff nightmares are made of. It made me
nostalgic for C++ GUIs that abused polymorphism to extremes.

 

[Arne Vajhøj]

Definitely in decline. HTML 5 + WebSockets can make fully interactive
applications that look and feel native.

The decline is not caused by HTML 5 and websockets. It happen
many years before those showed up.

And there are still 40-50% of PC browsers that do not support
websockets (primarily IE < 10).

Arne

 

[Arne Vajhøj]

Definitely in decline. HTML 5 + WebSockets can make fully interactive
applications that look and feel native. The improvements are so great
that the dreaded workflow and business logic tier can be moved from the
server side to the client side. Moving that tier to the client takes a
HUGE load off the server, making the server a pure number cruncher and
data service.

Business logic should not be put in client side JS.

Client side JS can be manipulated by the user.

Arne

 

[Gene Wirchenko]

Business logic should not be put in client side JS.

I disagree. Client-side logic makes for quicker UI response.

Client side JS can be manipulated by the user.

But since this is also true, put the logic in the server side,
too.

Sincerely,

Gene Wirchenko

 

[Kevin McMurtrie]

Business logic should not be put in client side JS.

Client side JS can be manipulated by the user.

Arne

Some of the most difficult business logic is creating the workflow that
defines a smoothly operating online product. It's a complex process of
analyzing where you've been, what you chose to do, what data you have,
what operations are available, and then offering meaningful solutions to
reaching the next step. That used to be sprinkled all over the client
and server sides, making it difficult to maintain. Now much of that can
now go in the JavaScript layer.

Business logic related to security and data integrity remains on the
server. What's gone is the hand-holding steps to recovery when
integrity would be violated. Now it's just a 4xx status code.

 

[Arne Vajhøj]

I disagree. Client-side logic makes for quicker UI response.

I don't think there is much point in having business logic that is
not enforced.

And client side logic can not be enforced in a web solution.

But since this is also true, put the logic in the server side,
too.

I don't think there is much point in implementing all the business
logic twice - server side in Java and client side in JavaScript. That
would be an awfully waste of money.

But I think I know what you are thinking about. You are talking about
data input validation.

There are good reasons to do that both client side (for smooth UX) and
server side (for security).

But the overlap between data input validation and business logic
is pretty small. Most business logic is not data input validation.
And a big chunk of data input validation is really UI and not
business logic.

Arne

 

[Arne Vajhøj]

Some of the most difficult business logic is creating the workflow that
defines a smoothly operating online product. It's a complex process of
analyzing where you've been, what you chose to do, what data you have,
what operations are available, and then offering meaningful solutions to
reaching the next step. That used to be sprinkled all over the client
and server sides, making it difficult to maintain. Now much of that can
now go in the JavaScript layer.

Business logic related to security and data integrity remains on the
server. What's gone is the hand-holding steps to recovery when
integrity would be violated. Now it's just a 4xx status code.

It is certainly possible to move the flow logic (success go to
this page, error 1 go to another page, error 2 go to yet another
page - all the Struts 1 action-mappings !) to client side
JavaScript.

But I must admit that I do not consider that business logic.

IMHO that is pure UI. I consider heavy AJAX to move the UI layer
from server tier to client tier and replace it in server tier with
a service layer.

Arne

 

[Gene Wirchenko]

[snip]

I don't think there is much point in implementing all the business
logic twice - server side in Java and client side in JavaScript. That
would be an awfully waste of money.

But I think I know what you are thinking about. You are talking about
data input validation.
Exactly.

There are good reasons to do that both client side (for smooth UX) and
server side (for security).

Exactly my point.

But the overlap between data input validation and business logic
is pretty small. Most business logic is not data input validation.
And a big chunk of data input validation is really UI and not
business logic.

True. I am tired of Web pages that could catch entry errors, but
do not until I have finished a whole page. It seems that a lot of
people ignore putting any validation in the front-end. I would like
people to think of putting code in both places.

Sincerely,

Gene Wirchenko

 

[Robert Klemme]

I spend much of my working life translating a clients business processes
into something that can run on a computer and the trend is now more than
ever away from a strictly web based process and towards systems that are
completely independent of delivery mechanism.

So, where as a few years ago we had 'we gotta have a web site because
our competitors have a web site' now we have 'we need a system that can
implement our business and deliver our business value over multiple
communication channels'

So as well as a web site we often provide one or more of, a mobile
interface, a social media interface delivering targeted updates to the
likes of twitter, farcebook etc. an XML RSS feed, an interactive XML
based catalogue and recently a way of delivering business value via web
TV. We also provide interfaces to existing legacy systems and machine
interfaces to allow JIT supplier order fullfilment, shop floor intranet
access via hand held devices, POS systems etc etc. Only last week I was
asked about a 'Virtual Worlds' interface, Second Life and suchlike. I
had a second life account for a while but got so absorbed that I started
to neglect my earthly one :-(

I try to design our systems to be completely isolated from both
persistence mechanism and delivery mechanism

What I inevitably end up with is a slightly less that perfect decoupling
but I like to think that eventually, given the appearance of a truly
scalable way to persist entire Object trees I will be able to produce a
business system that will be completely decoupled from earthly
considerations like UI and database

This sounds exactly like the use case JEE was intended for. Your
business logic sits in session beans, your state is made persistent with
JPA whatever backend is used (mostly RDBMS though) and you can interface
to legacy systems with JCA. Transaction control across these layers is
available in most modern JEE containers. Most of them let you create a
web UI with JSF or other modern technologies. Usually you can also
expose session beans as Web Services as well with relatively low effort.
JASS handles authentication and can interface with various backends
(LDAP, AD...).

In practice of course this is pretty complicated and architecting such
an application and setting it up has quite some overhead. But if you
have it set up you have a nice separation of concerns.

Kind regards

robert

 

[Robert Klemme]

Well yes, I remember early days writing EJB deployment descriptors by
hand. What a hideous nightmare that was. An early, poorly documented
version of Weblogic and trying to figure out how everything was glued
together because the company couldn't afford the price of Weblogic
training. RMI over IIOP, stubs and skeletons, oh misery thy name is J2EE
... and don't get me started on the Sun One application stack

But you did notice that things have considerably changed in JEE world,
did you?

You know what, I don't actually use it much these days. I have a bunch
of classes that implement the core business logic. A facade hides the
atomic business logic methods from clients and people write to the
facade. Need more functionality ... no problem, update the facade by
combining atomic methods in new ways.

I rarely use web frameworks either, or persistence frameworks or any
other type of framework unless the client specifically requests it.
I still write most of my own SQL ... for the same reason I still write
stuff in assembler. It just seems like a good idea to stay close to the
machine/problem space

This sounds like a case of NIH syndrome. It may actually be that you'd
be better off with all the framework logic though. If things work well
for you the way they are then that's good.

Validation is done serverside, client side validation is a nice thing to
have but I would never rely on this, I would always back it up on the
server, after all, validation can be a fundamental part of your business
logic.

Absolutely.

Cheers

robert

 

[Arne Vajhøj]

What I inevitably end up with is a slightly less that perfect decoupling
but I like to think that eventually, given the appearance of a truly
scalable way to persist entire Object trees I will be able to produce a
business system that will be completely decoupled from earthly
considerations like UI and database

I thought a business logic layer by definition was separate
from UI layer and data access layer.



Arne

 

[Arne Vajhøj]

Well yes, I remember early days writing EJB deployment descriptors by
hand. What a hideous nightmare that was.

They could be generate by IDE's.

Or they could be generated by xdoclet.

And they were not that hard to write manually.

Today they can be replaced with annotations if one prefer those.

An early, poorly documented
version of Weblogic and trying to figure out how everything was glued
together because the company couldn't afford the price of Weblogic
training.

That id more the company's problem than the technology's
problem.

? RMI over IIOP, stubs and skeletons, oh misery thy name is J2EE

RMI over IIOP is no worse than other binary serialized protocols.

And stubs+skeletons is a standard solution for remote calls - EJB's
or web services or whatever.

Dynamically generated such do make life a little bit easier though.

You know what, I don't actually use it much these days. I have a bunch
of classes that implement the core business logic. A facade hides the
atomic business logic methods from clients and people write to the
facade. Need more functionality ... no problem, update the facade by
combining atomic methods in new ways.

I rarely use web frameworks either, or persistence frameworks or any
other type of framework unless the client specifically requests it.
I still write most of my own SQL ... for the same reason I still write
stuff in assembler. It just seems like a good idea to stay close to the
machine/problem space

Sounds pretty expensive to me not to utilize what other have
come up with.

DI frameworks, MVC web frameworks, ORM etc..

To quote Newton "If I have seen further it is by standing on the
shoulders of giants".

Arne