The Revenge of the Geeks

A

Arne Vajhøj

I didn't mean like CORBA or DCOM, but probably directly copying over
program binaries (DLLs or SOs and precompiled binaries and similar), and
probably using traditional compilation and linking.

You lost me.

How to get the same type of services as Java EE provides is related
to copying binaries how?
well, I meant for code and other resources.

or, to you mean putting code in the database as well?...

(like, put the JAR in a data-blob and fetch it out via a SELECT or
something?...).

No.

But as I said I am lost.

Arne
 
A

Arne Vajhøj

I have a web-server I am running on an old laptop, it uses Windows XP,
Apache, and also has PHP, MySQL, and MediaWiki...

If you decided that you preferred Java over PHP, then
you would replace PHP with a Java EE web container (Tomcat
would be obvious) and write your web app using Java EE
technologies like servlet, JSP and JSF.

Arne
 
L

Lew

BGB said:
I didn't mean like CORBA or DCOM, but probably directly copying over
program binaries (DLLs or SOs and precompiled binaries and similar), and
probably using traditional compilation and linking.

What does any of that have to do with Java EE, BGB?
well, I meant for code and other resources.

WTF?

That has nothing to do with Java EE or Java SE. Source code is kept in textfiles,
ideally managed through version control, regardless of which you're using.

Or are you talking about the binaries? The binaries are just Java classes.
or, to you mean putting code in the database as well?...
(like, put the JAR in a data-blob and fetch it out via a SELECT or
something?...).

Huh?

BGB, your posts show no evidence of any comprehension of what Java EE is ordoes,
none for knowledge of what Java EE-compliant products are out there, or thefact that
Java EE is just Java with some additional specifications that vendors implement.

I suggest you study up on those matters before pontificating about the subject.
 
B

BGB

You lost me.

How to get the same type of services as Java EE provides is related
to copying binaries how?

I may be missing something here...


because... it involves linking against and using libraries, correct?...


like "both languages have libraries, but maybe not the same libraries".

as in, for Java, you can copy around and use a JAR.
or in C or C++, you link against the DLL or SO, or use a static-library
(which then becomes a permanent part of the binary), ...

like, for Java there is LWOGL, and for C there is "opengl32.dll".
or, one person uses AWT or Swing, and another uses GDI+ or WinForms.


if you have some program and need to run it on a web-server, it can be
copied over into its "cgi-bin/" directory or similar, or set it to run
at start-up as a deamon (or a as a service on Windows, or launch it via
"start-up applications" or similar).


if end users run a program, they typically download it off the internet,
maybe as a ZIP, or maybe as a self-extracting "setup.exe" or similar.

any libraries would be contained inside, and copied over into the
relevant directories. any data files are typically copied along as well,
and the installer might put everything in its place.


and, if a person needs new libraries for a project they are developing,
they will go and download them off the internet, maybe recompile it from
source, ...


I actually have little idea how DCOM or CORBA fits into this, as they
are network protocols (like for doing RPC), but you don't generally need
a network protocol for using a library, just the library itself (IOW:
its compiled binary).

like, you might need something like these for accessing a web-service or
similar I guess. (like, Google does something like this, for its search
APIs and Google Earth and similar I think).


but, little idea what if-anything web-services have to do with using
libraries though.

admittedly, I don't personally have much experience dealing with RPC or
web-services though (and mostly use HTTP for file-delivery, well, and
for providing a website).



but, for most client/server apps I am familiar with are more like:
server runs somewhere (opening a listen port, for example, port 80 for
HTTP, ...);
user downloads and runs client;
client opens socket to connect to server (such as TCP or UDP);
then they share whatever data is relevant over the socket, using the
relevant protocol (often application-specific).

say, the protocol does structured message delivery, either using globs
of XML (like Jabber/XMPP or similar), or maybe some specialized binary
message format, and sometimes with a "multiplexer" to avoid clogging up
TCP sockets with large messages (by breaking large messages into smaller
pieces), ...

then each end sees the messages, and handles them as appropriate (or
reassembles the pieces, and handles complete messages when they arrive), ...

No.

But as I said I am lost.

I am confused as well...


