Analyse der Software-Qualität mit SonarQube

Was ist SonarQube?

SonarQube ist ein Werkzeug, das mittels statischer Code-Analyse technische Qualitätsmerkmale von Software erfasst und diese in einer übersichtlichen Oberfläche darstellt. Neben der Analyse von Java-Quellcode können mittels diverser Plugins auch JavaScript, Groovy, PHP, C# und viele weitere Sprachen analysiert werden. Die offizielle SonarQube Seite listet die verfügbaren Plugins auf. In diesem Artikel beschränke ich mich auf die Analyse von Java-Projekten mittels SonarQube.

SonarQube besteht aus den drei folgenden Komponenten:

  1. Das Analyse-Modul untersucht den Quellcode. Zum Aufruf der Analyse existieren Plugins für Apache Maven und Apache Ant. Zusätzlich existiert ein eigenständiger SonarQube-Runner. Mittels dieser Tools kann die Quellcode-Analyse innerhalb des Builds (beispielsweise in einem CI-System) automatisiert aufgerufen werden.
  2. Die Analyse-Ergebnisse werden in einer Datenbank gespeichert, so dass diese im Nachhinein ausgewertet werden können. Dabei wird neben den jeweils neusten Analyse-Ergebnissen auch eine Historie gespeichert, sodass untersucht werden kann, wie sich die Qualitätsmerkmale im Laufe der Zeit ändern. SonarQube kann mit diversen relationalen Datenbanken betrieben werden.
  3. Eine Webanwendung, mittels der die Analyse-Ergebnisse betrachtet werden können. Die einzelnen Ergebnisse werden zunächst übersichtlich innerhalb eines konfigurierbaren Dashboards angezeigt. Von dieser Übersicht kann man über eine Drill-Down-Funktion weitere Details anzeigen lassen.

SonarQube analysiert den Programm-Code hinsichtlich der folgenden Qualitätsbereiche (Quelle sonarqube.org) :

  • Softwarearchitektur & Softwaredesign
  • Duplikation
  • Unit tests
  • Komplexität
  • Potenzielle Fehler
  • Quellcode-Richtlinien
  • Kommentare

Intern verwendet SonarQube die folgenden Werkzeuge für die Analyse:

  • In SonarQube 4.4 existieren noch Rules, welche die Tools Checkstyle, PMD, Findbugs verwenden. Diese Rules werden von dem Hersteller nach und nach abgelöst durch Regeln, welche mit einer SonarQube eigenen Rules-Engine geprüft werden. (Details: SonarQube Blog)
  • Darüber hinaus werden auch Analyse-Ergebnisse von diversen Tools zur Ermittlung der Testabdeckung eingelesen und in der SonarQube Datenbank gespeichert. Diese können ebenfalls in der Webanwendung betrachtet werden.

SonarQube Webanwendung

Einstiegspunkt in eine Analyse innerhalb der Webanwendung ist das Dashboard. Im linken Bereich werden einige Meta-Informationen wie Anzahl an Klassen, Dateien, Methoden etc. dargestellt. Rechts finden sich die Ergebnisse der Regel-Überprüfungen, direkt darunter Metriken bzgl. der Abhängigkeiten zwischen Dateien.

01_dashboard

In der Ansicht des Dashboards können die Ergebnisse der letzten Analyse mit vorherigen Analysen verglichen werden. So kann schnell erkannt werden, ob sich die Ergebnisse verschlechtern oder verbessern. Auswählbar sind die Änderungen seit der vorherigen Analyse, Unterschiede über die letzten 30 Tage oder Änderungen seit der letzten Version. Die bei der Analyse verwendete Versionsnummer wird bei Maven-Projekten aus dem Version Feld der POM entnommen. Bei anderen Projektarten wird die Versionsnummer bei der Analyse über das Property sonar.projectVersion festgelegt.

In den folgenden Abschnitten werden einige einzelne Analyse-Ergebnisse exemplarisch dargestellt.

Anzeige der Testabdeckung

Im Dashboard werden die Ergebnisse der Testabdeckung angezeigt. Dabei wird unterschieden zwischen Unit- und Integrations-Tests.

02_testabdeckung

Abbildung 1: Anzeige der Testabdeckung eines Projektes

