Esecuzione di Java come app Web

Question

Ok, so che Java è una lingua ma qualcuno mi ha chiesto se è possibile scrivere un'applicazione Web per l'interfaccia con un'applicazione Web che ho scritto in ASP.NET. Sto implementando un servizio Web per offrire un XML, quindi è un bel linguaggio indipendente.

Tuttavia, non sono sicuro al 100% se percorrere la rotta Java abbia molto senso. Mi aspettavo un codice lato server PHP o ASP.NET con forse qualche Ajax/JavaScript o forse un programma JavaScript client più pesante usando JScript.

Qualcuno potrebbe spiegare l'ambiente Java di base quando si tratta di applicazioni web? Ho inferito quanto segue: sto abbaiando sull'albero giusto?

• Java quando correre come ASP.NET è chiamata JSP
• JavaBeans è un po 'come il framework .NET, cioè si tratta di una libreria di componenti riutilizzabili
• Java EE è un po' come ASP.NET in quanto si tratta di un framework per la creazione di pagine web su un server
• Java può funzionare anche sul client, ma ha bisogno della Java VM installazione

Durante l'esecuzione di Java sul client, si può utilizzare JavaBeans e c'è un struttura? Può anche usare JScript? Non penso che JScript sia una libreria JavaScript.

Mentre l'esecuzione di Java sul server andrebbe bene, questa è un'applicazione relativamente piccola e quindi Java sembra un po 'eccessivo. PHP o ASP.NET si sentono meglio.

Ma non penso che dovrebbero andare giù l'applet Java nel browser e aggiunge complessità che non è necessaria.

Answer 1

Proviamo a definire alcuni termini (non necessariamente al 100% esatto, ma comprensibile)

