Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20694 > unrolled thread

Java servlet on browsers: dying or kicking ?

Back to article view | Back to comp.lang.java.programmer

Contents

  Java servlet on browsers: dying or kicking ? "SL@maxis" <noreply@my-rialto.com> - 2012-12-25 01:04 +0800
    Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-24 12:37 -0500
      Re: Java servlet on browsers: dying or kicking ? "SL@maxis" <ecp_gen@my-rialto.com> - 2012-12-25 04:32 +0800
        Re: Java servlet on browsers: dying or kicking ? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-12-26 23:20 -0800
          Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 21:05 -0500
          Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 21:07 -0500
            Re: Java servlet on browsers: dying or kicking ? Gene Wirchenko <genew@telus.net> - 2012-12-27 21:13 -0800
              Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 11:07 -0500
                Re: Java servlet on browsers: dying or kicking ? Gene Wirchenko <genew@telus.net> - 2012-12-28 09:14 -0800
                  Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 18:18 -0500
            Re: Java servlet on browsers: dying or kicking ? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-12-28 00:41 -0800
              Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 11:14 -0500
              Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-28 17:50 +0000
                Re: Java servlet on browsers: dying or kicking ? Robert Klemme <shortcutter@googlemail.com> - 2012-12-28 21:22 +0100
                  Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-28 21:08 +0000
                    Re: Java servlet on browsers: dying or kicking ? Robert Klemme <shortcutter@googlemail.com> - 2012-12-28 22:55 +0100
                    Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 18:02 -0500
                      Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-29 08:55 +0000
                        Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:40 -0500
                      Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-31 20:08 -0400
                        Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-31 19:33 -0500
                Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 17:51 -0500
                  Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-29 11:37 +0000
                    Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-29 11:39 +0000
                      Re: Java servlet on browsers: dying or kicking ? Gene Wirchenko <genew@telus.net> - 2012-12-29 22:22 -0800
                    Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:34 -0500
                  Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-29 08:22 -0400
                    Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-29 13:00 +0000
                      Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:54 -0500
                        Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-30 11:02 +0000
                          Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-30 20:33 -0500
                          Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-31 19:54 -0400
                    Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:43 -0500
                      Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-31 19:06 -0400
                        Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-31 19:29 -0500
                          Re: Java servlet on browsers: dying or kicking ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-01 01:46 +0000
                            Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-31 21:35 -0500
                          Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-01 09:22 -0400
                            Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-04 19:46 -0500
                        Re: Java servlet on browsers: dying or kicking ? "Richard Maher" <maher_rj@hotspamnotmail.com> - 2013-01-05 08:22 +0800
                          Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-04 19:59 -0500
                            Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-04 20:01 -0500
                            Re: Java servlet on browsers: dying or kicking ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-05 01:32 +0000
                          Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 10:27 +0000
                            Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-06 10:29 -0400
                              Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 16:29 +0000
                                Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-06 13:46 -0400
                                  Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 18:44 +0000
                                    Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:10 -0500
                                      Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 09:04 +0000
                                Re: Java servlet on browsers: dying or kicking ? Lew <lewbloch@gmail.com> - 2013-01-06 09:53 -0800
                                  Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 18:21 +0000
                                    Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:07 -0500
                                      Re: Java servlet on browsers: dying or kicking ? Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 21:18 -0500
                                        Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:28 -0500
                                          Re: Java servlet on browsers: dying or kicking ? Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 21:58 -0500
                                            Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 22:04 -0500
                                              Re: Java servlet on browsers: dying or kicking ? Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 22:10 -0500
                                                Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 08:34 +0000
                                      Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 08:25 +0000
                            Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 10:34 -0500
                              Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 16:46 +0000
                                Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:05 -0500
                              Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 17:10 +0000
                                Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-06 14:04 -0400
                                Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:03 -0500
                                  Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-07 07:01 -0400
                                  Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 11:11 +0000
                                  Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 14:25 +0000
                    Re: Java servlet on browsers: dying or kicking ? "Richard Maher" <maher_rj@hotspamnotmail.com> - 2013-01-05 08:05 +0800
    Re: Java servlet on browsers: dying or kicking ? Lew <lewbloch@gmail.com> - 2012-12-24 11:06 -0800
      Re: Java servlet on browsers: dying or kicking ? Robert Klemme <shortcutter@googlemail.com> - 2012-12-24 23:33 +0100
        Re: Java servlet on browsers: dying or kicking ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-24 18:15 -0500
          Re: Java servlet on browsers: dying or kicking ? Robert Klemme <shortcutter@googlemail.com> - 2012-12-25 10:43 +0100
        Re: Java servlet on browsers: dying or kicking ? Lew <lewbloch@gmail.com> - 2012-12-25 13:21 -0800
    Re: Java servlet on browsers: dying or kicking ? Roedy Green <see_website@mindprod.com.invalid> - 2013-01-01 12:29 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#20694 — Java servlet on browsers: dying or kicking ?

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