the whole Java SE vs Java EE thing has taken a turn into the confusing...


the former makes sense, because that is what a person gets when they go
download and install the JDK or the JRE.

but the latter?... dunno. it sounds like something a bit different (not
just an alternate version of the JDK or JRE).
 
B

BGB

If you decided that you preferred Java over PHP, then
you would replace PHP with a Java EE web container (Tomcat
would be obvious) and write your web app using Java EE
technologies like servlet, JSP and JSF.

I use PHP mostly for sake of running MediaWiki, which is probably the
biggest/most complicated thing on the site.


my own CGI binaries have typically been written in C and compiled into
EXE's before being copied over to the server.

though, PHP does have the advantage that a person doesn't have to
recompile it after editing (though, there is the possibility that a web
request could come in with the PHP code in an inconsistent state, say
because someone was in the middle of editing the code directly on the
server or something...).


I had idly considered the possibility of using my own scripting language
here, but haven't seen much point.

like, C works well enough, and PHP works even if it does look a little
funky.


I had considered the remote possibility of a kind of "pay and register"
thing, which would probably work something like:
person clicks button, and does paypal thing;
it uses a target URL set to the user registration form;
after doing this, it probably gives them their user-key (basically, as a
glob of ciphered data), and records this into a file.

haven't done so yet, and am currently operating under a "donate if you
want to" system, but hardly anyone is making donations, so probably no
one would care enough to bother paying and registering either (they
would just be like "hay whatever" and not bother, or just warez it or
figure out a way to circumvent making a payment or similar via using
hacked URLs or something...).

so, I haven't done so yet...


granted, yes, either way I am not exactly making money here (rarely does
anyone donate anything, and in the off chance they do, it has been like
$0.05 and similar...).

making actually more money on YouTube, as theoretically at least, I have
$0.75 on this, from ads on videos, but meh, whatever sometimes...
 
B

BGB

What does any of that have to do with Java EE, BGB?


WTF?

That has nothing to do with Java EE or Java SE. Source code is kept in text files,
ideally managed through version control, regardless of which you're using.

Or are you talking about the binaries? The binaries are just Java classes.


Huh?

BGB, your posts show no evidence of any comprehension of what Java EE is or does,
none for knowledge of what Java EE-compliant products are out there, or the fact that
Java EE is just Java with some additional specifications that vendors implement.

I suggest you study up on those matters before pontificating about the subject.

I was not claiming here to have any idea what Java EE was, this much
should have been obvious enough...

just responding to what people have been writing, but it is confusing,
and the Wikipedia article doesn't really make it obvious either.



granted, I will not claim to have much familiarity with businesses or
enterprise systems either (not a business person, not really worked on
anything like this either, ...).

or, IOW: this is all in an area I have never gone into, much beyond what
was covered in college classes, when trying to study for a CompSci major
(and then getting screwed over by stupid math classes and moving...).
 
L

Lew

BGB said:
I may be missing something here...
because... it involves linking against and using libraries, correct?...

Not in the case of Java EE explicitly. You use libraries to write your Java code, sure,
just like in Java SE, but there's no link step.

But once you've written a Java EE app, you don't do anything resembling linking. You
upload the app to the application server, which deploys it for you.
like "both languages have libraries, but maybe not the same libraries".

You overemphasize the similarities and ignore the differences.
as in, for Java, you can copy around and use a JAR.

You can, but that's only the tip of the iceberg.
or in C or C++, you link against the DLL or SO, or use a static-library
(which then becomes a permanent part of the binary), ...

Whatever. This does not shed light on the use or value (or problems) of Java EE.
like, for Java there is LWOGL, and for C there is "opengl32.dll".

Nothing to do with this discussion.
or, one person uses AWT or Swing, and another uses GDI+ or WinForms.

Things are always cognate, but that doesn't make them the same.

All analogies share the characteristic that they break down if carried too far.
if you have some program and need to run it on a web-server, it can be
copied over into its "cgi-bin/" directory or similar, or set it to run
at start-up as a deamon (or a as a service on Windows, or launch it via
"start-up applications" or similar).

That's very different from how you administer a Java EE server.

Really, it's annoying that you don't research this first. Bye.
 
