Re: The Revenge of the Geeks
Date: Sat, 26 Jan 2013 13:22:11 -0600
Message-ID: <ke1afi$lij$1_at_news.albasani.net>
On 1/26/2013 5:26 AM, Arved Sandstrom wrote:
> On 01/25/2013 12:31 AM, 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...
> [ 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... Received on Sat Jan 26 2013 - 20:22:11 CET