Die Anzeige der Testabdeckung setzt eine korrekte Projekt-Konfiguration voraus. Um bei der Ausführung der Unit- und Integrationstests die Daten zur Testabdeckung aufzeichnen zu können, muss die Java Virtual Maschine entsprechend instrumentiert werden. Hierzu kann z. B. JaCoCo verwendet werden. Eine Beispiel-Konfiguration und Details zum Aufruf der Analyse sind in dem GitHub-Repository sonar-examples von SonarSource  und in der SonarQube Dokumentation (Konfiguration für Unit-Tests, Konfiguration für Integration Tests) zu finden.

Bewertung

Bei dieser Metrik muss stets beachtet werden, dass eine hohe Testabdeckung alleine noch nicht zwangsläufig eine gute Qualität der Software bedeutet. Beispielsweise ist es möglich, “Tests” zu schreiben, die kein einziges Assert-Statement enthalten. Weiterhin müssen Tests natürlich auch fachlich korrekt sein, was selbstverständlich nicht von einer Software überprüft werden kann.

Anzeige der Regelverletzungen

Die Regelverletzungen werden nach ihrem Schweregrad gruppiert. Nach Auswahl eines Schweregrads werden die verletzten Regeln angezeigt.

Das Bespiel zeigt einige Regeln, welche von SonarQube als Kritisch angesehen werden:

03_regelverletzungen

Nach Auswahl einer Klasse wird diese – zusammen mit den Regelverletzungen – im unteren Bereich dargestellt:

04_regelverletzungen

Praktisch ist die gute Navigierbarkeit innerhalb der Anwendung. So ist es möglich, andere Verletzungen innerhalb der gerade angezeigten Klasse anzusehen. Zur Erhöhung der Übersichtlichkeit kann die Klasse auch in einem separaten Fenster geöffnet werden.

Komplexität

SonarQube ermittelt die zyklomatische Komplexität (Mc-Cabe-Metrik) des untersuchten Projektes. Zur Bestimmung der Metrik wird die Anzahl der folgenden Schlüsselwörter je Methode bzw. je Klasse gezählt:

  • if, for, while, case, catch, throw, return (ausgenommen des letzten return-Statements einer Methode), &&, ||, ?

Es sollte generell eine kleine Zahl und damit geringe Komplexität von Methoden angestrebt werden, da angenommen wird, dass eine Methode umso schwerer von Menschen verstanden werden kann, je höher die Zahl ist.

Bewertung

Die Metrik der zyklomatischen Komplexität ist nicht unumstritten. Ein Switch-Statement mit vielen Case-Anweisungen kann z.B. trotz hoher Komplexitäts-Zahl dennoch übersichtlich sein.

Im Dashboard werden die Durchschnittswerte der Komplexität angezeigt:

05_komplexität

Die Gesamtsumme der Komplexität stellt kein Qualitätsmerkmal dar, sondern gibt einen generellen Hinweis auf die Projektgröße. Die Durchschnittswerte der Komplexität je Methode sind alleine nicht sehr aussagekräftig. So wurde im Beispiel ein Projekt gezeigt, in dem unter anderem viele via Hibernate persistierte Domain-Objekte vorhanden sind, welche zumeist einfache Datenhalte-Objekte sind. Diese reduzieren natürlich die durchschnittliche Komplexität. (Laut Martin Fowler sind solche  „blutarmen“ Domain-Modelle eine Anti-Pattern. Siehe auch AnemicDomainModel)

Mittels Klick auf eine der Komplexitätszahlen kann zu der der Detail-Ansicht navigiert werden, in der weiter durch Packages bis hinunter zu den einzelnen Klassen navigiert werden kann.

Hotspots

Um schnell einen Überblick über die Qualität einer Software zu erhalten, eignet sich der Bereich Hotspot.

Beispiele:

  • Hotspot per nicht abgedeckter Quellcodezeilen
  • Hotspot per Komplexität je Klasse
  • Hotspot per Komplexität je Methode
  • Meist verletzte Ressource
  • etc.

Design

Im Dashboard werden mittels der “Package Design”-Komponente Informationen zu Abhängigkeiten zwischen den Packages und zu zirkulären Abhängigkeiten angezeigt:

08_design

Von dort gelangt man durch Klick auf eine Zahl direkt zur “Dependency Structure Matrix“, in der die Abhängigkeiten der Komponenten (d. h. der Java Packages) dargestellt werden. Mit Hilfe dieser Matrix können zirkuläre Abhängigkeiten im Projekt gefunden werden. Gutes Software-Design vermeidet generell zyklische Abhängigkeiten zwischen einzelnen Packages.