Is it a dying technology or still alive and kicking ?

Thanks.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

[toc] | [next] | [standalone]

#20695

On 12/24/2012 12:04 PM, SL@maxis wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#20697

On Tue, 25 Dec 2012 01:37:38 +0800, Arne Vajhøj <arne@vajhoej.dk> wrote:

>
> 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.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

[toc] | [prev] | [next] | [standalone]

#20718

In article <op.wpt8ogiewv4027@kiat-1>,
 "SL@maxis" <ecp_gen@my-rialto.com> wrote:

> On Tue, 25 Dec 2012 01:37:38 +0800, Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> >
> > 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.

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.
-- 
I will not see posts from Google because I must filter them as spam

[toc] | [prev] | [next] | [standalone]

#20738

On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
> In article <op.wpt8ogiewv4027@kiat-1>,
>   "SL@maxis" <ecp_gen@my-rialto.com> wrote:
>> 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 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

[toc] | [prev] | [next] | [standalone]

#20739

On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
> In article <op.wpt8ogiewv4027@kiat-1>,
>> 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.

Business logic should not be put in client side JS.

Client side JS can be manipulated by the user.

Arne

[toc] | [prev] | [next] | [standalone]

#20749

On Thu, 27 Dec 2012 21:07:02 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
>> In article <op.wpt8ogiewv4027@kiat-1>,
>>> 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.
>
>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

[toc] | [prev] | [next] | [standalone]

#20761

On 12/28/2012 12:13 AM, Gene Wirchenko wrote:
> On Thu, 27 Dec 2012 21:07:02 -0500, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>> On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
>>> In article <op.wpt8ogiewv4027@kiat-1>,
>>>> 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.
>>
>> Business logic should not be put in client side JS.
>
>       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.

>> Client side JS can be manipulated by the user.
>
>       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

[toc] | [prev] | [next] | [standalone]

#20766

On Fri, 28 Dec 2012 11:07:31 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

