Oracle Fusion Middleware Blog

Deutsche Informationen rund um Oracle Fusion Middleware

Archive for Juli 2013

Eine kurze Historie des Java Plug-Ins für Forms

leave a comment »

Wird Oracle Forms als Web-Applikation ausgeführt, wird für die Interaktion mit dem Anwender ein Applet ausgeführt, das ein Java Plug-In im Browser benötigt.
Bis einschließlich Forms 10g wurde als Java Plug-in vor allem der Oracle JInitiator verwendet, der auf dem JDK 1.3 basierte.
Warum Oracle ein eigenes Plug-In bereitstellte, lag vor allem daran, dass es im Java Plug-In von Sun noch einige Bugs gab, die vor allem die Ausführung der Forms-Applikationen stark beeinträchtigte.
Mit der Übernahme des Unternehmens Sun durch Oracle ergaben sich bessere Voraussetzungen, diese Probleme zu beheben. Mit Forms 11g wurde deshalb die Weiterentwicklung des JInitiators eingestellt.

In der Entwicklung des Java Plug-Ins (ehemals Sun, jetzt Oracle)  hat es einige deutliche Zäsuren gegeben.
Ab der Version 1.5.0_06 ist eine dynamische Versionierung möglich. Dies vereinfacht die Administration einer Anwendung, da nicht mehr eine bestimmte Version des Plug-Ins auf dem Client, sondern nur eine Mindestversion gefordert wird. Eine Einschränkung nach oben, d.h. auf ein bestimmtes Release (z.B. JDK 6)  ist über das Family Feature möglich. Siehe dazu folgendes Dokument.
Mit der Version 1.6.0_10 wurde  das Next Generation Plug-In veröffentlicht, dass weitgehende Änderungen mit sich brachte. So laufen die Applets in einer eigenen Java Virtual Machine (JVM) unabhängig vom Prozess des Browsers. Mit Hilfe des Parameters java_version können so innerhalb eines Browsers unterschiedliche Java-Versionen ausgeführt werden. Allerdings muss beachtet werden, dass u.a. dieser Parameter nicht zur Anwendung mit Oracle Forms-Applikationen supportet ist und deshalb auch in der Forms-Dokumentation nicht erwähnt wird. Eine Beschreibung des neuen Verhaltens kann in diesem Dokument nachgelesen werden.
Die letzte größere Veränderung kam mit zunehmenden Sicherheits-Problemen des Java Plug-Ins im Browser. Die Firma Oracle verkündete mit der Version 1.7.0_21 verschärfte Sicherheits-Maßnahmen für künftige Updates, die u.a. die notwendige Signierung aller Applets, ein Tool zum automatischen Entfernen älterer Versionen und erweiterte Warnungen (Alerts) betreffen. Nachzulesen sind diese Erweiterungen in diesem Dokument.
Gerade die zunehmenden Warnungen (Alerts) bei den Anwendern stellen den Administrator von Forms-Anwendungen in Unternehmen vor neue Herausforderungen.

Noch ein wichtiger Hinweis zum Support:
Wird eine bestimmte Version des JDK (und damit auch des Plug-In) in einem Oracle-Produkt verwendet, gelten die Support-Fristen des übergeordneten Produktes (z.B. Oracle Forms), selbst wenn der offizielle Support für die entsprechende Version des JDK ausgelaufen ist (siehe dazu die Note 1557737.1 vom Oracle Support). So ist es auch zu erklären, dass es über den Oracle Support noch Updates für eine bereits abgelaufene Version des JDK geben kann.
So können zum Beispiel nur Kunden mit einem gültigen Wartungsvertrag das JDK 6 Update 51 über MyOracle Support  beziehen (Note 1439822.1).
<JM>

Written by fmtechteam

29/07/2013 at 19:24

Veröffentlicht in Forms, Java, Jürgen Menge

Spracheinstellungen für die Human Workflow Services

leave a comment »

Für die Human Workflow Services ist nach der Installation des SOA/BPM Servers nur eine Sprache konfiguriert, und zwar Englisch – en. Sollen Task Title, Category und Subcategory mehrsprachig erscheinen, müssen neue Sprachen hinzugefügt werden. Dies geht über den System MBean Browser im Enterprise Manager.

Im EM Navigator den Eintrag soa-infra markieren und über das Menu der rechten Maustaste oder über die Popliste SOA-Infrastructure unter Administration den System MBean Browser aufrufen.
Image