09_dsm_design

Das Diagramm enthält für jedes Package je eine Zeile (mit Beschriftung) und ebenfalls eine korrespondiere Spalte. Innerhalb des Diagramms wird dargestellt, wie viele Klassen eines Packages Klassen aus anderen Packages verwenden. Mögliche zirkuläre Abhängigkeiten können an den rot hinterlegten Zahlen im oberen rechten Bereich der Matrix erkannt werden.

Beispiel

Durch Doppelklick auf eine Zahl (im Beispiel rote “1” in der Zeile “vorhaben”) werden unterhalb des Diagramms weitere Details der Abhängigkeiten der beiden Packages vorhaben und imp dargestellt:

09_dsm_design_uses

Welche Klassen aus dem Package imp (links) verwenden welche Klassen aus dem Package vorhaben (rechts)

Weitere Details zur Dependency Structure Matrix sind in der SonarQube Dokumentation auf der Seite Cycles – Dependency Structure Matrix enthalten.

Hinweise für den praktischen Einsatz von SonarQube

Definition von projektspezifischen Qualitätsprofilen

Nachdem die SonarQube Analyse eines größeren Projektes mit langer Historie erstmalig ausgeführt wurde, sind häufig sehr viele Metriken diverser Regeln verletzt. In einem großen Projekt können diese Verletzungen nicht unmittelbar durch entsprechende Änderung im Quellcode behoben werden. Dies ist auch nicht in jedem Projekt sinnvoll und notwendig.

Vor der regelmäßigen Verwendung von SonarQube sollten sich die Entwickler des Projektes daher zunächst auf eine Menge von Regeln einigen, die im Projekt eingehalten werden sollen. Dazu kann auch gehören, dass man die Kritikalität einzelner Regeln entsprechend der konkreten Projekt-Notwendigkeiten erhöht oder verringert.

Für die Konfiguration von solchen projektspezifischen Regeln bietet SonarQube den Einsatz von sogenannten “Quality-Profiles” an. Durch Qualitätsprofile kann festgelegt werden, welche Regeln für die Analyse verwendet werden sollen und mit welcher Kritikalität Regelverletzungen protokoliert werden sollen.

Wird bei der SonarQube-Analyse kein Qualitätsprofil angegeben, verwendet SonarQube per Default das Profil Sonar-Way. Alternativ kann durch Setzen des Properties sonar.profile der Name des gewünschten Profils beim Aufruf der Analyse angegeben werden.

Zur Pflege eines eigenen Profils kann ein bereits vorhandenes Profil kopiert und angepasst werden. Die Anpassung eines Profils wird dabei innerhalb des Bereichs “Rules” der Anwendung vorgenommen:

10_rules

Bei der Auswahl von Regeln sollte auch geprüft werden, ob im verwendeten Profil deaktivierte Regeln (Filter Activation: Inactive setzten!) existieren, welche im Projekt interessant sein könnten.

Unterdrückung von Validierungen

Zur Unterdrückung von Validierungen bietet SonarQube die folgenden Möglichkeiten:

  • Einfügen des Kommentars //NOSONAR am Zeilenende, wodurch die Analyse für diese Zeile komplett verhindert wird.
  • Annotation einer Methode mittels @SuppressWarnings(“all”), um die Analyse der gesamten Methode zu unterbinden.
  • Eine konkreter Validierungsfehler kann auch mittels der Webanwendung als “falsch positiv” deklariert werden:

11_falschpositiv

Anzeige von Änderungen

Bei der Anzeige der Regelverletzung können entweder alle Verletzungen angezeigt werden oder nur das Delta zwischen verschiedenen Analyse-Zeitpunkten. Beispielsweise ist die Anzeige der Veränderung seit der Analyse des letzten Release sinnvoll, um rechtzeitig (z. B. noch vor der Auslieferung eines Releases) erkennen zu können, wenn sich die Qualität (hinsichtlich der Metriken) in der aktuellen Version verschlechtert.

Anzeige aller Verletzungen:

12_aenderungen_1

Anzeige der Veränderungen innerhalb der letzten 30 Tage:

13_aenderungen_2

Bei der Anzeige der Regeln werden allerdings nur die Verschlechterungen in der Delta-Anzeige berücksichtigt. Dieser Umstand kann – je nach Persönlichkeit des Entwicklers – unter Umständen auch demotivierend sein.

