Creiamo portali, e-commerce con Liferay
Come accedere a Portal (semplice)
Gli utenti possono accedere al portale tramite Internet tradizionale o accesso wireless a Internet. Gli sviluppatori possono utilizzare SOAP, RMI e classi di canali personalizzati per accedere alle API esposte a chiamate esterne per il funzionamento del portale.
Portlet Application Interface (JSP168)
Liferay è progettato per essere in grado di distribuire portlet conformi allo standard JSP168 (Portlet Application Interface). Inoltre, molti portlet utili (come posta, documenti, calendari, bacheche e così via) sono stati forniti in bundle con Portal e possono essere utilizzati come esempi per l’aggiunta di portlet personalizzati.
Struts and Tiles (Livello di rappresentazione)
Tutte le richieste HTTP e WAP ricevono risposta tramite MainServlet.MailServlet estende la classe base di Struts ActionServlet.
MainServlet elabora tutte le richieste in modo che ogni richiesta possa essere inoltrata alla PortletAction appropriata per l’elaborazione.
Per ulteriori informazioni sul framework web del portale, fare riferimento a Comm.it per lo sviluppo di un portale altamente professionale con Liferay.
Le informazioni sul layout del portale vengono gestite tramite modelli personalizzati.
EJB di sessione, Spring e Hibernate (livello Biz e Persistenza)
Liferay non dipende più da EJB e può essere implementato in un contenitore Servlet standard. Tutta la logica di business è implementata in POJO che possono essere trovati e istanziati da Spring. Queste implementazioni possono essere modificate o migliorate tramite Spring’s AOP e IOC.
Portal Professional Edition chiama l’implementazione POJO per fornire un aspetto leggero e coerente. Tutti i dati vengono conservati utilizzando Hibernate per le chiamate di implementazione POJO.
Liferay originariamente utilizzava la tecnologia CMP per creare la persistenza, ma considerando la velocità e la flessibilità di Hibernate nella persistenza dei dati, è passato a Hibernate per la costruzione.
Liferay non si basa su un database specifico e può essere eseguito su database in più dialetti.
Liferay utilizza il meccanismo di sicurezza Web JAAS. Quando l’utente accede, le informazioni dell’utente verranno trasmesse ai corrispondenti nodi Servlet e EJB.
Il bean Session remoto ne approfitta per confermare la sicurezza e l’autorizzazione al livello EJB per impedire che venga copiato altrove.
Il bean di sessione locale espone la logica aziendale ad altri bean di sessione e non è necessario confermare esplicitamente la sicurezza perché non verranno chiamati in remoto. Le informazioni verranno anche trasmesse al POJO EJB della sessione remota per l’implementazione.
Portal Enterprise Edition utilizza Session EJB per incapsulare l’implementazione POJO, fornendo estensioni pesanti e supporto per transazioni per siti Web di grandi dimensioni.
Consente agli sviluppatori di separare il server Web, il server EJB e il server database per creare la propria architettura a tre livelli.
Questa è una vera distribuzione a più livelli, perché a nessuno interessa più un singolo livello e massimizza la flessibilità per l’azienda.
La maggior parte di EJB, HBM e Model sono generati da antbuild-service nel file service.xml nella directory / portal-ejb. Ogni portlet che usa la persistenza dei dati ha il proprio service.xml. (Cerca nella directory / portal-ejb e otterrai un elenco).
Quando è necessario generare classi persistenti per portlet, è possibile copiare questi file nella directory / portal-ejb. Questo è uno strumento interno costruito sul motore Xdoclet.
Ad esempio, durante la lettura del service.xml del portlet Segnalibri, verranno generate le seguenti classi di modello. Ogni classe del modello mappa una tabella nel database. Non è necessario modificare BookmarksEntryModel, ma aggiungere il codice di manutenzione manuale modificando BookmarksEntry. Genera BookmarksEntry contemporaneamente ed estendi BookmarksEntryModel. In modo che gli sviluppatori possano generare facilmente codice, ma abbiano anche la flessibilità di mantenere il codice manualmente.
SAOP, RMI e Tunneling
Tutte le implementazioni POJO remote sono esposte al mondo esterno tramite SOAP, RMI e la nostra classe Tunneling. Il motivo per cui lo facciamo semplicemente non è perché il servizio Web è ancora un mondo caotico, ma perché lo troviamo utile per l’integrazione del sistema.
Quello che segue è il piano di implementazione di un’azienda per bilanciare queste risorse.