L

Lew

BGB said:
I was not claiming here to have any idea what Java EE was, this much
should have been obvious enough...

No, it was not obvious that you were disclaiming knowledge, though it was obvious that
you lacked it.

Most of the stuff you've been saying about Java EE is very far off the mark. You should read
about it.
just responding to what people have been writing, but it is confusing,
and the Wikipedia article doesn't really make it obvious either.

I have not heard of anyone being able to program Java from reading a Wikipedia article
about it.
granted, I will not claim to have much familiarity with businesses or
enterprise systems either (not a business person, not really worked on
anything like this either, ...).

That has nothing to do with being able to evaluate the technical aspects of the
specification.
or, IOW: this is all in an area I have never gone into, much beyond what
was covered in college classes, when trying to study for a CompSci major
(and then getting screwed over by stupid math classes and moving...).

Exactly. It is an area you have never gone into. I am suggesting that you remedy that.

College is irrelevant. "Stupid math classes" are irrelevant. None of that stopped you from
talking about Java EE without understanding. You can gain understanding with a modicum
of research. You need not blame your history, or your college professor, or past
grievances, nor be held back by them. You can determine your own future by doing the
freaking research and learning something of what you're passing judgment about.
 
B

BGB

WinZip is one of the worst. You really have to keep your wits about
you these days to avoiding installing junk. It is quite undignified of
a product like Java to stoop that low. I hate it when companies buy
out smaller companies. The products always deteriorate or disappear
entirely.

I would like to start pressuring everyone to put the name of the
product and version on any download button.

(satire)

but then how would the download sites make money, if they can't make
every banner be a giant green "Download" button, with the actual
download for the program being a little plain-text link somewhere near
the bottom of the page somewhere?...
 
A

Arne Vajhøj

I may be missing something here...

because... it involves linking against and using libraries, correct?...

like "both languages have libraries, but maybe not the same libraries".

as in, for Java, you can copy around and use a JAR.
or in C or C++, you link against the DLL or SO, or use a static-library
(which then becomes a permanent part of the binary), ...

like, for Java there is LWOGL, and for C there is "opengl32.dll".
or, one person uses AWT or Swing, and another uses GDI+ or WinForms.

if you have some program and need to run it on a web-server, it can be
copied over into its "cgi-bin/" directory or similar, or set it to run
at start-up as a deamon (or a as a service on Windows, or launch it via
"start-up applications" or similar).

if end users run a program, they typically download it off the internet,
maybe as a ZIP, or maybe as a self-extracting "setup.exe" or similar.

any libraries would be contained inside, and copied over into the
relevant directories. any data files are typically copied along as well,
and the installer might put everything in its place.

and, if a person needs new libraries for a project they are developing,
they will go and download them off the internet, maybe recompile it from
source, ...

You copy jar files in Java EE just like you do in Java SE.

The difference is in what the libraries do. Not how they are
distributed.
I actually have little idea how DCOM or CORBA fits into this, as they
are network protocols (like for doing RPC),

They are not.

CORBA is a component model that uses IIOP as network protocol.

DCOM is a component model that uses ncacn_tcp as network protocol.
but, for most client/server apps I am familiar with are more like:
server runs somewhere (opening a listen port, for example, port 80 for
HTTP, ...);
user downloads and runs client;
client opens socket to connect to server (such as TCP or UDP);
then they share whatever data is relevant over the socket, using the
relevant protocol (often application-specific).

say, the protocol does structured message delivery, either using globs
of XML (like Jabber/XMPP or similar), or maybe some specialized binary
message format, and sometimes with a "multiplexer" to avoid clogging up
TCP sockets with large messages (by breaking large messages into smaller
pieces), ...

then each end sees the messages, and handles them as appropriate (or
reassembles the pieces, and handles complete messages when they arrive),
...

Let me give you a very simple example.

You want to allow browsers to connect to your code and be
told what the time is.

You could write that in Java SE. You listen on port 80, accept
a connection, start a thread that parse the request and outout
the response.

With Java EE you could write now.jsp:

<%=new Date()%>

and Java EE would handle sockets, threads, reading and writing for
you.