Umso schöner und motivierender kann daher die Anzeige der Änderung im Dashboard sein:

14_aenderungen_dashboard

Eine Anzeige des Analyseverlaufs über verschiedene Versionen bietet die Seite “Historisch” (Deutsche Version)  bzw. “Time Machine” (Englische Version):

15_timemachine

Hinweis: Die Integration-Tests des Projektes wurden ohne Erfassung der Testabdeckung ausgeführt.

Quality Gates und das Build-Breaker Plugin

Mittels Quality Gates können Grenzwerte definiert werden, welche im Projekt nicht überschritten werden dürfen. Durch die Verwendung des Build-Breaker Plugins ist es möglich, den Build fehlschlagen zu lassen, wenn die im Quality Gate definierten Anforderungen nicht erfüllt wurden.

Fazit

Mit SonarQube wird und ein reichhaltiges und mächtiges Werkzeug für die Qualitätsanalyse von Software-Projekten an die Hand gegeben. Richtig konfiguriert und eingesetzt, liefert SonarQube Informationen zu Schwachstellen in Software-Projekten, welche für die daraus geleitete Qualitätsverbesserung eingesetzt werden können.

Bei der Verwendung von SonarQube sollte jedoch immer im Auge behalten werden, welches Ziel mit der Analyse erreicht werden soll. Im Projektteam wird man daher über die verschiedenen Metriken und Regeln diskutieren und sich nach der (hoffentlich eingetretenen) Einigung ein eigenes Qualitätsprofil definieren, welches im Zuge des weiteren Projektverlaufs verwendet wird.

Weiterhin führt die Analyse alleine nicht automatisch zu besserer Qualität. So sind nach der Identifizierung von Schwachstellen im Code selbstverständlich entsprechende Refactoring-Maßnahmen notwendig.

Darüber hinaus sollte das manuelle, durch einen Projektteam-Kollegen durchgeführte Quellcode-Review auch trotz SonarQube weiter durchgeführt werden, um auch Qualität hinsichtlich fachlicher Korrektheit und guter Verständlichkeit (bspw. Benennung von Klassen, Methoden und Variablen) sicherstellen zu können.

Kategorien:Uncategorized

Microservices: Not a first principle, but an emerging design

Thoughts by: Sven Bernhardt, Richard Attemeyer, Torsten Winterberg, Stefan Kühnlein, Stefan Scheidt


Up to now (see our article on Microservices from a SOA perspective) we considered Microservices as an architectural pattern: We discussed the statical structure of your system and the consequences. It seems nowadays that you design explicitely for a microservices architecture. We believe that this is the wrong way to approach the problem.
Don’t build the system with the microservices pattern in mind, but ask more important questions about how you want to develop, what are the principles to follow when building a new system… and a microservices architecture emerges naturally. Weiterlesen…

Using JMS Unit-of-Order in a High Availability Environment

Abstract

 

The WLS JMS Unit-of-Order feature (UOO) is well documented in various papers and blogs; it mainly enables numerous message producer to group messages into a single unit that is processed sequentially in the order the messages were created. Until message processing for a message is complete, the remaining unprocessed messages for that Unit-of-Order are blocked. This behavior makes the usage of UOO essential in cases that a specific processing order must be adhered to.

But what happens in a High Availability Environment using distributed queues, when a node breaks down? How can the processing order be guaranteed under these circumstances? This article is a practice report answering these questions.
 

Preparing the test

 

For our tests we are using an OSB cluster with two nodes and an Admin server in the Version 11.1.1.7; the WLS is in the version 10.3.6.

Configuring the JMS Server

Use the Admin Console (Admin Server) to perform the following steps:

  1. Define a data source (e.g. jdbc/jmsDS)
  2. Define a persistence store on each OSB Cluster-Node using the data source from Step1

e.g.:

- JDBCStore4JMS1 targets osb_server1 (migratable)

- JDBCStore4JMS2 targets osb_server2 (migratable)

pic1

  1. Define a JMS Server on each OSB Cluster Node targeting a migratable target. Note: When a JMS server is targeted to a migratable target, you have to use a custom persistence store which must be configured and targeted to the same migratable target.

pic2

  1. Define a JMS Module targeting both JMS Servers; define an appropriate connection factory and a distributed queue.

pic3

pic4

  1. Pointing at the distributed queue, you can now see both queues and the messages holding by them