Navigieren zu : Application Defined Mbeans -> oracle.as.soainfra.config -> Server: <ServerName> -> WorkflowConfig -> human-workflow.
Auf der Operations Tab wird die Aktion createLocale ausgewählt.
Image

Bei den Parametern setzt man language, defaultFlag und enabledFlag, z.B. de, false und true. Um die Parameter zu speichern wird der Button Invoke angeklickt.
Image

Die Anzeige muss neu aufgebaut werden, damit die neue Sprache im Mbean Browser angezeigt wird. Dazu wird wieder der Eintrag human-workflow markiert und der Refresh Button rechts oben angeklickt.
Image

Unter WorkflowConfig.LocaleList werden alle Sprachen angezeigt.
Image

Erst jetzt können z.B. die Titel der Human Tasks in den oben konfigurierten Sprachen Deutsch, Englisch und Französisch angezeigt werden.

Wichtig ist, dass die Sprachen eingetragen werden bevor Prozessinstanzen gestartet werden. Sind bereits Instanzen gestartet, werden die Task Titel in Englisch angezeigt. Wenn jetzt Deutsch und Französisch über den MBean Browser hinzugefügt werden, dann werden die Aufgaben der bereits gestarteten Prozesse nicht in den deutschen und französischen Aufgabenlisten angezeigt (siehe auch 32.12.3 How to Change the Language in Which Tasks Are Displayed).

<GS>

Written by fmtechteam

29/07/2013 at 16:52

Veröffentlicht in BPEL, BPM, Gert Schüßler, SOA

Integration BPM TaskList Portlet in Oracle Portal 11g

leave a comment »

Verweise und Dokumentationen

  1. Oracle® Fusion Middleware Developer’s Guide for Oracle SOA Suite -> ConfiguringTask List Portlet
  2. Oracle® Fusion Middleware Administrator’s Guide for Oracle WebCenter Portal -> Configuring WS-Security
  3. Oracle® Fusion Middleware Administrator’s Guide for Oracle Portal -> Securing Access to Web Services Remote Portlets

Vorbemerkungen

Die TaskList Portlet Anwendung ist eine Produktkomponente der BPM Suite und somit funktional vorgegeben. Jegliche Änderungen der Logik, der Inhalte und des Layouts sind ohne weiteres nicht möglich. Im Wesentlichen ist dieses Portlet eine Abbildung der Worklist App der BPM Suite. Folgende Bilder zeigen das TaskList Portlet in einer WebCenter Portalanwendung sowie im Oracle Portal.

clip_image002

clip_image002[4]

Eine Gesamtarchitektur des Setups sieht wie folgt aus

clip_image002[9]

Die Portletanwendung wird auf dem Managed Server der SOA Suite installiert. Dazu muss der Managed Server zuvor mit der Portletlaufzeit erweitert werden. Weiterhin muss der WSRP request über SAML abgesichert werden, damit die Identität des Portalusers zum Portlet propagiert werden kann. Dies setzt auch voraus, dass sowohl Portal als auf BPM Suite denselben Userstore verwenden.

Im Folgenden ist die Herangehensweise der Integration beschrieben.

