Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #21601 > unrolled thread
| Started by | Ramon F Herrera <ramon@conexus.net> |
|---|---|
| First post | 2013-01-22 06:41 -0800 |
| Last post | 2013-01-27 23:33 -0800 |
| Articles | 20 on this page of 106 — 15 participants |
Back to article view | Back to comp.lang.java.programmer
The Revenge of the Geeks Ramon F Herrera <ramon@conexus.net> - 2013-01-22 06:41 -0800
Re: The Revenge of the Geeks Melzzzzz <mel@zzzzz.com> - 2013-01-22 14:55 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:29 -0500
Re: The Revenge of the Geeks Ramon F Herrera <ramon@conexus.net> - 2013-01-22 06:58 -0800
Re: The Revenge of the Geeks joel garry <joel-garry@home.com> - 2013-01-22 08:54 -0800
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-23 00:07 +0000
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-22 17:02 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:23 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-22 21:30 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:26 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 00:51 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:01 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 01:10 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:20 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 12:15 +0000
Re: The Revenge of the Geeks "Ezekiel" <zeke@nosuchemail.com> - 2013-01-24 07:37 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-24 12:55 +0000
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 14:40 +0000
Re: The Revenge of the Geeks "Ezekiel" <zeke@nosuchemail.com> - 2013-01-24 10:01 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:24 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:35 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:56 -0500
Re: The Revenge of the Geeks Stuart <DerTopper@web.de> - 2013-01-30 23:54 +0100
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:32 -0500
Re: The Revenge of the Geeks Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-22 21:33 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 00:21 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-23 05:25 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 04:35 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:17 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 22:47 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 06:03 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 04:44 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 11:10 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-24 10:49 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 11:06 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 16:10 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:30 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 17:44 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:49 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:58 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 21:10 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 22:15 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 22:31 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 23:57 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-25 22:05 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 23:31 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 07:25 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 12:40 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 21:34 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:06 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 09:12 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 14:47 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 16:23 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 15:24 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 21:47 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:11 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 22:54 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-27 07:46 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 12:47 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:40 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 21:16 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-29 22:05 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-30 03:22 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-30 20:12 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-31 02:22 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-02-01 20:12 -0500
Re: The Revenge of the Geeks Gene Wirchenko <genew@telus.net> - 2013-02-04 14:09 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:28 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-02-05 01:57 -0600
Re: The Revenge of the Geeks Gene Wirchenko <genew@telus.net> - 2013-02-05 09:55 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:37 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-27 10:38 +0000
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 13:09 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:47 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:45 -0500
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 07:26 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 13:22 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-26 12:57 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 16:15 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:04 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 00:38 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:35 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 21:04 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 16:34 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 17:04 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:14 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 01:38 -0600
Re: The Revenge of the Geeks Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-27 13:13 +0000
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 13:59 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 22:17 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 23:06 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-25 22:10 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 00:31 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 19:42 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 23:22 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-25 00:03 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 02:41 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 19:31 -0400
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 11:30 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:13 -0500
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 15:31 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 14:37 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:09 -0500
Re: The Revenge of the Geeks Roedy Green <see_website@mindprod.com.invalid> - 2013-01-24 04:30 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 02:45 -0600
Re: The Revenge of the Geeks Roedy Green <see_website@mindprod.com.invalid> - 2013-01-27 23:33 -0800
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-24 21:10 -0600 |
| Message-ID | <kdst63$eq8$1@news.albasani.net> |
| In reply to | #21674 |
On 1/24/2013 4:58 PM, Arne Vajhøj wrote: > On 1/24/2013 5:10 PM, BGB wrote: >> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>> On 1/23/2013 11:47 PM, BGB wrote: >>>> but, in any case, with the other languages there are a wide range of >>>> libraries available, many under fairly open licenses (like MIT or BSD), >>>> and there is a lot more GPL stuff available, >>> >>> In the EE space you would need to look at CORBA or DCOM. >>> >>> You would prefer Java EE believe me. >>> >>> :-) >>> >> >> errm, so you can't just copy all the files over to ones' servers? and/or >> recompile the code for ones' servers?... > > The coding model in Java EE is definitely more modern than that > of CORBA and DCOM. > 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. or if you mean like network communication?... >> granted, dunno much about business systems, but I was under the >> understanding that most were some combination of: >> >> rack mounts running Linux, typically with x86 CPUs, and with Gigabit >> Ethernet or 10GbE or similar linking them all together. >> >> one or more server computers in a desktop-like form factor, sometimes >> with multi-CPU boards, Xeon or Opteron chips, and craploads of RAM >> installed, and sometimes also in a LAN. AFAIK, Linux is also popular >> here. (though I guess Windows XP, Windows Vista, and Windows Server, >> also make an appearance). >> >> something more strange, like IBM mainframes or similar, where everyone >> uses them via funky multi colored textual interfaces inside of a >> terminal emulator, ... pretty much everything I have read about them >> sounds strange. > > Java EE run on servers for production usage. > > But all types of OS and hardware. > > Linux is the most popular OS, but Windows, various Unix and > mainframe are still seen. > fair enough. >> as for data sharing (between lots of networked servers), I am less sure, >> I would think maybe something like NFS or SAMBA, but then thinking of >> it, NFS or Samba might not scale well if the number of servers becomes >> sufficiently large (like, people would probably want to locally cache >> files, rather than always doing IO over the network, ...). > > Persistent data in the the Java EE world is most often in database. > 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?...). >> otherwise, not entirely sure why developing for these would be all that >> much different than dealing with a normal PC or Linux box. > > It is not the type of box that makes a difference. > > You can run a Java EE app server on your laptop. > > You laptop does just not have the IO system and the 24x7 > reliability to run in most production contexts. > > The difference in development is the services provided by the > server that the application can utilize if the application follows > the rules. > I have a web-server I am running on an old laptop, it uses Windows XP, Apache, and also has PHP, MySQL, and MediaWiki... > Arne > >
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-24 22:15 -0500 |
| Message-ID | <5101f8d3$0$293$14726298@news.sunsite.dk> |
| In reply to | #21686 |
On 1/24/2013 10:10 PM, BGB wrote: > On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >> On 1/24/2013 5:10 PM, BGB wrote: >>> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>>> On 1/23/2013 11:47 PM, BGB wrote: >>>>> but, in any case, with the other languages there are a wide range of >>>>> libraries available, many under fairly open licenses (like MIT or >>>>> BSD), >>>>> and there is a lot more GPL stuff available, >>>> >>>> In the EE space you would need to look at CORBA or DCOM. >>>> >>>> You would prefer Java EE believe me. >>>> >>>> :-) >>>> >>> >>> errm, so you can't just copy all the files over to ones' servers? and/or >>> recompile the code for ones' servers?... >> >> The coding model in Java EE is definitely more modern than that >> of CORBA and DCOM. >> > > 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? >>> as for data sharing (between lots of networked servers), I am less sure, >>> I would think maybe something like NFS or SAMBA, but then thinking of >>> it, NFS or Samba might not scale well if the number of servers becomes >>> sufficiently large (like, people would probably want to locally cache >>> files, rather than always doing IO over the network, ...). >> >> Persistent data in the the Java EE world is most often in database. >> > > 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
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-24 22:31 -0600 |
| Message-ID | <kdt1t7$m7e$1@news.albasani.net> |
| In reply to | #21687 |
On 1/24/2013 9:15 PM, Arne Vajhøj wrote: > On 1/24/2013 10:10 PM, BGB wrote: >> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>> On 1/24/2013 5:10 PM, BGB wrote: >>>> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>>>> On 1/23/2013 11:47 PM, BGB wrote: >>>>>> but, in any case, with the other languages there are a wide range of >>>>>> libraries available, many under fairly open licenses (like MIT or >>>>>> BSD), >>>>>> and there is a lot more GPL stuff available, >>>>> >>>>> In the EE space you would need to look at CORBA or DCOM. >>>>> >>>>> You would prefer Java EE believe me. >>>>> >>>>> :-) >>>>> >>>> >>>> errm, so you can't just copy all the files over to ones' servers? >>>> and/or >>>> recompile the code for ones' servers?... >>> >>> The coding model in Java EE is definitely more modern than that >>> of CORBA and DCOM. >>> >> >> 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? > 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), ... >>>> as for data sharing (between lots of networked servers), I am less >>>> sure, >>>> I would think maybe something like NFS or SAMBA, but then thinking of >>>> it, NFS or Samba might not scale well if the number of servers becomes >>>> sufficiently large (like, people would probably want to locally cache >>>> files, rather than always doing IO over the network, ...). >>> >>> Persistent data in the the Java EE world is most often in database. >>> >> >> 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. > 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). > Arne >
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-01-24 23:57 -0800 |
| Message-ID | <6d5b6a8a-b95e-48da-a734-0d8105f455bf@googlegroups.com> |
| In reply to | #21692 |
BGB wrote: > 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. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-25 22:05 -0500 |
| Message-ID | <5103480d$0$284$14726298@news.sunsite.dk> |
| In reply to | #21692 |
On 1/24/2013 11:31 PM, BGB wrote: > On 1/24/2013 9:15 PM, Arne Vajhøj wrote: >> On 1/24/2013 10:10 PM, BGB wrote: >>> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>>> On 1/24/2013 5:10 PM, BGB wrote: >>>>> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>>>>> On 1/23/2013 11:47 PM, BGB wrote: >>>>>>> but, in any case, with the other languages there are a wide range of >>>>>>> libraries available, many under fairly open licenses (like MIT or >>>>>>> BSD), >>>>>>> and there is a lot more GPL stuff available, >>>>>> >>>>>> In the EE space you would need to look at CORBA or DCOM. >>>>>> >>>>>> You would prefer Java EE believe me. >>>>>> >>>>>> :-) >>>>>> >>>>> >>>>> errm, so you can't just copy all the files over to ones' servers? >>>>> and/or >>>>> recompile the code for ones' servers?... >>>> >>>> The coding model in Java EE is definitely more modern than that >>>> of CORBA and DCOM. >>>> >>> >>> 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? > > 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. >>>>> as for data sharing (between lots of networked servers), I am less >>>>> sure, >>>>> I would think maybe something like NFS or SAMBA, but then thinking of >>>>> it, NFS or Samba might not scale well if the number of servers becomes >>>>> sufficiently large (like, people would probably want to locally cache >>>>> files, rather than always doing IO over the network, ...). >>>> >>>> Persistent data in the the Java EE world is most often in database. >>>> >>> >>> 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. >> > > 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
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-25 23:31 -0600 |
| Message-ID | <kdvppm$80q$1@news.albasani.net> |
| In reply to | #21718 |
On 1/25/2013 9:05 PM, Arne Vajhøj wrote: > On 1/24/2013 11:31 PM, BGB wrote: >> On 1/24/2013 9:15 PM, Arne Vajhøj wrote: >>> On 1/24/2013 10:10 PM, BGB wrote: >>>> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>>>> On 1/24/2013 5:10 PM, BGB wrote: >>>>>> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>>>>>> On 1/23/2013 11:47 PM, BGB wrote: >>>>>>>> but, in any case, with the other languages there are a wide >>>>>>>> range of >>>>>>>> libraries available, many under fairly open licenses (like MIT or >>>>>>>> BSD), >>>>>>>> and there is a lot more GPL stuff available, >>>>>>> >>>>>>> In the EE space you would need to look at CORBA or DCOM. >>>>>>> >>>>>>> You would prefer Java EE believe me. >>>>>>> >>>>>>> :-) >>>>>>> >>>>>> >>>>>> errm, so you can't just copy all the files over to ones' servers? >>>>>> and/or >>>>>> recompile the code for ones' servers?... >>>>> >>>>> The coding model in Java EE is definitely more modern than that >>>>> of CORBA and DCOM. >>>>> >>>> >>>> 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? >> >> 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. > yes, ok. >> 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. > 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, ...). >> 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. > 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... >>>>>> as for data sharing (between lots of networked servers), I am less >>>>>> sure, >>>>>> I would think maybe something like NFS or SAMBA, but then thinking of >>>>>> it, NFS or Samba might not scale well if the number of servers >>>>>> becomes >>>>>> sufficiently large (like, people would probably want to locally cache >>>>>> files, rather than always doing IO over the network, ...). >>>>> >>>>> Persistent data in the the Java EE world is most often in database. >>>>> >>>> >>>> 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. >>> >> >> 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. > ok. this much makes sense at least.
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-01-26 07:25 -0400 |
| Message-ID | <23PMs.86405$sm1.44698@newsfe22.iad> |
| In reply to | #21721 |
On 01/26/2013 01:31 AM, BGB wrote: > On 1/25/2013 9:05 PM, Arne Vajhøj wrote: >> On 1/24/2013 11:31 PM, BGB wrote: >>> On 1/24/2013 9:15 PM, Arne Vajhøj wrote: >>>> On 1/24/2013 10:10 PM, BGB wrote: >>>>> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>>>>> On 1/24/2013 5:10 PM, BGB wrote: >>>>>>> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>>>>>>> On 1/23/2013 11:47 PM, BGB wrote: >>>>>>>>> but, in any case, with the other languages there are a wide >>>>>>>>> range of >>>>>>>>> libraries available, many under fairly open licenses (like MIT or >>>>>>>>> BSD), >>>>>>>>> and there is a lot more GPL stuff available, >>>>>>>> >>>>>>>> In the EE space you would need to look at CORBA or DCOM. >>>>>>>> >>>>>>>> You would prefer Java EE believe me. >>>>>>>> >>>>>>>> :-) >>>>>>>> >>>>>>> >>>>>>> errm, so you can't just copy all the files over to ones' servers? >>>>>>> and/or >>>>>>> recompile the code for ones' servers?... >>>>>> >>>>>> The coding model in Java EE is definitely more modern than that >>>>>> of CORBA and DCOM. >>>>>> >>>>> >>>>> 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? >>> >>> 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. >> > > yes, ok. > > >>> 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. >> > > 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
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-26 12:40 -0600 |
| Message-ID | <ke1811$g4n$1@news.albasani.net> |
| In reply to | #21732 |
On 1/26/2013 5:25 AM, Arved Sandstrom wrote: > On 01/26/2013 01:31 AM, BGB wrote: >> On 1/25/2013 9:05 PM, Arne Vajhøj wrote: >>> On 1/24/2013 11:31 PM, BGB wrote: >>>> On 1/24/2013 9:15 PM, Arne Vajhøj wrote: >>>>> On 1/24/2013 10:10 PM, BGB wrote: >>>>>> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>>>>>> On 1/24/2013 5:10 PM, BGB wrote: >>>>>>>> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>>>>>>>> On 1/23/2013 11:47 PM, BGB wrote: >>>>>>>>>> but, in any case, with the other languages there are a wide >>>>>>>>>> range of >>>>>>>>>> libraries available, many under fairly open licenses (like MIT or >>>>>>>>>> BSD), >>>>>>>>>> and there is a lot more GPL stuff available, >>>>>>>>> >>>>>>>>> In the EE space you would need to look at CORBA or DCOM. >>>>>>>>> >>>>>>>>> You would prefer Java EE believe me. >>>>>>>>> >>>>>>>>> :-) >>>>>>>>> >>>>>>>> >>>>>>>> errm, so you can't just copy all the files over to ones' servers? >>>>>>>> and/or >>>>>>>> recompile the code for ones' servers?... >>>>>>> >>>>>>> The coding model in Java EE is definitely more modern than that >>>>>>> of CORBA and DCOM. >>>>>>> >>>>>> >>>>>> 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? >>>> >>>> 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. >>> >> >> yes, ok. >> >> >>>> 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. >>> >> >> 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.
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-01-26 21:34 -0400 |
| Message-ID | <0v%Ms.125648$Id.110278@newsfe24.iad> |
| In reply to | #21744 |
On 01/26/2013 02:40 PM, BGB wrote: > On 1/26/2013 5:25 AM, Arved Sandstrom wrote: [ 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? > The terms "client" and "server" are common in discussions of CORBA, yes. Strictly speaking what you've really got for any given local/remote method invocation in a CORBA distributed system is an object that receives the request, and a caller (client) that invokes the method on the receiving implementation entity - the real server is an Object Request Broker (ORB). Myself when doing CORBA I prefer to refer to things as client, servant, ORB etc, and not use the term "server". YMMV. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-26 22:06 -0500 |
| Message-ID | <510499d8$0$293$14726298@news.sunsite.dk> |
| In reply to | #21763 |
On 1/26/2013 8:34 PM, Arved Sandstrom wrote: > On 01/26/2013 02:40 PM, BGB wrote: >> On 1/26/2013 5:25 AM, Arved Sandstrom wrote: > [ 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? >> > The terms "client" and "server" are common in discussions of CORBA, yes. > Strictly speaking what you've really got for any given local/remote > method invocation in a CORBA distributed system is an object that > receives the request, and a caller (client) that invokes the method on > the receiving implementation entity - the real server is an Object > Request Broker (ORB). Myself when doing CORBA I prefer to refer to > things as client, servant, ORB etc, and not use the term "server". YMMV. But then we are down at the EJB, JNDI, EJB client level. I would call VisiBroker for a server. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-26 09:12 -0500 |
| Message-ID | <5103e445$0$288$14726298@news.sunsite.dk> |
| In reply to | #21721 |
On 1/26/2013 12:31 AM, BGB wrote: > On 1/25/2013 9:05 PM, Arne Vajhøj wrote: >> On 1/24/2013 11:31 PM, BGB wrote: >>> 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. >> > > 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. >>> 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. >> > > 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). >>> 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. >> > > ok. > > this much makes sense at least. The concept is sometimes call the Hollywood Principle. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-26 14:47 -0600 |
| Message-ID | <ke1ffk$vmg$1@news.albasani.net> |
| In reply to | #21738 |
On 1/26/2013 8:12 AM, Arne Vajhøj wrote: > On 1/26/2013 12:31 AM, BGB wrote: >> On 1/25/2013 9:05 PM, Arne Vajhøj wrote: >>> On 1/24/2013 11:31 PM, BGB wrote: >>>> 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. >>> >> >> 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. > ok. >> 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. > 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...). >>>> 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. >>> >> >> 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). > 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). >>>> 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. >>> >> >> ok. >> >> this much makes sense at least. > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-26 16:23 -0500 |
| Message-ID | <51044961$0$285$14726298@news.sunsite.dk> |
| In reply to | #21747 |
On 1/26/2013 3:47 PM, BGB wrote: > On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >> On 1/26/2013 12:31 AM, BGB wrote: >>> 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. > > I don't really like SOAP... > > IMHO, it seems wasteful and probably like a dedicated protocol could > probably be more efficient in most cases. SOAP is designed by committee. >>>> 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. >> >> 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. The principle can certainly also be used in SE context. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-26 15:24 -0600 |
| Message-ID | <ke1hld$4hr$1@news.albasani.net> |
| In reply to | #21751 |
On 1/26/2013 3:23 PM, Arne Vajhøj wrote: > On 1/26/2013 3:47 PM, BGB wrote: >> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>> On 1/26/2013 12:31 AM, BGB wrote: >>>> 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. >> >> I don't really like SOAP... >> >> IMHO, it seems wasteful and probably like a dedicated protocol could >> probably be more efficient in most cases. > > SOAP is designed by committee. > ok. >>>>> 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. >>> >>> 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. > > The principle can certainly also be used in SE context. > yep, or in many other cases. > Arne > >
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-01-26 21:47 -0400 |
| Message-ID | <XG%Ms.61014$H5.46906@newsfe28.iad> |
| In reply to | #21747 |
On 01/26/2013 04:47 PM, BGB wrote: > On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >> On 1/26/2013 12:31 AM, BGB wrote: [ SNIP ] > >>> 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. >> > > I don't really like SOAP... [ SNIP ] I don't know anyone who does, I know I don't. Still, it's what we've got. For well-designed operations and schemas it's not that verbose, not appreciably worse than JSON. Having WSDLs and the ability to validate is useful, although over the years I've come to believe that WSDL-first is an abomination unless the project is extremely structured and disciplined. SOAP is also - still - the only game in town for various security and transactional tasks, even if aspects of WS-Security are atrocious. For true web services I'd use REST almost always, because SOAP actually isn't much to do with the Web at all. But if I need application security, encryption of portions of a message, non-repudiation, transactionality etc,and I'm really doing RPC, I'm using SOAP. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-26 22:11 -0500 |
| Message-ID | <51049af9$0$293$14726298@news.sunsite.dk> |
| In reply to | #21765 |
On 1/26/2013 8:47 PM, Arved Sandstrom wrote: > On 01/26/2013 04:47 PM, BGB wrote: >> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>> On 1/26/2013 12:31 AM, BGB wrote: > [ SNIP ] >> >>>> 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. >>> >> >> I don't really like SOAP... > [ SNIP ] > > I don't know anyone who does, I know I don't. Still, it's what we've > got. For well-designed operations and schemas it's not that verbose, not > appreciably worse than JSON. Having WSDLs and the ability to validate is > useful, although over the years I've come to believe that WSDL-first is > an abomination unless the project is extremely structured and disciplined. > > SOAP is also - still - the only game in town for various security and > transactional tasks, even if aspects of WS-Security are atrocious. For > true web services I'd use REST almost always, because SOAP actually > isn't much to do with the Web at all. But if I need application > security, encryption of portions of a message, non-repudiation, > transactionality etc,and I'm really doing RPC, I'm using SOAP. Standards are rarely optimal. people are not too happy about HTTP and SMTP either. But a standard is a standard. SOAP got the tools support and all the standards that build on top of it. We can either accept it and live happy with it or invent a time machine and go back to around 1998 and tell a few people from IBM and MS how it should be done. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-26 22:54 -0600 |
| Message-ID | <ke2c01$bu5$1@news.albasani.net> |
| In reply to | #21779 |
On 1/26/2013 9:11 PM, Arne Vajhøj wrote: > On 1/26/2013 8:47 PM, Arved Sandstrom wrote: >> On 01/26/2013 04:47 PM, BGB wrote: >>> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>>> On 1/26/2013 12:31 AM, BGB wrote: >> [ SNIP ] >>> >>>>> 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. >>>> >>> >>> I don't really like SOAP... >> [ SNIP ] >> >> I don't know anyone who does, I know I don't. Still, it's what we've >> got. For well-designed operations and schemas it's not that verbose, not >> appreciably worse than JSON. Having WSDLs and the ability to validate is >> useful, although over the years I've come to believe that WSDL-first is >> an abomination unless the project is extremely structured and >> disciplined. >> >> SOAP is also - still - the only game in town for various security and >> transactional tasks, even if aspects of WS-Security are atrocious. For >> true web services I'd use REST almost always, because SOAP actually >> isn't much to do with the Web at all. But if I need application >> security, encryption of portions of a message, non-repudiation, >> transactionality etc,and I'm really doing RPC, I'm using SOAP. > > Standards are rarely optimal. > > people are not too happy about HTTP and SMTP either. > well, luckily there is HTTP 2.0 in development, which "should" be a little better, at least as far as it will Deflate the messages... http://en.wikipedia.org/wiki/Http_2.0 http://en.wikipedia.org/wiki/SPDY (in contrast to HTTP 1.1, it will multiplex the requests and responses over a single socket, and also compress the data). > But a standard is a standard. > > SOAP got the tools support and all the standards that > build on top of it. > > We can either accept it and live happy with it or invent > a time machine and go back to around 1998 and tell a few > people from IBM and MS how it should be done. > or just blow it off and do whatever... like, standards are useful so long as they are useful, but otherwise, unless there is some greater reason (mandatory inter-op or orders from above), why bother? like, unless is better for the project overall (or otherwise benefits the developers in some way), why not just go and do something different? granted, yes, usually standards are a good thing, but usually these are *good* standards. luckily at least, some of the worse offenders here have gained the fate they deserve.
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-01-27 07:46 -0400 |
| Message-ID | <Ss8Ns.125659$Id.2235@newsfe24.iad> |
| In reply to | #21787 |
On 01/27/2013 12:54 AM, BGB wrote: > On 1/26/2013 9:11 PM, Arne Vajhøj wrote: >> On 1/26/2013 8:47 PM, Arved Sandstrom wrote: >>> On 01/26/2013 04:47 PM, BGB wrote: >>>> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>>>> On 1/26/2013 12:31 AM, BGB wrote: >>> [ SNIP ] >>>> >>>>>> 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. >>>>> >>>> >>>> I don't really like SOAP... >>> [ SNIP ] >>> >>> I don't know anyone who does, I know I don't. Still, it's what we've >>> got. For well-designed operations and schemas it's not that verbose, not >>> appreciably worse than JSON. Having WSDLs and the ability to validate is >>> useful, although over the years I've come to believe that WSDL-first is >>> an abomination unless the project is extremely structured and >>> disciplined. >>> >>> SOAP is also - still - the only game in town for various security and >>> transactional tasks, even if aspects of WS-Security are atrocious. For >>> true web services I'd use REST almost always, because SOAP actually >>> isn't much to do with the Web at all. But if I need application >>> security, encryption of portions of a message, non-repudiation, >>> transactionality etc,and I'm really doing RPC, I'm using SOAP. >> >> Standards are rarely optimal. >> >> people are not too happy about HTTP and SMTP either. >> > > well, luckily there is HTTP 2.0 in development, which "should" be a > little better, at least as far as it will Deflate the messages... > > http://en.wikipedia.org/wiki/Http_2.0 > http://en.wikipedia.org/wiki/SPDY > > (in contrast to HTTP 1.1, it will multiplex the requests and responses > over a single socket, and also compress the data). > > >> But a standard is a standard. >> >> SOAP got the tools support and all the standards that >> build on top of it. >> >> We can either accept it and live happy with it or invent >> a time machine and go back to around 1998 and tell a few >> people from IBM and MS how it should be done. >> > > or just blow it off and do whatever... > > > like, standards are useful so long as they are useful, but otherwise, > unless there is some greater reason (mandatory inter-op or orders from > above), why bother? > > like, unless is better for the project overall (or otherwise benefits > the developers in some way), why not just go and do something different? > > granted, yes, usually standards are a good thing, but usually these are > *good* standards. luckily at least, some of the worse offenders here > have gained the fate they deserve. > > Another note on SOAP: many (I'd say most) of the pain points encountered by a developer are not problems of SOAP itself. You can use a tool like SoapUI to hit WSDLs, and inspect the raw XML being passed back and forth - if the WSDLs and XSDs are well-crafted then the XML requests and responses are quite readable and not particularly verbose. You'd be better off using SOAP most of the time for RPC-type work then rolling your own. WS-Security is a different matter. That's complicated for many use cases; you don't even want to look at the typical raw XML for a request. :-) OTOH there is really no other game in town for this aspect. What really complicates things is the tooling. For Java, you'd probably use Axis or CXF. I no longer like Axis at all, for various reasons, so I've moved to CXF. But even CXF, if you generate your client classes off a WSDL, the verbosity and complexity of the classes is offputting. You have to acquire a fair bit of experience with a language-specific WS framework in order to make generated code half-reasonable to work with. .NET, say with C# as the language, is no better - lots of little gotchas that you just have to be aware of. So it's not all the fault of SOAP - programming language implementations for developing client and server code complicate matters quite a lot. Usually in the enterprise world you have little or no leeway as to how systems talk to each other. You may have a few options to choose from, but rolling your own is looked upon askance. AHS
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-27 12:47 -0600 |
| Message-ID | <ke3spm$ela$1@news.albasani.net> |
| In reply to | #21796 |
On 1/27/2013 5:46 AM, Arved Sandstrom wrote:
> On 01/27/2013 12:54 AM, BGB wrote:
>> On 1/26/2013 9:11 PM, Arne Vajhøj wrote:
>>> On 1/26/2013 8:47 PM, Arved Sandstrom wrote:
>>>> On 01/26/2013 04:47 PM, BGB wrote:
>>>>> On 1/26/2013 8:12 AM, Arne Vajhøj wrote:
>>>>>> On 1/26/2013 12:31 AM, BGB wrote:
>>>> [ SNIP ]
>>>>>
>>>>>>> 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.
>>>>>>
>>>>>
>>>>> I don't really like SOAP...
>>>> [ SNIP ]
>>>>
>>>> I don't know anyone who does, I know I don't. Still, it's what we've
>>>> got. For well-designed operations and schemas it's not that verbose,
>>>> not
>>>> appreciably worse than JSON. Having WSDLs and the ability to
>>>> validate is
>>>> useful, although over the years I've come to believe that WSDL-first is
>>>> an abomination unless the project is extremely structured and
>>>> disciplined.
>>>>
>>>> SOAP is also - still - the only game in town for various security and
>>>> transactional tasks, even if aspects of WS-Security are atrocious. For
>>>> true web services I'd use REST almost always, because SOAP actually
>>>> isn't much to do with the Web at all. But if I need application
>>>> security, encryption of portions of a message, non-repudiation,
>>>> transactionality etc,and I'm really doing RPC, I'm using SOAP.
>>>
>>> Standards are rarely optimal.
>>>
>>> people are not too happy about HTTP and SMTP either.
>>>
>>
>> well, luckily there is HTTP 2.0 in development, which "should" be a
>> little better, at least as far as it will Deflate the messages...
>>
>> http://en.wikipedia.org/wiki/Http_2.0
>> http://en.wikipedia.org/wiki/SPDY
>>
>> (in contrast to HTTP 1.1, it will multiplex the requests and responses
>> over a single socket, and also compress the data).
>>
>>
>>> But a standard is a standard.
>>>
>>> SOAP got the tools support and all the standards that
>>> build on top of it.
>>>
>>> We can either accept it and live happy with it or invent
>>> a time machine and go back to around 1998 and tell a few
>>> people from IBM and MS how it should be done.
>>>
>>
>> or just blow it off and do whatever...
>>
>>
>> like, standards are useful so long as they are useful, but otherwise,
>> unless there is some greater reason (mandatory inter-op or orders from
>> above), why bother?
>>
>> like, unless is better for the project overall (or otherwise benefits
>> the developers in some way), why not just go and do something different?
>>
>> granted, yes, usually standards are a good thing, but usually these are
>> *good* standards. luckily at least, some of the worse offenders here
>> have gained the fate they deserve.
>>
>>
> Another note on SOAP: many (I'd say most) of the pain points encountered
> by a developer are not problems of SOAP itself. You can use a tool like
> SoapUI to hit WSDLs, and inspect the raw XML being passed back and forth
> - if the WSDLs and XSDs are well-crafted then the XML requests and
> responses are quite readable and not particularly verbose.
>
> You'd be better off using SOAP most of the time for RPC-type work then
> rolling your own.
>
IMHO, better is probably not using RPC, if possible, but either way.
> WS-Security is a different matter. That's complicated for many use
> cases; you don't even want to look at the typical raw XML for a request.
> :-) OTOH there is really no other game in town for this aspect.
>
> What really complicates things is the tooling. For Java, you'd probably
> use Axis or CXF. I no longer like Axis at all, for various reasons, so
> I've moved to CXF. But even CXF, if you generate your client classes off
> a WSDL, the verbosity and complexity of the classes is offputting. You
> have to acquire a fair bit of experience with a language-specific WS
> framework in order to make generated code half-reasonable to work with.
> .NET, say with C# as the language, is no better - lots of little gotchas
> that you just have to be aware of.
>
> So it's not all the fault of SOAP - programming language implementations
> for developing client and server code complicate matters quite a lot.
>
well, maybe.
it is easier for a language which has built-in lists (in the Lisp
sense), but these are an uncommon concept in mainstream languages, and
if built by library features aren't quite as nice.
for example, in C, I can compose messages like:
t=dylist4s("message", dyint(1), dyint(2), dyint(3));
btSendMessage(tgt, t);
and, in the reciever:
t=btRecieveMessage(src);
if(t && dyFormIs(t, "message"))
{ ... }
which *could* always be a bit worse.
in my own language, it is like this:
t=#{#message, 1, 2, 3};
btSendMessage(tgt, t);
...
t=btRecieveMessage(src);
if(t && t[0]==#message) { ... }
for Java, maybe it could be something like:
t=Cons.list(message, 1, 2, 3); //lots of overloads
tgt.sendMessage(t);
...
t=src.recieveMessage();
if((t!=null) && t.formIs("message"))
{ ... }
probably with special Cons and MailBox classes.
> Usually in the enterprise world you have little or no leeway as to how
> systems talk to each other. You may have a few options to choose from,
> but rolling your own is looked upon askance.
>
well, this is where the whole "mandatory interop or orders from above"
comes in. in such a case, people say what to do, and the programmer is
expected to do so.
but, I more meant for cases where a person has free say in the matter.
and, also, a person still may choose an existing option, even if bad,
because it is the least effort, or because it is still locally the best
solution.
like, rolling ones' own is not required, nor necessarily always the best
option, but can't necessarily be summarily excluded simply for sake of
"standards", as doing so may ultimately just make things worse overall.
historically there have been cases where standards organizations have
made some fairly bad standards, and most everyone else ended up ignoring
them (and they largely became forgotten).
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-27 19:40 -0500 |
| Message-ID | <5105c8fa$0$288$14726298@news.sunsite.dk> |
| In reply to | #21801 |
On 1/27/2013 1:47 PM, BGB wrote: > On 1/27/2013 5:46 AM, Arved Sandstrom wrote: >> Usually in the enterprise world you have little or no leeway as to how >> systems talk to each other. You may have a few options to choose from, >> but rolling your own is looked upon askance. >> > > well, this is where the whole "mandatory interop or orders from above" > comes in. in such a case, people say what to do, and the programmer is > expected to do so. > > but, I more meant for cases where a person has free say in the matter. > > and, also, a person still may choose an existing option, even if bad, > because it is the least effort, or because it is still locally the best > solution. > > like, rolling ones' own is not required, nor necessarily always the best > option, but can't necessarily be summarily excluded simply for sake of > "standards", as doing so may ultimately just make things worse overall. It almost can. If you go non standard and problems arise, then you are in deep shit. Arne
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web