pic5
 

Performing the test

 

A message producer sends 14 messages using UOO KEY1, KEY2, and KEY3 in the following way:

  • 3 messages with UOO: KEY1
  • 2 messages with UOO: KEY2
  • 9 messages with UOO: KEY3

The following was observed:

  1. The messages were received by the queue and distributed to the configured persistence stores
  2. Messages with the same UOO were stored in the same persistence store
  3. After a cluster node was shut down, all new messages containing the same UOO as those processed by the JMS Server (and the persistence store) pinned to the disconnected node, have been rejected; all other messages continued to be enqueued (and dequeued)
  4. After the migration of the JMS Server (and its persistence store) which was pinned to the shutdown node, to another working node – which took approximately 10 sec.- all rejected messages were processed and the distributed queue regained fully functionality.

 

Conclusion

 

The processing order of messages can be guaranteed in a clustered Environment when using JMS Unit-Of-Order.

If a cluster node crashes the distributed queue is not able to receive messages of a certain UOO for approximately 10 sec. which might be for the most cases a sufficient small amount of time.

Kategorien:Weblogic Server Schlagworte: , ,

Microservices architectures – Thoughts from a SOA perspective

Thoughts by: Sven Bernhardt, Richard Attemeyer, Torsten Winterberg, Stefan Kühnlein, Stefan Scheidt


 

A frequently discussed topic these days is the Micorservices architectural paradigm. Discussions on various internet blogs and forums are showing the trend that proponents of this approach are not tired of emphasizing why Microservices are different to a holistic SOA approach, when dealing with breaking up or avoiding monolithic software architectures.

For this reason it’s time for the Cattle Crew team, to take a closer look on this arising architectural style and the corresponding discussions from a different perspective.

Microservices Architectures

Amongst others Martin Fowler published a blog about what is characteristic for Microservices and applications build on the foundation of this architectural style [1].  According to this and other blog posts (see also [2], [3]), the goal of a Microservices approach is to avoid software systems to become monolithic, inflexible and hardly manageable, by splitting a system into modular, lightweight and maximum cohesive services. Applications build on this architecture should ensure the agility regarding changes caused by changed business requirements, because affected services of an application can simply be adapted and be redeployed independently from other components.

Effectively a Microservice is a in itself cohesive, atomic application, which fulfills a dedicated purpose. Therefore it encapsulates all needed elements, e.g. UIs, logic components, may also have its own separated persistent store and may run in a separate JVM, to ensure as less impairment to other services as possible. Furthermore the implementation technologies for a specific service may vary. For each service the best-fitting technology should be used; there should be no restrictions regarding the used technologies.

To ensure consistency as well as compatibility with already existing components in case of changes and to guarantee seamless release management of changed components, a Continuous Delivery procedure is indispensable for succeeding. In addition the implementation efficiency benefits from the Microservices approach, because different components may be developed in parallel. Communication between the services, if needed, is done via lightweight protocols such as HTTP. Well defined interfaces are depicting the service contracts.

Where there is light, there is also shadow…

One of the basic questions, we asked ourselves when discussing the Microservices approach, is how to determine respectively which metrics to use for evaluating, if a service is a Micorservice or not. Resulting from that it would be interesting what if it is no longer a Microservice: is it directly a monolithic service?

A clear definition about what are the differentiating and unique characteristics of a Microservice cannot be found. Metrics like lines of code or number of classes are no appropriate characteristics, so something spongy, like specific business functionality has to be taken as a distinctive mark for a real Microservice. But that’s not really measureable…

Besides the missing clarification about the Microservice term as such, building business applications using a modular Microservices architecture means a higher complexity than when using a classical monolithic approach. From conception to delivery to the operating this higher complexity may raise the following challenges:

  • Right level of service granularity; not to coarse grained, not to fine-grained
  • Comprehensible service distribution for scalability reasons and the corresponding monitoring
  • Complex testing procedures because of loose coupling and service distribution
  • Consistent and tolerant Error-handling, because a referenced service might be down for maintenance reasons (Timeouts, Retry mechanisms, etc.)
  • Reliable message delivery
  • Consistent transaction handling, because of cross-service communications using non-transactional protocols like HTTP mean the establishment of complex compensation mechanisms
  • Guarantee of data synchronization and consistency, when services have their own and exclusive persistent stores
  • Sophisticated Service Lifecycle Management, because every service has its own lifecycle including challenges like how to deal with incompatible interface changes