• Java: possono essere un sacco di cose: la lingua, la JVM, la piattaforma, l'idea, ...
• Java SE: Java Standard Edition: Java "normale" utilizzato per l'esecuzione di applicazioni desktop. Questo è stato precedentemente noto come "Java 2 SE" e "J2SE".
• Java EE: Java Enterprise Edition. Lo stack a livello aziendale per lo sviluppo di applicazioni Web e altre bestie più complesse (contiene tonnellate di componenti). Questo è stato precedentemente noto come "Java 2 EE" e "J2EE".
• JSP: Java Server Pages. Un linguaggio che consente di mescolare contenuti HTML/XML con Java Scriptlets. Praticamente equivalente a ASP.NET.
• Java Beans (nota: non "JavaBeans"): una specifica piuttosto leggera che descrive solo come devono essere scritte le classi in modo che le loro proprietà e metodi possano essere scoperti automaticamente. Da non confondere con Enterprise Java Beans (EJB)
• Enterprise Java Beans/EJB: il fratello molto più complesso di Java Beans. Ti consente di incapsulare alcune parti della tua applicazione. Terribilmente complesso ed ingombrante da usare (un po 'meglio nelle ultime versioni, ma il cambiamento sembra essere arrivato tardi).

JScript è il dialetto Microsoft di JavaScript e non ha nulla a che fare con Java.

A proposito, JavaScript non ha nulla a che fare con Java. Le uniche somiglianze sono i primi 4 caratteri del loro nome e una somiglianza superficiale nella sintassi.

Quindi, in sostanza: se vogliono scrivere un'applicazione Java per interfacciarsi con l'applicazione che fornisce semplicemente un file XML, Java è sicuramente adatto a questo. Non hai bisogno di alcuna delle tecnologie Java EE per questo. Java SE è più che sufficiente per questo.

Modifica: Si noti che è una pratica abbastanza comune non utilizzare l'intero stack Java EE per applicazioni Web (di piccole dimensioni). Nello specifico, Apache Tomcat, che è ampiamente utilizzato, non è un Java EE Server completo (come richiesto dalle specifiche Java EE), ma piuttosto un'implementazione degli standard JSP e Servlet (due parti principali di Java EE). Gestisce ancora molte, molte utili applicazioni Web Java, semplicemente perché non utilizzano le funzionalità più complesse di Java EE.

Answer 2

Sembra che tu abbia una buona padronanza delle cose.

È corretto esitare utilizzando J2EE per una piccola applicazione Web. Ho trovato utile questo .NET/J2EE feature comparison. Si noti in particolare il confronto tra i costi e la complessità del secondo grafico su un progetto di test sviluppato da Microsoft e Sun.

Java offre un'enorme potenza, ma è più adatto per le applicazioni Web di grandi dimensioni. Tenderei ad essere d'accordo con la tua preferenza per ASP/.NET in questo caso.

Answer 3

Sembra una buona panoramica del paesaggio.

Sono d'accordo con la vostra valutazione dell'approccio applet, buono se avete bisogno di un'elaborazione davvero complessa al cliente. Altrimenti l'HTML potenziato con JavaScript va bene, alcuni funzionano per renderlo portatile attraverso i browser.

Gli aspetti lato server sono interessanti. Se la persona che consuma il tuo servizio Web è già fluente in Java e forse dispone già dell'infrastruttura delle app Web, non c'è motivo di preoccuparsi dell'uso di Java.

Quindi se sono lo scrivono, lasciaglielo fare.

D'altra parte si un programmatore .Net viene chiesto di abilità in Java penso che sia non ovvia (e sono Java al mio nucleo blu) Se avessi voluto un approccio veloce e facile da fare un sito web in una situazione di campo verde mi piacerebbe usare qualcosa come php o Smash

Il vantaggio di Java in un senso JE o, presumo, un approccio .Net in piena regola è che si ottiene un ridimensionabile, a scomparsa, soluzione amministrabile (è una parola?). Solo perché la funzione è piccola e facile, non dare per scontato che non sarà molto utilizzata.

Answer 4

Java quando correre come ASP.NET è chiamata JSP

Questa è una sorta di vero - una pagina JSP tradizionale è molto simile a una pagina ASP classico. Non c'è un "codebehind" come quello che hai con ASPX.

La grande differenza in Java è che il framework web si basa su cose chiamate servlet. Un servlet è un po 'come un "axd" ASP.NET in quanto gestisce richieste HTTP non elaborate (get, post, ecc.) E sputa una risposta.

In cima a quel servlet "base" ci sono molti altri framework - JSP è uno di questi (i JSP sono infine compilati dal server in servelet). Anche JSF, Struts, Tapestry e molti altri sono costruiti su questa base. Nel mondo .NET hai davvero due scelte: ASP.NET (.aspx pagine con codebehind) o .NET MVC. La maggior parte dei framework web Java sono più simili NET MVC, anche se (se ho capito bene) JSF è più come ASP.NET

JavaBeans è un po 'come il framework .NET , cioè si tratta di una libreria di componenti riutilizzabili

Non proprio. Quello che stai pensando è J2SE, che è il framework di base su cui sono costruite tutte le app Java - ha le classi di raccolta, socket, sicurezza, ecc. JavaBeans è solo una specifica su come scrivere oggetti di tipo DTO (denominazione standard per getter e setter, ecc)

Java EE è un po 'come in ASP.NET che è un framework per la creazione di web pagine sul server

Questo è più o meno corretto . J2EE è un'estensione di J2SE per fare lo sviluppo del web (così come EJB di cui sono tutta una palla nother di cera che in realtà non hanno un equivilent diretta in .NET)

Java può funzionare anche sul client, ma it richiede l'installazione di Java VM

Sì, questo è vero. Proprio come è possibile utilizzare .NET per sviluppare applicazioni desktop o web, è possibile utilizzare Java allo stesso modo. E in entrambi i casi è richiesto un runtime (sia Java VM che .NET)

Per quanto riguarda la valutazione sull'uso di Java rispetto a PHP rispetto a .NET, ho lavorato con tutti loro, e Direi che Java è il più complesso, ma anche molto potente per applicazioni su larga scala. PHP sarà il più semplice di gran lunga, ed è ottimo per le piccole app, ma può diventare complicato quando le cose si ingrandiscono. ASP.NET ha un buon equilibrio. Un po 'più complesso di PHP, ma anche molto più potente.

Answer 5

Non è del tutto chiaro per me se stai scrivendo il webservice o è già stato scritto e qualcuno vuole solo usarlo?

Se vogliono solo di chiamare il webservice è la lingua agnostico in modo che non dovrebbe importare che lingua/le librerie che utilizzano.

Se si sta scrivendo il webservice, di nuovo, in realtà non importa quale lingua si usa, in generale uno hai dimestichezza con e ha una bella biblioteca.

Se si decide di utilizzare Java, ho esperienza con Axis2 ed è molto semplice una volta che hai capito cosa sta facendo. Puoi scrivere un POJO (Plain Old Java Object) e dire ad Axis che è quello che vuoi esporre. Caricalo su Tomcat o qualcosa di simile e sei a posto.

Answer 6

La risposta breve - alla domanda che non hai chiesto :) - è: Java dovrebbe funzionare correttamente. Se Java è ciò che il tuo cliente/partner/qualsiasi cosa è più comodo da usare, lasciali * usarlo.