The JSP get compiled to Java that get compiled to byte code that
get JIT compiled.
I am confused as well...

the whole Java SE vs Java EE thing has taken a turn into the confusing...

the former makes sense, because that is what a person gets when they go
download and install the JDK or the JRE.

but the latter?... dunno. it sounds like something a bit different (not
just an alternate version of the JDK or JRE).

Correct.

Let us say that the Java SE model is:
- you write some classes and build them with JDK
- you start the JVM with a main method in one of your classes
- your main code calls some code

The Java EE model is:
- you start the JVM with the Java EE app server
- you write some classes and build them with JDK
- you deploy your classes (no main method) to the server
- the server calls your code

In Java SE terms you can consider the Java EE server to be the
program and your Java EE application to be a plugin to the
server.

Arne
 
A

Arne Vajhøj

I use PHP mostly for sake of running MediaWiki, which is probably the
biggest/most complicated thing on the site.

You could use Java for the same purpose:

http://en.wikipedia.org/wiki/JAMWiki
my own CGI binaries have typically been written in C and compiled into
EXE's before being copied over to the server.

Servlets that are the part of Java EE which is pure Java code that
get executed by HTTP requests.

But inlike CGI scripts they get loaded once and kept in memory
and run in threads not in separate processes.

Arne
 
B

BGB

You copy jar files in Java EE just like you do in Java SE.

The difference is in what the libraries do. Not how they are
distributed.

yes, ok.

They are not.

CORBA is a component model that uses IIOP as network protocol.

DCOM is a component model that uses ncacn_tcp as network protocol.

fair enough...

I haven't really used either of them personally, FWIW.

I will assume then that they are probably for inter-operation with other
servers or similar?

(though I guess client/server communication was mentioned earlier, like
the end-user clients could call back to the server).



FWIW: I once messed briefly with XML-RPC, but never really did much with
it since then, although long ago, parts of its design were scavenged and
repurposed for other things (compiler ASTs).


my own network protocol designs had typically revolved around (typically
asynchronous and unidirectional) message passing (basically, both ends
throwing messages at each other over a socket).

usually, these weren't based on HTTP or similar, but typically special
dedicated sockets.

for example, my game protocol currently uses TCP/18512, and is based on
compressed S-Expressions.


like:
(sound 594 "sound/monsters/enemyhead/idle1" ...)
would match against the tag 'sound', and then invoke the appropriate
handling logic (which looks up entity 594, tells the mixer to start
playing the sound-effect in question, which is connected to the entity,
....).

Let me give you a very simple example.

You want to allow browsers to connect to your code and be
told what the time is.

You could write that in Java SE. You listen on port 80, accept
a connection, start a thread that parse the request and outout
the response.

With Java EE you could write now.jsp:

<%=new Date()%>

and Java EE would handle sockets, threads, reading and writing for
you.

The JSP get compiled to Java that get compiled to byte code that
get JIT compiled.

ok, so it does something sort of like a web-server then, but with Java
taking the role of PHP or similar?

I guess maybe that has to do with the whole "application server" thing,
which was another part I didn't really understand what it was doing
exactly...

Correct.

Let us say that the Java SE model is:
- you write some classes and build them with JDK
- you start the JVM with a main method in one of your classes
- your main code calls some code

The Java EE model is:
- you start the JVM with the Java EE app server
- you write some classes and build them with JDK
- you deploy your classes (no main method) to the server
- the server calls your code

In Java SE terms you can consider the Java EE server to be the
program and your Java EE application to be a plugin to the
server.

ok.

this much makes sense at least.
 
B

BGB

You could use Java for the same purpose:

http://en.wikipedia.org/wiki/JAMWiki

interesting...


MediaWiki is cool as well, and works well enough, though I ended up
ultimately disabling the ability of people to create new user-accounts
mostly as a spam-control measure (bots kept coming along and flooding
the wiki with spam).


I had once considered the idea using a variant of MediaWiki syntax as
part of a stand-alone documentation system (sort of like a mix of
MediaWiki, Windows Help, and Javadoc), but never really got around to it.

the main idea though would be to do it as a single self-contained tool,
in contrast to something like MediaWiki which has a list of dependencies
needed to make it work (like MySQL and PHP and similar, and assumes
using a web-server + browser, ...).