Another risk we see with a naive implementation of the Micorservices architecture is a fall-back to the days of distributed objects: Calling a magnitude of services is not a good idea because of latency and (missing) stability.

Microservices and SOA

When dealing with the Microservices approach it is conspicuous that at least one paragraph could often be found, stating something like “Microservices vs. SOA”, where it is depicted that Microservices and SOA are conceptually different. In this context the idea of SOA is often reduced to technology terms like WS* or ESB and therefore referred to as heavyweights. This definition of SOA only covers possible implementation details, because from a conceptual perspective SOA is also an architectural paradigm, making no premises regarding implementation details or the corresponding technologies to use for a concrete SOA implementation.

When looking at the sections before, describing Microservices-based architectures and its challenges, it can be stated that very similar concepts and challenges arise in SOA-style architectures, because characteristics for Service-oriented architectures are loose-coupling, standard-based and stable service contracts, distributed services and flexibility as well as agility regarding changing business requirements. The resulting challenges are nearly the same. As a reason for this, in our opinion the both approaches aren’t so different essentially.

SOA-style architectures historically often use SOAP-style communications. But regarding this fact we are observing a change: the number REST-style SOA services is growing. A trend which is mainly influenced by the increasing need of multi-channel support, e.g. for mobile devices, where REST-style communications by using a JSON-based data format is the preferred variant. The big software vendors, e.g. Oracle, also recognize this trend and therefore have extended out-of-the-box support for REST services.

In system architectures that are based on the SOA paradigm, an ESB is often used to integrate different enterprise applications. Classically it cares about routings, protocol as well as data transformations and service virtualization. So point-to-point integrations between systems can be avoided and makes an IT system landscape more flexible regarding adding new applications as well as services. In our opinion this can’t be called heavyweight and is indispensable for increasing agility.

Furthermore the microservices proponents do not say any word about service governance. This is also ok for some sorts of SOA services. We often differentiate services into public and private services. Systems consisting of multiple components are often organized as a set of collaborating private services [4]. These interfaces are not published enterprise-wide and must therefore not adhere to more strict policies applied to public services. The offical / public interfaces of a system are in contrast published as public services.

Thus from our perspectives, Microservices are nothing new, but rather an implementation of the concept of private services.

Summary

Microservices architectures are primarily focusing on a local, application-based scope and provide a very flexible as well as modular approach for developing easy-to-extend applications. In summary it can be said that the Microservices architectural paradigm seams to deliver great benefits though it must be stated that the approach is not a completely new concept. Compared to that a SOA approach has a farsighted, global scope aiming at the enterprise level. From a SOA perspective, Microservices could be understood as private services, not necessarily exposing their functionalities for reusing them in other systems or services. But that is ok, because in service-oriented architectures one does not expose a service, when there is no need – which means no need for reuse in other applications or services – for it.

Taking all points discussed in this article into account, we would recommend that discussions about differences between Microservices and SOA should be avoided. Instead it should be evaluated how and if a coexistence of these two very similar approaches is possible to deliver the most valuable benefit for system architectures as possible, making IT system landscapes more flexible and therefore promoting business agility.

[1] http://martinfowler.com/articles/microservices.html

[2] http://microservices.io/patterns/microservices.html

[3] http://www.infoq.com/articles/microservices-intro

[4] http://www.oracle.com/technetwork/articles/soa/ind-soa-canonizing-language-1957510.html

 

Kategorien:Architecture Schlagworte: , ,

Eindrücke vom ADF Community Meeting

Am gestrigen Dienstag fand das Meeting der Deutschen ADF Community im CVC der Oracle Niederlassung in Berlin statt. Der Fokus lag dieses Mal weniger auf den technischen Feinheiten des Frameworks, sondern auf dem Thema „Vertrieb“. Aufgrund des Themenschwerpunkts waren neben altbekannten Teilnehmern auch viele neue Gesichter aus den Tiefen des Vertriebs der verschiedenen Partnerunternehmen anwesend. OPITZ CONSULTING war gleich mit drei Teilnehmern vertreten und gab somit schon alleine durch die Mannstärke ein eindeutiges Commitment zu ADF ab. Das bunte Programm ließ keine Wünsche offen.