In particolare:

• Se hai scritto un servizio ordinario web SOAP con WSDL, un'applicazione Java non dovrebbe avere alcuna difficoltà a parlare ad esso. Ho scritto client Java che parlano di servizi Web .NET e.I client NET che parlano con i servizi Web Java e, anche se c'è sempre un po 'di manipolazione, non ci sono problemi seri a meno che i servizi inviino oggetti binari incorporati o qualcos'altro non standard.

• Se hai appena scritto qualcosa che serve XML non elaborato su HTTP, Java non dovrebbe avere più problemi con quello di .NET.

Java non è necessariamente pesi massimi più di PHP o ASP.NET, se si utilizza un server leggero come Jetty. Nessuna applet del browser deve essere coinvolta. E Java ha librerie solide e stabili per parlare con i servizi web. (Anche PHP lo sarebbe, ma sarei sorpreso se quelli di Java non fossero stati molto più pesantemente esercitati.)

Per le altre tue domande, potresti dare un'occhiata all'articolo di Wikipedia ".NET framework: .NET vs. Java and J2EE".

---

* Se vogliono si di scrivere la loro fine del servizio web, che è una cosa completamente diversa. Probabilmente hanno una qualche infrastruttura Java esistente che hanno davvero bisogno di riutilizzare - nel qual caso suggerirei di prendere un buon libro di base come O'Reilly's Head First Servlets and JSP - ma altrimenti, se .NET è la tua esperienza, è quello che dovrebbero lascia che tu usi. Se non gli piace Microsoft, digli che lo farai girare sotto Mono.

Answer 7

Davvero deve essere Java? Forse potresti scrivere una piccola web app usando JRuby o Groovy che consuma il tuo servizio web ASP.NET. Ci sono strumenti (.ie. Apache CFX) in JRuby, Groovy e plain old java che ti permettono di consumare il tuo WSDL per creare clienti al volo.

Detto questo, è difficile dare un buon suggerimento senza sapere esattamente come si intende utilizzare questo client Java. Interagirà con gli utenti reali o è come un lavoro batch?

Se è il più tardi, puoi batterlo rapidamente con Java o JRuby/Groovy. Poiché le tecnologie successive possono essere compilate in contenitori, possono essere eseguite sulla JVM.

Se deve essere rivolto agli utenti, è necessario creare un client Web o uno spesso.

Per il primo, è possibile seguire il percorso JRuby/Groovy e creare una piccola app Web, che è possibile distribuire su un server dell'app Jetty/GlassFish/Tomcat ridotto. O potresti andare in modo Java e usare uno dei tanti framework.

Indipendentemente dalla scelta della lingua JVM, è molto più semplice creare un'app Web che un client spesso. Sfortunatamente, creare un client GUI non banale con Java con una buona progettazione dell'interfaccia utente non è un compito banale. Ho lavorato sia con i client web che con quelli thick e questa è stata la mia esperienza (YMMV).

Non sarei troppo preoccupato nel pensare al sovraccarico dell'utilizzo di un contenitore web. È possibile eseguire un'app Web snella e media in un contenitore in circa 500 mg (che dovrebbe essere una goccia nell'acqua per un server.)

E se si attaccano realmente a servlet semplici e non JSP (ovvero, il servlet crea l'output HTML) è possibile utilizzare un contenitore di servlet veramente meschino, snello e minuscolo come TJWS, LWS o Winstone che può essere eseguito con meno di 1 MB.

Spero che aiuti.