Vorbereitungen

  • FMW Repository der SOA Domain über RCU mit <präfix>_Portlets erweitern
  • Laufzeitumgebung für Portlets bereitstellen
    • Domain komplett stoppen
    • Installieren der WebCenter Software ins Middleware Home auf dem SOA Server
    • SOA Domain mit Oracle Portlet Producer- 11.1.1.0 (Oracle_WC1) erweitern
      • DB Verbindung auf das eben erstellte PortletDS Schema setzen
      • Auf der Wizard Seite „Optionale Konfiguration“ Deployments und Services“ aktivieren

        clip_image002[11]

      • Bei den Deploymenteinstellungen bitte schauen, welche Bibliotheken und Anwendungen nur auf das Target WC_Portlet aktiviert ist. Diese bitte auch auf das Target soa_server1 setzen.
        Das müssten sein

        • oracle.portlet-producer.jpdk(11.1.1,11.1.1)
        • oracle.portlet-producer.wsrp(11.1.1,11.1.1)
        • oracle.webcenter.skin(11.1.1,11.1.1)
        • portalTools (11.1.1.4.0)
        • wc-producer-web-lib(11.1.1,11.1.1)
        • wlp-framework-common-web-lib(11.1.1,11.1.1)
        • wlp-light-core-web-lib(11.1.1,11.1.1)
        • wlp-producer-full-web-lib(11.1.1,11.1.1)
        • wlp-wsrp-producer-core-web-lib(11.1.1,11.1.1)
        • wsrp-tools (11.1.1.4.0)
        • Bitte auch die PortletDS Datasource auf das Target soa_server1 setzen
    • Domain starten (nur AdminServer und soa_server1, aber nicht WC_Portlet . Diesen kann man über die WLS Konsole entfernen) und testen, ob die WSRP Tools funktionieren (http://<soaserver>:<soaport>/wsrp-tools )
  • Deployen eines Testportlets in das Target soa_server1, um zu sehen, ob alles gut funktioniert.

clip_image002[13]

clip_image002[15]

Der rot gekennzeichntete Link gibt die WSRP URL an, die beim Registrieren des Producers im Portal verwendet wird. Es wird hier nur überprüft, ob die Anwendung als WebService ansprechbar ist, nicht aber, ob der Inhalt der Anwendung fehlerfrei ist. Um das zu sehen, kann man oben den Link run as servlet aufrufen.

TaskList Portlet Deployen

  • Aus der SOA Domain in WLS Konsole auswählen
    • Deployments
    • Install
    • Current Location auf <Oracle_Home>/<SOA_Home>/soa/applications setzen
    • TaskListPortlet.ear auswählen
  • Target auf soa_server1 setzen
  • Deployment finalisieren
  • Url testen http://<soaserver>:<soaport>/TaskListPortlet und auf WSRP v2 klicken
    Achtung: die Url in der Dokumentation (1) ist falsch. Diese hier ist richtig.

Security (SAML) konfigurieren

Damit der Consumer (Oracle Portal) den aktuellen Benutzerkontext an das Portlet verlässlich übermitteln kann, müssen beide Parteien eine Vertrauenswürdigkeit in Form eines Keystores und der darin enthaltenen Public / Private Keys ausgemacht haben. Daher wird jeweils ein Keystore für den Consumer (portal.jks) und für den Producer (portlet.jks) angelegt und darin die entsprechenden public bzw. private keys registriert. In der Dokumentation (2) gibt es weitere Hinweise für das Erstellen solcher Keystores. Wir beziehen uns hier auf eine Typical Topology, das heißt 2 verschiedene Domains.

Da noch kein Keystore existiert, wurden diese mit dem keytool aus dem JDK erstellt. Dieser Vorgang ist einmalig, d.h. die Keystores sind universell und können auch auf andere Maschinen übertragen (kopiert) und dort eingesetzt werden. Für das Erstellen eines neuen Keystores empfiehlt es sich, den Pfad auf das Keytool in die Umgebungsvariable PATH aufzunehmen , <jdk_home>/jre/bin . Man kann beide keystores in einer Arbeitssequenz erstellen und dann auf die jeweiligen Server kopieren.

Keystores erstellen

  • keytool -genkeypair -keyalg RSA -dname „cn=portal,dc=oracle,dc=com“ -alias portal -keypass welcome1 -keystore portal.jks -storepass welcome1 -validity 4000
  • keytool -exportcert -v -alias portal -keystore portal.jks -storepass welcome1 -rfc -file portal_public.cer
  • keytool -importcert -alias portal_ws -file portal_public.cer -keystore portlet.jks -storepass welcome1
  • keytool -genkeypair -keyalg RSA -dname „cn=portlet,dc=example,dc=com“ -alias portlet -keypass welcome1 -keystore portlet.jks -storepass welcome1 -validity 4000
  • keytool -exportcert -v -alias portlet -keystore portlet.jks -storepass welcome1 -rfc -file orakay.cer
  • keytool -importcert -alias orakey -file orakay.cer -keystore portal.jks -storepass welcome1

SAML Konfiguration für Portlet Server

  • Kopieren des Keystores portlet.jks auf den Portlet Server (SOA Suite) nach <domain_home>/config/fmwconfig
  • Registrieren des Keystores in FMW Control
    • Weblogic Domain -> <Domain auswählen> -> Security -> Security Provider Configuration

      clip_image002[17]

    • Keystore aufklappen und auf Configure klicken

      clip_image002[19]

    • Formular ausfüllen
      • Keystore Type: Java Key Store (JKS)
      • Keystore Path: ./portlet.jks
      • Password: welcome1 (s.o.)
      • Confirm password : welcome1 (s.o.)
      • Signature Key Alias: portlet
      • Signature Password : welcome1 (s.o.)
      • Confirm password : welcome1 (s.o.)
      • Encryption Key Alias: portlet
      • Crypt Password: welcome1 (s.o.)
      • Confirm password : welcome1 (s.o.)

        clip_image002[21]

    • OK Klicken
    • Domain komplett neu starten (AdminServer, soa_server1)

SAML Konfiguration für Portalserver

  • Kopieren des Keystores portal.jks auf den Portal Server nach <domain_home>/config/fmwconfig
  • Registrieren des Keystores in FMW Control analog wie auf dem Portlet Server nur mit
    • ./portal.jks
    • portal als Alias Namen für die Keys

      Anmerkung: Da auf dem Portalserver der OWSM nicht installiert ist, sollte eigentlich eine Registratur über FMW Control überflüssig sein. Dennoch ist es nicht verkehrt, hier den Keystore zu registrieren., Wichtig ist, das der Keystore auf den Portalserver kopiert wird. Er wird später im Oracle Portal nochmal extra registriert

WSRP Endpoint des TaskList PortletApp sichern

Jetzt muss dem WSRP Service noch eine SAML Policy angehängt werden

  • Auf dem Portlet Server (SOA Suite) FMW Control starten
  • Öffne im Navigationsbaum Application Deployments -> TaskListPortlet
  • Öffne Menü Application Deployment -> Web Services

    clip_image002[23]

  • Wähle WSRP v2 Markup Service
  • Wähle Tabreiter OWSM Policies und klicke auf Attach/Detach

    clip_image002[27]

  • Wähle die Poliy oracle/wss10_saml_token_service_policy aus und klicke auf Attach. Sollte eine andere Policy bereits attached worden sein, bitte diese auswählen und Detach klicken. Speichern mit OK

    clip_image002[29]

  • Bitte den Managed Server (soa_server1) neu starten

Registratur des TaskList Portlets im Oracle Portal

Registratur des Keystores im Portal

  • Anmelden am Portal als Portal Admin (orcladmin)
  • Wähle Administer -> Global Settings

    clip_image002[31]

  • Wähle Tabreiter Keystore
    • Store Path : <absoluter Pfad zum Keystore> /portal.jks
    • Store Password : welcome1
    • Store Type : JKS

      clip_image002[33]

  • Klicke auf OK. Server muss nicht neu gestartet werden

Registratur des Producers

clip_image002[35]

clip_image002[37]

Das war’s. Das Portlet liegt nun im Portlet Repository und muss nur noch auf die gewünschten Seiten platziert werden.

Einschränkungen und sonstige Hinweise

Man darf nicht außer Acht lassen, dass diese Portlet eine Verwendung in Oracle Portal nicht explizit berücksichtigt. WSRPv2 ist der kleinste gemeinsame Nenner und sorgt nur dafür, dass das Portlet grundsätzlich funktionieren sollte. Da WebCenter und Oracle Portal komplett unterschiedliche Basistechnologien verwenden, gibt es naturgemäß auch entsprechende Brüche und Reibungsverluste.

Portlet Parameter

Das TaskList Portlet besitzt diverse Initialisierungsparmeter, die beim Instanzieren eines Portlets optional gesetzt werden und die die Darstellung der Portletinnhalte steuern können (siehe Dokumentation 1 – 36.4 Passing Worklist Parameters) . Werden die Parameter nicht gefüllt, ziehen Default Werte. Im WebCenter Portal kann man die Parameter im Editiermodus des Portlets sehen und füllen. Diese Parameterliste sieht man aber im Oracle Portal nicht, genauer genommen kennt das Oracle Portal den Editiermodus des Portlets gar nicht. Will man dennoch das Verhalten des Portlets über die Portletparameter steuern, so müsste man vielleicht die Default Werte in der portlet.xml der Portlet App überschreiben. Das heißt,

  • TaskListPortlet.ear auspacken
  • WAR Archiv auspacken
  • portlet.xml im WEB-INF Ordner editieren
  • Archive wieder einpacken
  • TaskListPortlet.ear neu deployen

Diese Vorgehensweise ist zum einen nicht verifiziert und zum anderen werden dann die Parameter, die eigentlich nur für die entsprechende Portlet Instanz gelten sollen, für alle Portlet Instanzen gültig. Das kann also bestenfalls nur ein Workaround sein.

Layout / Skins

Da Oracle Portal nichts mit ADF Faces und dem Skinninng zu tun hat, ziehen die normalen Trinidad Skins. Will man ein spezielles Skinning erhalten, müsste man evtl. einen Portalservice bauen (meinetwegen eine Content Komponente), der die notwendigen CSS Definitionen in die HTML Seite legt, oder man muss das Portlet EAR auspacken und eigene, neue Skins hinzufügen, alles wieder einpacken und neu deployen. Auch das ist nicht verifizert und nur eine Lösungsidee.

Dokumentationsfehler

Die Dokumentation (1) weist Fehler auf. Beispielsweise weicht die angegebene Parameterliste von der Realität ab. Es gibt z.B. den Parameter soaURL gar nicht, der die Verbindung zur SOA Suite definieren soll. Das Problem wurde hier so gelöst, dass das Portlet auf dem SOA Server deployt wurde, so dass hier diverse JNDI Einträge und andere Artefakte sowohl für die SOA Suite als auch fürs Portlet gelten.

Es sind einige kleine Unstimmigkeiten, Ungenauigkeiten und Fehler vorhanden (ungenaue Syntax, falsche URL usw.), so dass diese Dokumentation nicht als How To angewendet werden kann, ohne zu verstehen, was der Hintergrund der jeweiligen Aktivität ist.

<DM>

Written by fmtechteam

15/07/2013 at 15:39

Veröffentlicht in Detlef Müller, Portlet, SOA, WebCenter

GlassFish vom Quellcode selber bauen

leave a comment »

Java EE Anwendungsentwickler haben selten den Bedarf, den Application Server, den sie nutzen, selber vom Quelltext zu kompilieren. Das geht sowieso nicht, wenn die Quellen nicht öffentlich zugänglich sind. Falls es sich aber um einen Open-Source Application Server wie GlassFish handelt, der auch viele und gut dokumentierte Erweiterungspunkte anbietet, gerät man früh oder später in die Versuchung, sie für eigene Experimente zu nutzen. Oder man möchte einem bestimmten Problem auf den Grund kommen und den verwendeten Application Server entsprechend anpassen oder instrumentalisieren.

In der Vergangenheit haben mich meistens die langen und komplizierten Build-Instruktionen davon abgeschreckt. Nach der Freigabe von GlassFish 4.0 am 12 Juni habe ich doch einen Versuch unternommen und mit Überraschung festgestellt, dass ich meinen eigenen GlassFish unter 2 Stunden gebacken gekriegt habe, während ich zwischendurch meine RSS-Feeds und Emails auswerten konnte.

Entwicklungsumgebung

Ich arbeite mit Windows 7 64-bit, SP1. Zum Auschecken des GlassFish Source-Code und seine Kompilierung habe ich NetBeans 7.3.1 genutzt, da es eine integrierte Unterstützung für Subversion (der Repository-Typ von GlassFish) und Maven (das GlassFish Build-System) anbietet. Die verwendete JDK-Version war 1.7.0_25.

Auschecken der GlassFish-Sourcen

Der GlassFish Quelcode ist unter https://svn.java.net/svn/glassfish~svn zu erreichen. In NetBeans wird zunächst der Menüpunkt Team –> Subversion –> Checkout selektiert:

image

Im nächsten Schritt kann man durch Browsen von Repository-Folder die Auswahl von Branches, Tags und Revisions der gewünschten GlassFish-Version bestimmen. Man muss sicherstellen, dass das selektierte Verzeichnis die Unterverzeichnisse appserver, copyright und nucleus sowie das pom.xml enthält. Ich habe durch trunk/main und HEAD die aktuellste Entwicklung, die GlassFish 4.0.1 entspricht, ausgewählt:

image

Das Auschecken dauert eine Weile, abhängig von der Bandbreite, die man kriegt. Bei mir hat es etwa 20 min. gedauert.

Der Build-Prozess

Zunächst das GlassFish-Projekt öffnen. NetBeans erkennt es als ein Maven-Projekt anhand der pom.xml Datei:

image

Damit Maven genug Speicher für den GlassFish-Build hat, muss eine Umgebungsvariable am Anfang von <netbeans_home>\java\maven\bin\mvn.bat gesetzt werden:

set MAVEN_OPTS=-Xmx1024M -XX:MaxPermSize=512m

Dann im Context-Menü den Build-Prozess anstoßen:

image

Das dauert etwas länger, bei mir ca. 60 – 80 min., weil alle Maven-Abhängigkeiten heruntergeladen und sämtliche Source-Dateien kompiliert werden müssen. Wenn etwas schief gehen sollte, ist es hilfreich die Maven Debug-Option einzuschalten: Tools –> Options –> Java –> Maven und dann als Global Execution Options –debug setzen. Wenn man hinter einem Proxy ist, muss das Proxy in <user_home>\.m2\settings.xml eingetragen werden, das auch beim Aufklappen von Project Files in NetBeans erscheint. Der Inhlat meiner settings.xml Datei ist folgender(host name geändert!):

<settings>
<proxies>
<proxy>
<id>emea-proxy</id>
<active>true</active>
<protocol>http</protocol>
<host>emea-proxy.com</host>
<port>80</port>
</proxy>
</proxies>
</settings>

Testen der erzeugten GlassFish-Distribution

Wenn der Build-Prozess erfolgreich zu Ende gegangen ist, erscheint die fertige GlassFish-Distribution als zip-File unter main\appserver\distributions\glassfish\target. Man kann nun das zip-Archive in einem Verzeichnis auspacken. Dort wird ein Unterverzeichnis glassfish4 angelegt. Der neue GlassFish kann dann gestartet werden: “glassfish4\bin\asadmin start-domain” und über die Konsole (http://localhost:4848) zum Deployment und Test der eigenen Web-Anwendungen getestet werden. Das einzige was fehlt ist das GlassFish Update Tool.

Detailliertere, wenn auch etwas veraltete Informationen zum Builden von GlassFish vom Quellcode gibt es auf https://wikis.oracle.com/display/GlassFish/FullBuildInstructions.

<PD>

Written by fmtechteam

15/07/2013 at 11:06

Veranstaltung: HTML5 aus Oracle Sicht

leave a comment »

Veranstalter: JUG Saxony

Sprecher: Peter Doschkinow (Oracle Deutschland B.V. & Co KG) und Shaun Smith (Oracle Canada)
Ort: HTW Dresden, Friedrich-List-Platz 1, 01069 Dresden, Hörsaal Z 211
Datum: 05. Juli 2013, 18:00 – 21:00 Uhr

HTML5 und Bleeding-Edge Java Enterprise Technologien aus Oracle Sicht
Sprecher: Peter Doschkinow, Oracle Deutschland

Kann Java für HTML5 genutzt werden? In dieser Veranstaltung wird gezeigt wie aktuelle Java Technologien die Erstellung von HTML5 Anwendungen vereinfachen. Zu ihnen gehören auf der Server-Seite JAX-RS, WebSocket, Server Sent Events und JSON API. Auf der Client-Seite ermöglicht JavaFX die Entwicklung von anspruchsvollen hybriden Java-JavaScript HTML5 Clients. Und NetBeans 7.3 verblüfft mit vertieften HTML5 Unterstützung.

From NoSQL to HTML5 (Vortrag in Englisch)
Sprecher: Shaun Smith, Oracle Canada

Data is the fuel enterprises run on and the data access requirements of today’s Java applications have grown to include JSON REST services for HTML5 and mobile clients, NoSQL database persistence, and multi-tenancy. Most developers use an assortment of independent frameworks to cope with each of these disparate requirements often having to copy and transform data from one format into another as it makes its way from database to browser and back again. Or they have to craft custom extensions to frameworks to provide features they were never designed to support. Meanwhile EclipseLink, best known as an open source provider of JPA for database access on the backend and JAXB for web services on the front end, has evolved to simplify the entire path from front to back. EclipseLink has added JSON binding to support HTML5 clients, zero code JAX-RS REST service support, NoSQL database persistence, and has integrated JPA with JAXB to make it easy to move data from database to XML or JSON and back again without data loss.

In this session we’ll dive into EclipseLink’s new services and build an application that goes from browser to database leveraging EclipseLink both in the back end for data persistence and on the front end for JSON over REST to HTML5 and JavaScript clients.

Anmeldung hier.

<MB>

Written by fmtechteam

01/07/2013 at 17:09