Wie agil die ADF Community auf neue Anforderungen reagieren kann, zeigte bereits der erste Vortrag zum Thema „Enterprise Mobility“. Aufgrund von Schwierigkeiten mit der Flugverbindung konnte der Referent nicht physisch anwesend sein, so dass kurzerhand eine Web- und Telefonkonferenz aufgesetzt wurde. Die Runde war sich weitestgehend einig, dass mobile Lösungen im Enterprise-Bereich in Zukunft eine stärkere Rolle einnehmen werden und sieht ADF in diesem Zusammenhang durch das Mobile Application Framework (MAF) und den Zukauf von Bitzer gut aufgestellt. Diesem Trend folgend drehte sich auch der zweite Beitrag dieses Tages auf um das Thema MAF. Michael Krebs von esentri referierte dabei sehr bildlich über „Oracle MAF und die Positionierung einer mobilen Unternehmensstrategie“. Am Nachmittag folgten dann noch Vorträge zu „ADF im Kontext der Oracle Fusion Middleware“ (Ingo Prestel, Oracle), „Oracle ADF und Forms-Modernisierung“ (Andreas Gaede, PITSS).

IMG_1028

Jochen Rieg von virtual7 moderierte eine interaktive Session zu „Oracle ADF als Basis für moderne Unternehmens-Anwendungen“. Dabei wurden von den Teilnehmern fachliche Einsatzszenarien, USPs von ADF, sowie eine Statistik zu Branchen in denen ADF Projekte bereits umgesetzt werden, erarbeitet. Es wurde in diesem Zusammenhang deutlich, dass derzeit die meisten Partnerunternehmen Projekte für Kunden im „public sector“ umsetzen. Da wir die Statistik selbst „gefälscht“ hatten gab es keinen Grund ihr in diesem Punkt nicht zu trauen. Neben den spannenden Sessions diskutierte die Runde sehr lebhaft und konstruktiv über mögliche Vertriebswege von ADF. Die Teilnehmer waren sich einig, dass die Technologie deutliche Vorteile im Vergleich zu anderen Frameworks aufweist, im Markt aber noch zu unbekannt sei. Die zahlreichen Aktivitäten der ADF Community werden in Zukunft sicher ihren Teil dazu beitragen, dies zu ändern. Erste Anzeichen sind in diesem Bereich schon wahrzunehmen. So wird beispielsweise bei der diesjährigen Konferenz der Deutschen Oracle Anwendergruppe zum ersten Mal ein eigener Slot für die ADF Community reserviert.

Alles in allem kann man wieder einmal von einem sehr gelungenen Treffen der ADF Community sprechen. Die thematische Ausrichtung auf das Thema „Vertrieb“ sorgte für interessante Diskussionen. Wir freuen uns, Teil dieser lebendigen Community zu sein und werden gerne am nächsten Community-Meeting teilnehmen.

Kategorien:Uncategorized

SOA & BPM Suite 12c – Erfahrungsberichte und Live Demos für Architekten und Entwickler

  Die neuen Oracle 12c Versionen sind da!
 

SOA Suite & BPM Suite Launch Events vom Oracle Platinum Partner OPITZ CONSULTING

    23.10.14 Düsseldorf | 28.10.14 München

Sehr geehrte Damen und Herren,

die SOA Suite ist Oracle’s Lösung für Systemintegrationen jeglicher Art. Die BPM Suite bietet alles zur Prozessautomatisierung und zum Bau von Workflowlösungen mit BPMN 2.0.

Erleben Sie in einem komprimierten Abendprogramm in lockerer Atmosphäre bei Getränken, Snacks und einem anschließenden Abendessen, warum wir als Projekthaus die neuen 12c Versionen beider Suiten für einen großen Wurf halten.

Wir bleiben dabei marketingfrei, zeigen viele Live Demos und diskutieren in den Pausen gerne bis in beliebige Tiefen der neuen Produkte.

Es erwarten Sie diese Themen:

  • Oracle SOA Suite & BPM Suite 12c: Was bringen mir die neuen Versionen?
  • Neue Features SOA Suite: Erfahrungen aus einem SOA Suite 11g Upgrade auf 12c
  • BPM Suite 12c live: Workflows erstellen auch mit komplexen Formularen
  • Internet der Dinge: Live Demo mit Raspberry Pi, SOA Suite, BPM Suite und Oracle Event Processing 12c

__________________________________________________________________

Jetzt kostenfrei anmelden:
23. Oktober 2014, Oracle Deutschland, Geschäftsstelle Düsseldorf
28. Oktober 2014, Oracle Deutschland, Geschäftsstelle München