[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

[toc] | [prev] | [next] | [standalone]

#20784

On 12/28/2012 12:14 PM, Gene Wirchenko wrote:
> On Fri, 28 Dec 2012 11:07:31 -0500, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>
> [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.

It is generally accepted as a best practice, but I am sure
that it is still missing many places.

But unless server side is node.js or using a smart framework, then
it do means replicating code logic.

Regarding smart frameworks then ASP.NET MVC can generate both server
side and client side checks from same rules (annotations on data class)
and the same can certain JSF 2 implementations using JSR-303 annotations
(Richfaces is one such implementation).

Arne

[toc] | [prev] | [next] | [standalone]

#20751

In article <50dcfecc$0$292$14726298@news.sunsite.dk>,
 Arne Vajhøj <arne@vajhoej.dk> wrote:

> On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
> > In article <op.wpt8ogiewv4027@kiat-1>,
> >> 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.
> 
> 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.
-- 
I will not see posts from Google because I must filter them as spam

[toc] | [prev] | [next] | [standalone]

#20762

On 12/28/2012 3:41 AM, Kevin McMurtrie wrote:
> In article <50dcfecc$0$292$14726298@news.sunsite.dk>,
>   Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
>>> In article <op.wpt8ogiewv4027@kiat-1>,
>>>> 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.
>>
>> Business logic should not be put in client side JS.
>>
>> Client side JS can be manipulated by the user.
>
> 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

[toc] | [prev] | [next] | [standalone]

#20767

On 28/12/12 08:41, Kevin McMurtrie wrote:
> In article<50dcfecc$0$292$14726298@news.sunsite.dk>,
>   Arne Vajhøj<arne@vajhoej.dk>  wrote:
>
>> On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
>>> In article<op.wpt8ogiewv4027@kiat-1>,
>>>> 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.

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

Not sure how moving anything to the client will be of any interest to us 
in the future but never say never ... websockets look interesting however.

Client side business logic simply isn't an option AFAICS

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#20775

On 28.12.2012 18:50, lipska the kat wrote:

> 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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#20777

On 28/12/12 20:22, Robert Klemme wrote:
> On 28.12.2012 18:50, lipska the kat wrote:
>
>> 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.

> This sounds exactly like the use case JEE was intended for.

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

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

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.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#20781

On 28.12.2012 22:08, lipska the kat wrote:
> On 28/12/12 20:22, Robert Klemme wrote:
>> On 28.12.2012 18:50, lipska the kat wrote:
>>
>>> 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.
>
>> This sounds exactly like the use case JEE was intended for.
>
> 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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#20783

On 12/28/2012 4:08 PM, lipska the kat wrote:
> On 28/12/12 20:22, Robert Klemme wrote:
>> On 28.12.2012 18:50, lipska the kat wrote:
>>> 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.
>
>> This sounds exactly like the use case JEE was intended for.
>
> 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

[toc] | [prev] | [next] | [standalone]

#20791

On 28/12/12 23:02, Arne Vajhøj wrote:
> On 12/28/2012 4:08 PM, lipska the kat wrote:
>> On 28/12/12 20:22, Robert Klemme wrote:
>>> On 28.12.2012 18:50, lipska the kat wrote:
>>>> 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.
>>
>>> This sounds exactly like the use case JEE was intended for.
>>
>> 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.

Hmm, we are talking Weblogic version '3.something or other' here, around 
1998 I seem to remember. Eclipse didn't exist, we had IBMs Visual Age 
for Java but that was ... truly awful and it certainly didn't have the 
ability to generate EJB Deployment descriptors. These were the days when 
you had to implement Entity Bean primary keys by hand

> Or they could be generated by xdoclet.

Well the earliest reference I can find to xdoclet is 2002 so we probably 
didn't have that option. Anyway, I think most early adopters of EJB 
would agree that developing EJBs and keeping track of all the files 
involved was a frustrating experience.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#20808

On 12/29/2012 3:55 AM, lipska the kat wrote:
> On 28/12/12 23:02, Arne Vajhøj wrote:
>> On 12/28/2012 4:08 PM, lipska the kat wrote:
>>> On 28/12/12 20:22, Robert Klemme wrote:
>>>> On 28.12.2012 18:50, lipska the kat wrote:
>>>>> 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.
>>>
>>>> This sounds exactly like the use case JEE was intended for.
>>>
>>> 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.
>
> Hmm, we are talking Weblogic version '3.something or other' here, around
> 1998 I seem to remember. Eclipse didn't exist, we had IBMs Visual Age
> for Java but that was ... truly awful and it certainly didn't have the
> ability to generate EJB Deployment descriptors. These were the days when
> you had to implement Entity Bean primary keys by hand
>
>> Or they could be generated by xdoclet.
>
> Well the earliest reference I can find to xdoclet is 2002 so we probably
> didn't have that option.

XML deployment descriptors did not exist in WL 3.x.

They were added in EJB 1.1 released December 1999.

>                         Anyway, I think most early adopters of EJB
> would agree that developing EJBs and keeping track of all the files
> involved was a frustrating experience.

No - I don't think so.

All the ASP classic developers, PHP 4 developers and students
that spent a week looking at it probably found the descriptors
and interfaces very painful.

For those actually developing J2EE app back then it was an
insignificant part of the work.

Arne

[toc] | [prev] | [next] | [standalone]

#20838

On 12/28/2012 07:02 PM, Arne Vajhøj wrote:
> On 12/28/2012 4:08 PM, lipska the kat wrote:
>> On 28/12/12 20:22, Robert Klemme wrote:
>>> On 28.12.2012 18:50, lipska the kat wrote:
>>>> 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.
>>
>>> This sounds exactly like the use case JEE was intended for.
>>
>> 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.
[ SNIP ]

Not _hard_, no, but quite tedious. Hence error-prone. I seem to recall 
that back then (10+ years ago) I mostly used JBuilder - I have the vague 
memory that it wasn't *that* much fun to do EJBs. :-)

AHS

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web