Oracle ADF Powerkurs - 15. Dezember in Bern

Am 15. Dezember findet in Bern ein 1-tägiger Powerkurs zum Thema Oracle ADF Entwicklung statt. Durchgeführt von Frank Nimpius, dem Experten der Oracle für das Thema. Weitere Details und Anmeldung unter: http://www.ipt.ch/veranstaltungen/javaee-applikationsentwicklung/.

JavaEE-Applikationsentwicklung

Schnell und effizient mit Oracle ADF

Am 15. Dezember 2011 in Bern

Suchen Sie ein effizientes Framework für die Entwicklung Ihrer Rich-Enterprise-Applications im Web- und Mobile-Bereich? Oder planen Sie eine Rapid-Application-Development-Initiative in Ihrer Organisation? Wir zeigen Ihnen an diesem Event, wie Sie mit Oracle ADF signifikante Effizienz- und Qualitätssteigerungen in der Java EE Applikationsentwicklung erreichen können. Ergreifen Sie die einmalige Gelegenheit Frank Nimphius persönlich kennenzulernen, den Experten für Oracle ADF im deutschsprachigen Raum.

 

Nach einer Einführung in die Herausforderungen bei der Applikationsentwicklung zeigen wir Ihnen, wie das auf Standards basierende End-to-End Framework Oracle ADF aufgebaut ist. Dann vergleichen wir es mit anderen Frameworks für die Applikationsentwicklung und zeigen auf, wie Oracle ADF Sie bei der Realisierung der Rapid-Application-Development-Konzepte unterstützt.

Die Demo nach der Mittagspause setzt die am Morgen präsentierten Ansätze praktisch um und zeigt wie schnell eine Rich-Enterprise-Application mit den visuellen und deklarativen Werkzeugen der ADF-Plattform entwickelt werden kann.

First-class citizens and splendid isolation

Michael Poulin did a review of our SOA Design Patterns book:

Thomas Rischbeck says: “The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants”. I would welcome this transparency if it were not based on intelligent routing and data enrichment having its own policies on the interaction between the participant. In SOA, we have a mechanism that regulates the interactions – Service Contract – and it is not seemed to be considered by the ESB at all.

Michaels seems to imply that the ESB doesn't honor service contracts at all. I get the impression that Michael also sees an ESB as a magical integration switchbox in the middle of the enterprise. This makes Michael feel uneasy – which I can understand very well.

There’s also another way of looking at an ESB: You could think about it as an opaque substrate for hosting "facade" services – which are fully-fledged, first-class citizens in the SOA world. Like every other service, such facade services have a formal interface (and a less formal contract which is a superset of the interface (as James Watson says. While I’d admit that there can be quibbles about business logic on the ESB – it doesn’t “break […] the service contract between the service consumer and the service provider”, as Michael thinks. The consumer wouldn’t’ reason about the actual backend provider but only about the ESB-exposed endpoint it communicates with. The rest is implementation details, so to say.


From this point of view the ESB becomes opaque. It cannot violate a service contract because it isolates whatever backend services are multiplexed through the ESB. This splendid isolation renders numerous benefits. For example, services can be normalized according to enterprise requirements; they may also enforce coarse-grain security and shield backend services from certain attack vectors. Many rings of defense is a security best practice since the middle ages.

Cheers, Thomas.