Details und Anmeldung
__________________________________________________________________

Wir freuen uns auf Ihren Besuch!

Mit herzlichen Grüßen

Torsten Winterberg
Business Development & Innovation
OPITZ CONSULTING Deutschland GmbH
Torsten Winterberg, Business Development & Innovation, OPITZ CONSULTING


OPITZ CONSULTING

OPITZ CONSULTING, Oracle PlatinumPartner

Short recap on OFM Summer Camps 2014

Last week the Oracle Fusion Middleware summer camps took place in Lisbon. More than 100 participants attended the event, learning much new stuff about new features and enhancements, arriving with the recently available FMW 12c release. In four parallel tracks the highlights of the new major release were presented to the attendees; hands-on labs allows to get a first impression regarding the new platform features and the markedly increased productivity delivered by the enhanced, consolidated tooling.

The four tracks had different focuses, regarding the new features of the 12c release of Oracle Middleware platform:

  • SOA 12c – focusing on application integration, including Oracle Managed File Transfer (MFT), and fast data with Oracle Event Processing (OEP)
  • BPM 12c – focusing on Business Process Management, the new enhanced Business Activity Monitoring (BAM) and Adaptive Case Management (ACM)
  • SOA/BPM 12c (Fast track) – Combined track, covering the most important enhancements and concepts with reference to SOA and BPM 12c
  • Mobile Application Framework (MAF) Hackathon – Development of mobile applications using the newly released MAF (formerly known as ADF mobile)

The main topics addressed by the new OFM 12c release are:

  • Cloud integration
  • Mobile integration
  • Developer’s performance
  • Industrial SOA

Cloud integration

Integrating Cloud solutions in grown IT system landscapes is complex. With SOA Suite 12c, Oracle provides a coherent and simple approach for integrating enterprise applications with existing cloud solutions. Therefore new  JCA-based cloud adapters, e..g. for integrating with Salesforce, as well as a Cloud SDK are available. Service Bus might be used in this context to care about transformation, routing and forms the backbone of a future-oriented, flexible as well as scalable cloud application architecture.

Mobile integration

Mobile-enablement of enterprise applications is a key requirement and a necessity for application acceptance today. The new JCA REST adapter can be used to easily REST-enable existing applications. In combination with Oracle MAF and Service Bus, Oracle provides a complete Mobile Suite, where seamless development of new mobile innovations can be done.

Developer’s performance

To enhance development performance, the new SOA and BPM Quickinstalls are introduced. Using those allows the developers to have a complete SOA or BPM environment installed in 15 minutes (see the blog post of my colleague). Furthermore new debugging possibilities, different templating mechanisms (SOA project templates, Custom activity templates, BPEL subprocesses and Service Bus pipeline Templates) as well as JDeveloper as the single and only IDE deliver a maximum good development experience.

Industrial SOA

Industrializing SOA is a main goal, when starting with a SOA initiative: Transparent monitoring and management and a robust, scalable and performant platform are key to successfully implementing SOA-based applications and architectures. These points are addressed by the new OFM 12c release through the following features:

  • Lazy Composite Loading – Composites will be loaded on demand and not at platform startup
  • Modular Profiles – Different profiles provided, which enables only the features currently needed (e.g. only BPEL)
  • Improved Error Hospital and Error Handling
  • Optimized Dehydration behaviour
  • Integrated Enterprise Scheduler (ESS)

Further main enhancements that where introduced regarding SOA and BPM Suite 12c were:

  • Oracle BPM Suite 12c: Definition of Business Architecture, including definition of Key Performance Indicators (KPI) and Key Risk Indicators (KRI) to provide an integral overview from a high-level perspective; ACM enhancements in the direction of predictive analytics
  • Oralce BAM 12c: Completly re-implemented in ADF, allows operational analytics based on the defined KPIs and KRIs
  • Oracle MFT: Managed File Transfer solution for transferring big files from a specified source to a defined target; integration with SOA/BPM Suite 12c can be done by new JCA-based MFT adapters

Looking back,  a great and very interesting week lays behind me, providing a bunch of new ideas and impressions on the new Fusion Middleware 12c release. I’m looking forward to use some of this great new stuff soon, in real world’s projects.

Special thanks to Jürgen Kress for the excellent organization of the event! I’m already looking forward for next SOA Community event…

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 27 Followern an