Re: The Revenge of the Geeks
Date: Sat, 26 Jan 2013 07:26:17 -0400
Message-ID: <t3PMs.86406$sm1.29092_at_newsfe22.iad>
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.
AHS Received on Sat Jan 26 2013 - 12:26:17 CET