but, as noted, I never got to it, and don't currently have any concrete
plans for doing so.

most of my documentation thus far is either as plain text files, or
sometimes as HTML documents.

Servlets that are the part of Java EE which is pure Java code that
get executed by HTTP requests.

But inlike CGI scripts they get loaded once and kept in memory
and run in threads not in separate processes.

yep, could improve performance some I guess.
 
A

Arved Sandstrom

yes, ok.



fair enough...

I haven't really used either of them personally, FWIW.

I will assume then that they are probably for inter-operation with other
servers or similar?
[ SNIP ]

Both CORBA and DCOM are meant for distributed applications. Like Arne
said, both have to do with software components on numerous different
machines, possibly different languages, and having defined interfaces
for RPC. Myself I wouldn't even use the term "server" to explain what
DCOM and CORBA do, not at a high level.
but, for most client/server apps I am familiar with are more like:
server runs somewhere (opening a listen port, for example, port 80 for
HTTP, ...);
user downloads and runs client;
client opens socket to connect to server (such as TCP or UDP);
then they share whatever data is relevant over the socket, using the
relevant protocol (often application-specific).
[ SNIP ]

Let me give you a very simple example.

You want to allow browsers to connect to your code and be
told what the time is.

You could write that in Java SE. You listen on port 80, accept
a connection, start a thread that parse the request and outout
the response.

With Java EE you could write now.jsp:

<%=new Date()%>

and Java EE would handle sockets, threads, reading and writing for
you.

The JSP get compiled to Java that get compiled to byte code that
get JIT compiled.

ok, so it does something sort of like a web-server then, but with Java
taking the role of PHP or similar?

I guess maybe that has to do with the whole "application server" thing,
which was another part I didn't really understand what it was doing
exactly...
[ SNIP ]

Don't make the mistake of thinking that Java EE == web application.
Although I expect that a lot of Java coders who write only web apps in
the Java EE space may get to thinking that way.

Your typical Java EE enterprise app running on top of a Java EE
application server may or may not have a web tier. Just like servers
written in other languages on other platforms may often also have
nothing whatsoever to do with HTTP and HTML and web browsers.

But I suppose if you look at the numbers of Java EE app deployments,
I'll speculate that the very large majority are web apps or at least
incorporate one.

Since you mentioned PHP, and Arne mentioned JSP, you're aware that you
might run a PHP app on Apache with mod_php. Think of that latter as
being your app server. Similarly, if you want to run an ASP.NET MVC app,
you might set up an IIS website for it - IIS is your app server. In the
case of Java EE web apps using JSP as a view technology (with or without
JSF in the picture) then a Java EE server is your application/web server.

AHS
 
A

Arved Sandstrom

I may be missing something here...
[ SNIP ]

Step back for a moment. We are talking servers and their clients. On the
server side you start out with a vanilla install on a physical box or
VM: might be Apache httpd or IIS, might be Tomcat or WebLogic, might be
ActiveMQ or WebSphere MQ, might be Active Directory or OpenLDAP, might
be H2 or DB2 or Oracle or SQL Server...you get the idea.

The server install sets up directories, executables (services or tools),
libraries (DLLs, *.so's, Java JARs etc), baseline config information,
and so forth. At this stage of the game you may or may not have a
useable, albeit uninteresting, server. Further configuration is often
required to make it useable (e.g. the directory servers).

After all this it's probably still uninteresting. You need to write
server applications, and you need to develop clients (often, not
always). For a web server or app server you write your ASP.NET MVC or
Java EE or PHP apps. Those apps will use libraries that came with the
baseline server, but you may use other libraries that are either shared
on the server or bundled up/deployed with the specific server app.

In some cases the actual server that you write your own server
applications on is *itself* a server application sitting on a server.
For example, ECM systems like FileNet P8 or Alfresco are actually
humongo web apps (more or less) on app servers like Tomcat or WebSphere
(plus using database servers and maybe directory servers) that you can
the drop your own apps onto. IBM Cognos is itself a Java EE app.

On the client side, if it's a web app you've got a browser; there's not
anything left to do. But possibly your server application is providing
SOAP or REST web services - in that case you will be writing client
code. If CORBA, you're generating and writing client code. If WebSphere
MQ you're often writing client code.

These clients also need libraries, whether JARs or native shared/static
libraries. Frequently there are client installers that supply all of this.

You do not generally copy things in the manner you describe. Server
installs can be pretty complicated - if you need a new server on a new
box then you work through the approved install process...just like you'd
do with an .EXE or .MSI installer for a standalone app on Windows.

In fact, with few exceptions, *removing* a server and all its artifacts
can be pretty complicated and tedious too.

As to deployment of server and client apps, these often have a
deployable form. In Java EE these are JARs or WARs or EARs. Other
systems (ESBs, BPM systems, certain forms of IIS app deployment etc)
often have a publishing/deployment procedure that involves ZIPs of
directory/file structures. The IDE that you develop in, more often than
not, already knows how to create the proper deployment packages.

As for Java SE versus Java EE, the latter is the former plus reams of
extra libraries. The latter also encompasses the contracts for anyone
who is going to provide a Java EE-compliant application server.

AHS
 
A

Arne Vajhøj

fair enough...

I haven't really used either of them personally, FWIW.

I will assume then that they are probably for inter-operation with other
servers or similar?

(though I guess client/server communication was mentioned earlier, like
the end-user clients could call back to the server).

They are really fir inter-operation between components,

But it will typical be some application on a server that host those
components.
FWIW: I once messed briefly with XML-RPC, but never really did much with
it since then, although long ago, parts of its design were scavenged and
repurposed for other things (compiler ASTs).

XML-RPC never really took off. Instead we got SOAP.
ok, so it does something sort of like a web-server then, but with Java
taking the role of PHP or similar?

I guess maybe that has to do with the whole "application server" thing,
which was another part I didn't really understand what it was doing
exactly...

A full Java EE server comes with a web container and an EJB container.

Tomcat etc. only comes with web container.

The web container part of Java EE is for writing web applications
and web services in Java EE similar to PHP and ASP.NET.

The EJB container part does not speak HTTP(S). Instead
it uses binary calls over sockets, message queues and
allows for custom TCP and UDP traffic (via JCA).
ok.

this much makes sense at least.

The concept is sometimes call the Hollywood
Principle.

Arne
 
B

BGB

yes, ok.



fair enough...

I haven't really used either of them personally, FWIW.

I will assume then that they are probably for inter-operation with other
servers or similar?
[ SNIP ]

Both CORBA and DCOM are meant for distributed applications. Like Arne
said, both have to do with software components on numerous different
machines, possibly different languages, and having defined interfaces
for RPC. Myself I wouldn't even use the term "server" to explain what
DCOM and CORBA do, not at a high level.

if it is on a different machine, and is providing something for being
accessed over a network, wouldn't that machine be by definition a server?

but, for most client/server apps I am familiar with are more like:
server runs somewhere (opening a listen port, for example, port 80 for
HTTP, ...);
user downloads and runs client;
client opens socket to connect to server (such as TCP or UDP);
then they share whatever data is relevant over the socket, using the
relevant protocol (often application-specific).
[ SNIP ]

Let me give you a very simple example.

You want to allow browsers to connect to your code and be
told what the time is.

You could write that in Java SE. You listen on port 80, accept
a connection, start a thread that parse the request and outout
the response.

With Java EE you could write now.jsp:

<%=new Date()%>

and Java EE would handle sockets, threads, reading and writing for
you.

The JSP get compiled to Java that get compiled to byte code that
get JIT compiled.

ok, so it does something sort of like a web-server then, but with Java
taking the role of PHP or similar?

I guess maybe that has to do with the whole "application server" thing,
which was another part I didn't really understand what it was doing
exactly...
[ SNIP ]

Don't make the mistake of thinking that Java EE == web application.
Although I expect that a lot of Java coders who write only web apps in
the Java EE space may get to thinking that way.

Your typical Java EE enterprise app running on top of a Java EE
application server may or may not have a web tier. Just like servers
written in other languages on other platforms may often also have
nothing whatsoever to do with HTTP and HTML and web browsers.

But I suppose if you look at the numbers of Java EE app deployments,
I'll speculate that the very large majority are web apps or at least
incorporate one.

ok, but all this is still a bit outside my area.

Since you mentioned PHP, and Arne mentioned JSP, you're aware that you
might run a PHP app on Apache with mod_php. Think of that latter as
being your app server. Similarly, if you want to run an ASP.NET MVC app,
you might set up an IIS website for it - IIS is your app server. In the
case of Java EE web apps using JSP as a view technology (with or without
JSF in the picture) then a Java EE server is your application/web server.

I think I may have enabled mod_php, partly as IIRC the MediaWiki
installation instructions said to do something like this (along with
which things to install, ...).


I have not personally messed with IIS or ASP.NET.

the vast majority of code I have written in C# has been either small
tools (command-line or sometimes with a GUI), or Paint.NET plugins.
 
B

BGB

I may be missing something here...
[ SNIP ]

Step back for a moment. We are talking servers and their clients. On the
server side you start out with a vanilla install on a physical box or
VM: might be Apache httpd or IIS, might be Tomcat or WebLogic, might be
ActiveMQ or WebSphere MQ, might be Active Directory or OpenLDAP, might
be H2 or DB2 or Oracle or SQL Server...you get the idea.

The server install sets up directories, executables (services or tools),
libraries (DLLs, *.so's, Java JARs etc), baseline config information,
and so forth. At this stage of the game you may or may not have a
useable, albeit uninteresting, server. Further configuration is often
required to make it useable (e.g. the directory servers).

After all this it's probably still uninteresting. You need to write
server applications, and you need to develop clients (often, not
always). For a web server or app server you write your ASP.NET MVC or
Java EE or PHP apps. Those apps will use libraries that came with the
baseline server, but you may use other libraries that are either shared
on the server or bundled up/deployed with the specific server app.

In some cases the actual server that you write your own server
applications on is *itself* a server application sitting on a server.
For example, ECM systems like FileNet P8 or Alfresco are actually
humongo web apps (more or less) on app servers like Tomcat or WebSphere
(plus using database servers and maybe directory servers) that you can
the drop your own apps onto. IBM Cognos is itself a Java EE app.

On the client side, if it's a web app you've got a browser; there's not
anything left to do. But possibly your server application is providing
SOAP or REST web services - in that case you will be writing client
code. If CORBA, you're generating and writing client code. If WebSphere
MQ you're often writing client code.

These clients also need libraries, whether JARs or native shared/static
libraries. Frequently there are client installers that supply all of this.

You do not generally copy things in the manner you describe. Server
installs can be pretty complicated - if you need a new server on a new
box then you work through the approved install process...just like you'd
do with an .EXE or .MSI installer for a standalone app on Windows.

In fact, with few exceptions, *removing* a server and all its artifacts
can be pretty complicated and tedious too.

As to deployment of server and client apps, these often have a
deployable form. In Java EE these are JARs or WARs or EARs. Other
systems (ESBs, BPM systems, certain forms of IIS app deployment etc)
often have a publishing/deployment procedure that involves ZIPs of
directory/file structures. The IDE that you develop in, more often than
not, already knows how to create the proper deployment packages.

As for Java SE versus Java EE, the latter is the former plus reams of
extra libraries. The latter also encompasses the contracts for anyone
who is going to provide a Java EE-compliant application server.

....

well, ok, I run a web-server mostly running Apache.

apart from MediaWiki, most of the content thus far is static pages and
files.


so, not really some huge/complicated web-app thing, nor does it interact
with any other servers (it contents are pretty much all self-contained,
....).


I had generally imagined web-servers mostly like they were file-servers,
but with the plus-side of having a defined browser-level interface, and
the ability to use scripts or binaries to generate contents.

for a client-side app (probably a traditional desktop-style
application), it would use an HTTP server mostly like a file-server for
retrieving updated resources and similar. a CGI script could mostly
exist to provide a manifest and so the client app can know if/what files
to download.

dunno about an app working in a browser, I haven't personally really
looked much into this. the one thing I had noted which I felt might make
this worthwhile was "Google Native Client", but given it is Chrome-only
at this point, this is a drawback (better if Firefox supported it, but
the FF people apparently oppose it).

Adobe Flash sometimes seemed like a possible option, but isn't
particularly compelling, and the development environment apparently
costs money.


but, generally, I more prefer the desktop application experience...
 
B

BGB

They are really fir inter-operation between components,

But it will typical be some application on a server that host those
components.

ok.



XML-RPC never really took off. Instead we got SOAP.

I don't really like SOAP...


IMHO, it seems wasteful and probably like a dedicated protocol could
probably be more efficient in most cases.

not that high-level code should see (or need to care about) the raw
bytes going over the socket, but avoiding being overly wasteful does
seem like an advantage.

the usual strategy I had used is that high-level messages are seen
basically as structured data (list-structured data, or "tuples"), with
the protocol code basically being responsible for bundling them up,
serializing them (into a binary form), and sending them on their way.


admittedly, some of my views regarding high-level network programming
may have also been influenced some by (limited) exposure to Erlang.
(though, granted, a lot of my stuff works differently from Erlang...).

A full Java EE server comes with a web container and an EJB container.

Tomcat etc. only comes with web container.

The web container part of Java EE is for writing web applications
and web services in Java EE similar to PHP and ASP.NET.

The EJB container part does not speak HTTP(S). Instead
it uses binary calls over sockets, message queues and
allows for custom TCP and UDP traffic (via JCA).

yes, ok.


in my case, though not exactly the same, it is possible to have custom
messages composed by, and processed by, script code.

I don't generally use RPC, nor send code over the network protocol,
mostly as it seemed like too much of a security risk at present (though
technically, both could be done without much effort).


some of my older stuff did directly send executable code over sockets,
but I now generally consider this to be bad practice, and some other
things which could potentially send code include automatic filters to
try to prevent any script fragments from being sent (many of these sorts
of messages will be discarded).

this may change if/when general security improves (mostly so that script
code can be adequately sand-boxed).

note: it doesn't block all code from being sent, rather specific
black-listed cases, like sending globs of code over the network via
console commands, ... mostly as these cases more likely represent
nefarious uses than actually valid use-cases (valid code probably isn't
going to be sent via a big "stufftext" message).

The concept is sometimes call the Hollywood
Principle.

not really familiar with this.


looking it up.

actually, in a general sense, this sounds like how a lot of how my stuff
works internally.

direct top-down structuring usually gets overly complicated and really
doesn't scale well in general.
 
L

Lew

BGB said:
I had generally imagined web-servers mostly like they were file-servers,
but with the plus-side of having a defined browser-level interface, and
the ability to use scripts or binaries to generate contents.

Terminology varies, but by widely-accepted convention a web server specifically
handles browser-like interactions using (mostly) HTML over HTTP. An application
server, as others explained upthread, serves all kinds of services in service of
applications designed to run in that environment. It might, and often does, incorporate
a web server as part of the panoply of services provided. But the concept you must
grasp is that application servers, such as those that implement Java EE, are kitchen-sink
propositions, giving all kinds of help to applications from an "enterprise" (read "project",
"organization", or professionally cognate term) perspective.

You can play reductionist mind games all you want, I mean, really, isn't all "just" machine
code in the end? Playing that type of game utterly misses the point and to reply in such
terms is inappropriate. The point of any framework, or computer language, or toolkit, is
to educe a closer mapping between the ontology of the enterprise (in its literal English meaning)
and the ontology of the model you're building. To sit disingenuously in the wrong ontology
serves neither your education nor contributes to the common weal.

But you've been around this newsgroup a long, long time and by now you really should have
found out some of this for yourself. Java EE is well documented and the tools are free and open
source. So if you really had any genuine desire to understand the concepts and goals of the
specifications, you'd've done so already.

Java EE is like a high-level language, but for deployment and connection of services. It's one of
those things that separates mere programmers from people who can solve problems with software
systems. Its goals are deployability, scalability, ops-friendliness, orchestration-ability (sorry :)),
stability, and pragmatic leverage for useful software systems. It encompasses a broad range of tools,
such as message queues, persistent storage, server clustering, resource management, orchestration,
troubleshooting, and more.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top