Alle Kurse auch online

Obtec reagiert auf die aktuelle Corona Situation

Erweiteres Kursangebot erst mal bis zum Sommer für Online/Remote Kurse.

Alle Kurse sofort als Remote Kurse buchbar

Um der aktuellen Situation mit Reisebeschränkungen gerecht zu werden, biete die Obtec Software GmbH ab sofort alle Kurse auch Remote an. Bleiben Sie in Ruhe zu Hause sitzen und holen Sie sich Kurs und Trainer übers Internet nach Hause. Durch die Nutzung der verschiedensten Medien ist eine effektive und verständliche Kursgestaltung auch über Internet möglich. Für den genauen Ablauf sprechen Sie uns an: Kontakt

Obtec ergänzt Kursportfolio um weitere IT Trainings

Neben den zusätzlichen IBM Kurs-Terminen bietet Obtec nun auch weitere IT-Trainings an. Warum nicht die Zeit nutzen und zuhause lernen?

Obtec kann flexibel auf die veränderten Situationen reagieren

Sollte sich die Situation entspannen, ist es auch möglich von den Remote bzw. Online Kursdurchführung in den Klassenraum auf ein Präzensveranstaltung in der Essener Innenstadt zu wechseln. Egal wie sich die Situation entwickelt, wir haben eine Lösung.

Jetzt Garantietermine auch Remote. Bleiben Sie zuhause und besuchen Sie trotzdem die Kurse!

Der aktuellen Situation mit dem Coronavirus geschuldet, hat die Firma Obtec ihr Kursangebot erweitert und umgestellt. Ab sofort sind alle Klassenraumkurse auch als ILO Kurse verfügbar.

Diese Instructor lead online Kurse sind inhaltlich identisch zu den Präsenzkursen. Damit haben Sie für die Monate bis zu den Sommerferien eine absolute Planungssicherheit, auch wenn sich die Reiseverbote und Kontaktverbot nicht ändern.

Buchen Sie einfach den Kurs und Sie können sicher auch übers Internet daran teilnehmen. Sollte es sich ergeben, dass das Reiseverbot wieder aufgehoben wird, können die Remote Kurse auch wieder im Schulungsraum in Essen durchführen. Dies bietet in die absolute Flexibilität, die Sie gerade in dieser Zeit brauchen.

Falls Sie Fragen zu der Durchführung übers Internet haben, können Sie sich gerne mit uns in Verbindung setzen. Wir erklären Ihnen dann detailliert, wie das Ganze abläuft.

Coronazeit – Ausbildungszeit

Warum ich die Zeit nutzen und einen Kurs besuchen? Die Firma Obtec hat ihr Kursprogramm dem entsprechend erweitert.

Sie können zum Beispiel im Bereich der Programmiersprachen ein Java Kurs besuchen und Java entspannt von Zuhause aus lernen. Oder, falls Sie Java schon können, einen Clean Code Kurs besuchen, der es Ihnen ermöglicht aus der Software Engineering Perspektive Ihren Code noch mal zu überarbeiten.

Oder sie wollen sich im Bereich des Software-Engineerings weiterbilden. Dann können Sie die UML  oder BPMN Kurse besuchen. Auch eine Unterstützung, wie sie in den Enterprise Architekt einsetzen, erhalten Sie über die neu angebotenen Kurse der Firma Obtec.

Alle Kurse finden Remote statt und sind selbstverständlich Garantie Termine, ab dem ersten Teilnehmer.

IBM ACE App Conncet Enterprise V12 Schulung

Schulung zum Thema IBM ACE App Conncet Enterprise V12

Die Firma Obtec Software freut sich in Ihnen mitteilen zu können, dass die neuen IBM Kurse WM686G, WM687G und WM688G zum Thema Entwicklung von Anwendungen für IBM App Connect Enterprise V12 kurz IBM ACE, in der alten Version IBM Integration Bus oder davor WebSphere Message Broker, genannt zur Verfügung stehen und ab 2. Quartal 2024 die ersten garantierten Schulungen zum Thema stattfinden werden.

Die Kurse WM 686G, WM687G und WM688G sind jeweils 2 Tage lang. Mit den Schulungen werden alle Konzepte und Möglichkeiten der Entwicklung mit der neuen Version V12 abdeckt.

Die einzelnen Themen lassen sich aus den Seminarbeschreibungen entnehmen.

Obtec Kursnummer: OB 2238 Termin:

https://obtec.net/trainings/ibm-app-connect-enterprise-ace-v11-application-development/

Auch für Adminstratoren

Obwohl der Kurs als Entwicklungskurs ausgeschrieben ist, können auch Administratoren diesen Kurs besuchen. Es werden keine speziellen Programmierkenntnisse verlangt und es kann durchaus auch sinnvoll sein, dass ein Administrator einen etwas tieferen Einblick in die Anwendungen bekommt, die er dann betreiben soll.

IBM WebSphere Application Server – Ein Überblick bzw. Einführung

Der folgende Beitrag soll einen kleinen Überblick über den WebSphere Application Server geben.

Was ist der IBM WebSphere Application Server (Full Profile)?

Als vor circa 20 Jahren die Anwendungen nach und nach Internet fähig gemacht werden mussten, entstand die Notwendigkeit neben statischen Seiten, die ist im World Wide Web sowieso schon gab, nun eine Möglichkeit zu bieten auch Anwendungen übers Internet auf einem Server auszuführen. Eine der Techniken zu der Zeit war CGI (Common Gateway Interface). CGI war eine Erweiterung der Web Server, um über das HTTP Protokoll Anwendungen, die auf dem Server lagen, aufzurufen. Die Java Gilde überlegte sich, dass es sinnvoll wäre auch ein Java Technik in diesem Bereich zur Verfügung zu stellen. Somit entstand die Idee einer serverseitigen Java Anwendung, die auch vom Client aus aufrufbar sein sollte. So entstand das Servlets. (Übrigens wäre der Name Applet der sinnvollere gewesen, da es sich um einen Applikation handelte. Dieser Name war aber schon belegt. Dann hätte das Applet besser Clientlet geheissen)

Dieses Servlet sollte also im Server laufen. Da Java nun mal eine JVM braucht, wurde auch hier das Konzept verwendet.

Die JVM, die auf der Serverseite eingebaut wurde, beinhaltete einen Teil, der spezieller war, als die Standard JVM. Das resultierte daher, das man erwartete, dass es ganz viele Instanzen eines Servlets auf dem Server geben würde. Somit erzeugt man einen eigenen, so genannten Container, der damals noch Servlet Engine hieß, in dem die Servlets in einem bestimmten Lebenszyklus existieren. Dies geschah vor allem Dingen aus Skalierbarkeit und Ressourcen Gründen.

Somit entstand ein so genannter Web Applikation Server, der sich vom Web Server dadurch unterschied, dass es eine JVM gab und so Servlets, die darin liefen. Das war die Idee und erste Umsetzung. Im weiteren wurde die erste Spezifikation stark erweitert. Hier spielte vor allen Dingen der Model View Controller eine Rolle, der eine Trennung der Präsentationslogik,  der Business Logik  und des Kontrollers forderte. Hieraus entstand ein Standard der sich heute Java Enterprise Edition (J EE) nennt, früher  Java 2 Enterprise Edition (J2EE).

Der WebSphere Application Server ist somit ein Web Application Server (auch schon Mal nur Application Server genannt), der nach dem Java EE Standard implementiert worden ist.

Wie ist der IBM WebSphere Application Server aufgebaut?

In seiner Grundstruktur ist der WebSphere Application Server ist ein Java EE compliant  Server, der alle notwendigen Spezifikationen erfüllt. Im Kern besteht der Server aus einem internen Web Server, der die HTTP Requests entgegen nimmt und intern an den Web Container weiterleitet. In dem Container Leben die Servlets und JSPs, die die Control Logik und die User Interface Logik beinhalten. Von der Kontrolllogik aus wir nach Standard normalerweise der EJB Container angesprochen, nn dem sich die Business Logik befindet. Von der Business Logik aus wird auf ein Backend zugegriffen. Diese Backends können verschiedener Natur sein. Eine Möglichkeit ist ein Zugriff über JDBC auf eine Standard relationale Datenbank. Eine andere Möglichkeit ist der Zugriff auf beliebig andere Systeme. Der Zugriff erfolgt wie im J2C bzw. JCA Standard beschrieben. Ein weiterer wichtiger  Aspekt sind die verschiedenen Möglichkeiten, die Server basierte Anwendung anzusprechen. Dies kann wie bereits erwähnt über das Web Interface geschehen aber auch Webservice Zugriffe sowie Zugriffe über ein Messaging System wie JMS ist möglich. Auch besteht die  Möglichkeit eine Java Anwendung direkt mit der Business Logik reden zulassen (Java Client). Soweit ist der Aufbau des Servers ein ganz normaler Aufbau, wie er auch im Standard beschrieben wird. Interessant ist, dass die IBM viele Erweiterung zum Standard Server hinzugefügt hat, die vor allen Dingen Skalierbarkeit, Sicherheit und Zuverlässigkeit beinhalten. Dies wird vor allen Dingen im nächsten Abschnitt „Welche Konfiguration gibt es“  erklärt.

Welche Konfigurationen gibt es?

Wie bereits erwähnt ist in seiner Grundstruktur der WebSphere Application Server ein ganz normaler Server, der nach dem J EE Standard implementiert worden ist. Diese Version lässt sich standardmäßig installieren und ist eine so genannte Single Server Version (bei IBM auch schon mal Base genannt). Der Single Server hat aber diverse Nachteile. Fällt dieser eine Server aus kann man auf die Anwendung nicht mehr zugreifen. Ferner hat ein Soingel Server begrenzte Kapazitäten, die durch Speicher und Prozessor der Maschine begrenzt sind. Für die Themen Skalierbarkeit, Ausfallsicherheit und Load Balancing hat die IBM eine weitere Installationsmöglichkeit geschaffen, die mit dem Produkt Version Network Deployment ein hergeht. Die Network Deployment Version bietet die Möglichkeit nicht nur einen Server aufzubauen, sondern ein komplettes Cluster von Servern, die horizontal oder vertikal angeordnet werden können, um somit Prozess fail over oder Machine fail over zu kompensieren. In dieser Konfiguration gibt es eine zentrale Administrationsmöglichkeit den  Network Deployment Manager.

Welche Plattformen werden unterstützt?

Unabhängig von den verschiedenen Konfigurationen ist beim Application Server maßgeblich die Java EE Version. D.h. immer dann, wenn der Standard erweitert beziehungsweise eine neue Version des Standards herauskommt, muss der WebSphere Application Server um ein Java EE Compliant Server zu bleiben, auch angepasst beziehungsweise weiter implementiert werden. Darüber hinaus kann man den Server auf fast allen gängigen Plattformen installieren. eine Unterscheidung ist hierbei allerdings, ob der Server mit einer eigenen von IBM implementierten JVM ausgeliefert wird oder ob man eine JVM von Oracle installieren muss. Der Server ist generell auf Z/OS genau so verfügbar, wie auf allen Linux, Unix und Windows Plattform. Interessant ist hier das war eine Clusterkonfiguration nicht Mal gleiche Betriebssysteme noch Version des Servers gefordert sind.

Was sind die Vorteile vom WebSphere Application Server?

Von außen betrachtet und wenn man die reine Funktionalität sieht, hat der WebSphere Application Server in der Base Version keine Vorteile gegenüber den anderen angebotenen J EE complaint Servern.

  1. Support von IBM: Jeder Kommerzielle Server Anbieter unterstützt seine Kunden mit umfangreichem Support. Bei IBM gibt es alklerdings noch diverses mehr. Angefangen von den Redbooks über Developerworks bis hin zu diversen Spezialisten und 20 Jahren Erfahrung, vor allen Dingen auch mit großen Installationen, ist da alles dabei.

Nimmt man die Network Deployment Version mit hinzu, ergeben sich weitere Vorteile:

  1. Einfache Administration: Der WebSphere Application Server kann, egal in welchem Umfang über eine zentrale Administrationskonsole bedient beziehungsweise konfiguriert werden. Dies hat den entscheidenden Vorteil, dass auch bei komplexen Installationen, keine Notwendigkeit besteht einzelne Server zu administrieren. Ferner bietet die Zentrale Konsole diverse Konfigurationsmöglichkeiten, die von einem dynamischen Cluster angefangen bis hin zum Health Management konfigurierbar sind. Damit lassen sich einfacher aber auch sehr komplexe Installation einfach handhaben. Sollte das Konzept der Zelle (Cell) nicht ausreichen, gibt es darüber hinaus noch eine weitere Möglichkeit verschiedene Zellen auch zentral zu managen. Dies geschieht über den so genannten Job Manager, der einzeln installiert werden kann, oder Bestandteil des Deployment Managers ist. Sollte Administration über die Konsole zu aufwändig werden, bietet der WebSphere Application Server die Möglichkeit der Kommandozeilen Administration über wasadmin. Mit diesem Scriptinmg Client hat man die gleichen Möglichkeiten, wie in der Administrationskonsole, allerdings lassen sich nun diverse Aufgaben automatisieren und sogar zeitlich steuern.
  2. Zuverlässigkeit: Nimmt man den Server für sich, kann man natürlich auch von einer gewissen Zuverlässigkeit reden. Spannend wenn es allerdings erst, wenn man das Konstrukt der Cluster mit einbezieht. Durch ein Cluster, dass auch verschiedene Maschinen verteilt ist, kann man erreichen, dass immer ein Server zur Verfügung steht.
  3. Skalierbarkeit: Es besteht die Möglichkeit auf einer physikalischen Maschine oder logische Partition mehrere WebSphere Application Server zu installieren. Jeder dieser Server hat seinen eigenen Prozess und JVM. Dadurch lassen sich die Ressourcen der Maschine deutlich besser nutzen. Ferner bietet diese Installation schon einen ersten Fail Over Support, da bei Prozessfehler (Server Fehler) die anderen Server Prozesse weiterlaufen. Ferner besteht die Möglichkeit weitere Server auf anderen physikalisch getrennten Maschinen zu installieren. Dies hat den Vorteil, dass man beliebig viele Maschinen zu einem so genannten Cluster zusammensetzen kann. Dies ergibt die Möglichkeit eine Anwendung auf dem Cluster zu installieren und egal, ob 10 oder 100.000 Nutzer gleichzeitig auf den Server zugreifen wollen, hat man immer genügend Kapazität.
  4. Hoch Verfügbarkeit: Durch die Installation der Anwendung auf einem Cluster, welches aus verschiedenen Servern besteht, erhält man die Möglichkeit über einen vorgeschalteten Load Balancer (das kann das Plugin des WebServers und/oder ein externer Load Balancer) die verschiedenen Server zu nutzen. Die Anwendung ist bei sauberer Konfiguration nicht an einen Server gebunden (Session affinity), sondern kann auch verschiedenen Servern betrieben werden. Der Nutzer merkt den Unterschied nicht. Alle Daten (Session) bleiben erhalten.

Abgrenzung zu IBM WebSphere Application Server Liberty Profile

Der WebSphere Application Server Liberty Profile ist eine Server Version, die vor allen Dingen für einfache Anwendungen im kleineren Umfeld Verwendung finden sollte. Durch OSGI und die Möglichkeit nur Features einzubinden, die tatsächlich benötigt werden, entsteht eine Server-Struktur, deren Konfiguration des früheren JBoss sehr ähnelt.

Bei einfachen Installationen oder bei einfachen Anwendungen, die kein großes Cluster und keine große flexible Konfiguration brauchen, ist der Liberty Profile Server sicherlich die erste Wahl. Generell sind das allerdings zwei Unterschiedliche Produkte, die auch unterschiedliche Ziele und Aufgaben haben.

Eine genaue Gegenüberstellung kann man hier bei der IBM einsehen:

http://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/documentation/ChoosingTraditionalWASorLiberty-16.0.0.4.pdf

Hieraus ergibt sich auch folgende Zusammenfassung:

„As stated in the introduction, if you are using traditional WAS and it does what you need, you should not feel compelled to move to Liberty. Many companies have large investments in traditional WAS infrastructure and automation, and IBM will continue to serve and support those customers. It is expected that there will be some applications that remain on WAS indefinitely, because it is impractical or cost-prohibitive to adapt them to run on Liberty.“

Dies bedeutet, dass man je nach Einsatzbereich den richtigen Server auswählen sollte.

Schulungen zum Thema WebSphere Application Server

Das IBM Schulungsportfolio bietet unterschiedliche Kurse zu den jeweiligen Themen an. Die erste Unterscheidung muss man treffen, ob man etwas über den WebSphere Application Server Full Profile oder Liberty Profile lernen möchte. Will man Liberty Profile, kann man den Kurs WA190 – Administering WebSphere Application Server Liberty Profile V9 besuchen. Die Firma Obtec bietet diesen Kurs unter der Kursnummer OB2202 an:

https://obtec.net/trainings/ibm-wa190g-administering-websphere-application-server-liberty-profile-v9/

Dieser Kurs ist zwei Tage lang. Allerdings sollte man hier Kenntnisse des WebSphere Application Server Traditional mitbringen, sonst ist die Zeit sehr knapp.

Für den „Standard“ WebSphere Application Server bietet die IBM verschiedene Kurse an. Will man die Administration der Version 8.5.5 lernen, so kann man den Kurs WA855 – WebSphere Application Server V8.5.5 Administration besuchen. Obtec bietet den Kurs unter OB2203 an. Der nächste Termin ist:

21.06.-25.06.2021 | WA855G – WebSphere Application Server V8.5.5 Administration

 

Dieser 5 tägige Kurs deckt alle relevanten und wichtigen Themen der Administration ab.

Für die Version 9 des Servers hat die IBM 2 Kurse im Angebot. Der WA590 ist der erste Teil. Hier werden alle Funktionalitäten des „Base“ Servers abgedeckt. Im zweiten Kurs WA599 werden die Network Deployment Konfigurationen erklärt. Die Firma Obtec Sofware bietet das Ganze in Kombination in 5 Tagen an:

OB 2201 – WebSphere Application Server V9 Administration

Der nächste Termin ist:

21.06.-25.06.2021 | WA590G / WA599G – WebSphere Application Server V9 Administration

Beide Kurse werden sowohl Remote (ILO) und als Klassenraumkurse angeboten. Der V9 Admin Kurs wurde um einen Tag gegebenüber den IBM Vorgaben verlängert. Die Erfahrung hat gezeigt, dass man den Kurs in 5 Tagen besser halten kann. Dies hat zwei Gründe. Zum einen waren die 4 Tage sowieso etwas knapp bemessen, zum Anderen kann man so ein paar Themen ergänzen, die leider im Standard Kurs nicht mehr enthalten sind.

 

IBM erweitert das Schulungsprogramm zum WebSphere Application Server Full profile

IBM hat drei erfolgreiche Kurse zurück ins Portfolio gebracht. Diese Kurse sind ab sofort bei IBM re-retired. Sie werden auf dem Stand des WAS 8.5.5 angeboten, passen aber auch für die Nutzer/Administratoren der Version 9. Auf die geringen Unterschiede zwischen den Versionen 8.5.5 und 9 wird eingegangen.

 

WA680 – WebSphere Application Server V8.5 Scripting and Automation

06.09.-10.09.2021 | WA680G – WebSphere Application Server V8.5 Scripting and Automation

In diesem Kurs wird vermittelt, wie der WAS ohne die ICS Console administiert werden kann.

 

WA815 – WebSphere Application Server V8.5.5 Performance Tuning

12.07.-15.07.2021 | WA815G – WebSphere Application Server V8.5.5 Performance Tuning

Lernen Sie kennen, wie man den WAS unter Last testet und optimiert.

Beide Kurse werden sowohl online als auch Präsenzkurs angeboten.

Generell sind alle Kurse auch gerne als Inhouse bei Ihnen vor Ort möglich. Equipment kann dafür gestellt werden. Eigene Lizenzen des Produkts sind nicht erforderlich, sondern werden mit den Labs bei IBM eingekauft.

IBM MQ – Ein Überblick bzw. Einführung

Was ist IBM MQ?

 

Wenn man IBM MQ kennen lernen bzw. verstehen will, muss man sich erst mit den Kommunikationsmechanismen in der IT auseinandersetzen. Während im B2C Bereich die Kommunikation in der Regel synchron erfolgt, verwendet man im B2B Bereich lieber eine asynchrone Kommunikation.

Die asynchrone Kommunikation hat den Vorteil, dass der Absender nicht auf eine Antwort des Empfängers einer, so genannten, Nachricht warten muss. Man entkoppelt somit die beiden Systeme, die deswegen unabhängig voneinander weiter arbeiten können. Dies setzt allerdings voraus, dass die verwendeten Programme dies unterstützen. Im B2B ist dies möglich, während im B2C, dort sitzt ja immer ein Benutzer vor einen Browser oder System, auf ein Ergebnis wartet und damit die Kommunikation meist synchron sein muss. Bei der asynchronen Kommunikation, die in der Regel die Kommunikation zwischen zwei Computerprogrammen unterstützen, ist eine synchrone Kommunikation nicht unbedingt erforderlich. Das Ganze ist eigentlich wie ein Postablagekörbchen nur besser und elektronisch.

Beispiel: Eine Anwendung im Check in Bereich des Flughafens sammelt die Passagierdaten für den jeweiligen Flug. Nach Schließen des Fluges müssen die Daten an den Zielflughafen, beispielsweise in New York, geschickt werden. Ob diese Daten in der gleichen Sekunde, in der sie aufgenommen worden sind, oder 2 Stunden später, in New York ankommen, beziehungsweise entgegengenommen werden, ist für die Anwendung unerheblich, da der Flug ja mindestens 6 Stunden dauert und erst dann die Daten am Zielort vorliegen müssen.

IBM MQ ist ein so genanntes Message oriented middleware (MOM) System, welchen genau diese asynchrone Kommunikation unterstützt.

Deswegen gilt: Every DAD needs a MOM. Every Distributed Appliction Development needs a Message Oriented Middleware (alter IBM Merksatz – nicht ganz ernst)

Wie ist IBM MQ aufgebaut?

Die Initiale Idee von IBM MQ ist eigentlich aus der Realität abgeschaut. Man verwendet bei IBM MQ so genannte Messages oder deutsch Nachrichten, um die Daten zu übermitteln. Diese Nachrichten haben einen Header in dem u.a. die Empfängerinformationen stehen und einen Message Body oder auch Payload genannt, in dem die zu übermittelnden Daten stehen. Diese Messages werden in Message Queues abgelegt. Der Sinn dahinter ist, dass der Sender die Message in einer Queue ablegt. Damit ist sein Teil erledigt. Der Empfänger holt bei Bedarf oder zu gegebener Zeit die Message aus der Queue und verarbeitet sie weiter. Der Vorteil ist, wie weiter oben schon beschrieben, die asynchrone Nutzung. Der Sender steckt die Message in die Queue und damit ist die Arbeit für ihn erledigt. Der Empfänger kannst zu gegebener Zeit oder wenn es ihm passt die Message aus der Queue holen und verarbeiten.

Welche Konfigurationen gibt es?

IBM MQ kann auf verschiedene Art und Weisen konfiguriert werden. Zuerst einmal gibt es einen Queue Manager, auf dem die Queues eingerichtet werden. Die einfachste Konfiguration ist dann, dass der Absender in eine Queue, die auf dem IBM Queue Manager angelegt worden ist, die Message ablegt und der Empfänger die Message aus der gleichen Queue ausliest.

Auch kann man ein, so genanntes Remote oder Distributed Queuing konfigurieren. Hierbei werden zwei Queue Manager miteinander über einen Channel verbunden. Wenn die Verbindung einmal steht, kann der Absender auf seiner Seite in eine sogenannte Remote Queue auf seinem lokalen Queue Manager die Message ablegen. Diese wird dann über das Netzwerk zu dem Remote Queue Manager und der jeweiligen Queue übertragen. Dieses Remote Queuing bietet den Vorteil, dass Sender und Empfänger an ganz unterschiedlichen Stellen sitzen können und jeweils ihre eigene Queue Manager betreiben. Das Ganze unterstützt dann das sogenannte „exactly and asured once delivery“. Weiterhin kann man hier diverse Sicherheitskonzepte, wie eine gesicherte TLS Verbindung realisieren.

Eine weitere Konfiguration ist das so genannte Publish and sucribe. Diese Konfiguration unterstützt den so Absender, der eine Message zu einem bestimmten Topic (Thema) bereitstellt und diese automatisch vom MQ System zu den jeweiligen Queues für die jeweiligen Subscriber (wollen zu dem Topic die Infos haben) verteilt wird. Diese Art von Konfirmation ist ein so genanntes Point to Point bzw. 1-1 Messaging mehr, sondern mehr eine 1-m (many) Konfiguration.

Ferner besteht eine weitere Möglichkeit der Konfiguration: Das Erstellen von so genannten Clustern. Ein Cluster besteht aus verschiedenen Queue Managern, auf denen die Queues so konfiguriert werden, dass ein Load balancing stattfinden kann.

Welche Plattformen werden unterstützt?

IBM MQ „links nearly everything to everything”. D.h. IBM unterstützt mit ihrem System fast alle gängigen Plattformen. Zu unterscheiden sind allerdings Client und Server Konfigurationen. Die Client Konfiguration können normalerweise auf beliebigen Maschinen aufgebaut werden und werden dann mit dem Server verbunden. Auf den Clients lassen sich keine Queues anlegen. Sie dienen lediglich dazu, um über das MQI (MQ Application Programming Interface),  welches das Programmierinterface für die Client Anwendung ist, Programme aufrufen zu können, sprich Queues ansprechen zu können (MQPUT, MQGET etc.). Die Server Konfiguration steht auf allen gängigen Betriebssystemen zur Verfügung und überall gleich konfiguriert. Einzige Ausnahme hierbei ist das Z/OS. Beim Z/OS ist die Installation unterschiedlich. Bei Allen anderen Plattform ist die Konfiguration gleich. Es spielt also keine Rolle, ob sie einen Queue Manager auf einem Windows System oder einem AIX System installieren. Nur auf den MQ Servern lassen sich Queue Manager installieren. Sie dienen dann als Basis, um die jeweiligen Queues anlegen zu können, wobei hier unterschiedliche Konfigurationen -siehe oben- aufgebaut werden können.

Was sind die Vorteile von IBM MQ?

Wenn man sehr ins Detail geht, kommt man auf sehr viele Vorteile. Ohne zu sehr in Details zu gehen, kann man ein paar Vorteile nennen:

  1. Konnektivität. Wie bereits angesprochen kann mit IBM MQ mehr oder minder alles mit allen miteinander verbunden werden. Die Client Plattform, als auch die Server Plattform, bietet da sehr unterschiedliche Konfigurationsmöglichkeiten. Hierzu zählt auch das über die Message Queues beliebige Daten übertragen werden können. D.h. das System selbst ist, was die Daten anbelangt, neutral. Ob ich Datenbank Information oder Binärdaten übertrage, ist dem IBM MQ egal.
  2. Zuverlässigkeit. Das System ist so ausgelegt, dass es jede Art von Server Crash oder ähnlichem wie Verbindungsverlust kompensiert, beziehungsweise das System so wieder aufsetzt wird, als wäre nichts passiert. Es gehen keine Messages (wenn sie persistent sind) verloren und sie werden auch nur exakt einmal ausgeliefert. Zum Thema Zuverlässigkeit zählt auch, dass das  IBM MQ ein transaktionelles System ist. Dies bildet die Basis für die Zuverlässigkeit und sorgt so dafür, dass keine Messages verloren gehen. Es kann im Rahmen eines Two Phase Commit als Transaktionsmanager oder als Resourcen Manager konfiguriert werden.
  3. Sicherheit. Seit Version 6 sind die Security Konzepte nach und nach immer weiter überarbeitet worden, so dass heute jede Art der Security Konfiguration möglich ist. Das beginnt mit dem Object Authority Manager, der dafür sorgt, dass nur die jeweiligen Gruppen und Benutzer auf den Queues berechtigt sind, und geht bis hin zur Unterstützung von TLS auf der Transportebene. Es gibt heute keine Lücken mehr. Damit kann man eine sichere MQ Umgebung mit Bordmitteln realisieren. Security Exits sind kaum noch nötig.
  4. Skalierbarkeit. Es besteht die Möglichkeit von einfachen Konfigurationen schrittweise zu hoch komplexen das System zu erweitern. Hierfür können verschiedene Konfigurationen je nach Bedarf ergänzt beziehungsweise umgebaut werden. So kann von einem einfachen Queuing zu einem Remote Queuing oder auch Distribution Queuing umgebaut werden,  oder durch Publish and Subscribe ergänzt werden. Eine weitere Möglichkeit bietet der Aufbau eines Clusters, das die Skalierbarkeit weiter fördert.

Abgrenzung zu IBM Integration Bus (IIB), jetzt IBM ACE (App Connect Enterprise)

Während das IBM MQ rein zum Transport von beliebigen Daten dient, ist der IIB dazu da, um Nachrichten zu formatieren, sprich von einem Format in ein anderes zu überführen oder intelligent weiterzuleiten (Routing). Hier ist es wichtig diese beiden unterschiedlichen Systeme zu verstehen beziehungsweise voneinander zu trennen. IBM MQ  für den Transport. Der IIB ist für die Konfiguration bzw. zum Formatieren und für ein intelligentes (content based routing) Weiterleiten verantwortlich. Darüber würde in einer vollständigen Konfiguration noch ein Prozess Manager sitzen. (Siehe auch IBM Integration Bus (IBM ACE) und IBM Business Process Manager)

Schulungen zum Thema MQ

Das IBM Schulungsportfolio bietet unterschiedliche Kurse zu den jeweiligen Themen an. Wenn man sich erst einen Überblick verschaffen möchte, so kann man sich in einem 1-Tagesseminar genau diesen Überblick über Konzepte und Möglichkeiten des Systems holen.

Der IBM Kurscode ist WM103 – Technical Introduction to IBM MQ. Die Firma Obtec bietet diesen Kurs unter der Kursnummer OB2227 an.

Für die Konfiguration des Systems bietet die IBM generell zwei Kurse an. Der eine ist für die Konfiguration auf Z/OS Ebene.

Der andere ist für die Konfiguration auf den anderen Systemen. Der Kunde kann bei den Übungen zwischen Windows und Linux Plattform wählen. Nächster Termin:

IBM WM153 – IBM MQ V9 System Administration (using Windows for labs) Obtec OB2225:

15.02.-18.02.2021 | WM153G – IBM MQ V9 System Administration (using Windows for labs)

IBM WM154 – IBM MQ V9 System Administration (using Linux for labs) Obtec OB2226:

15.02.-18.02.2021 | WM154G – IBM MQ V9 System Administration (using Linux for labs)

Wobei man sagen muss, dass sich diese Kurse inhaltlich nicht unterscheiden, da auch das IBM MQ auf beiden bzw. auf allen Plattformen das gleiche ist. Selbst wenn man im Kurs auf Windows die Übung durchführen würde, könnte man das gelernte Wissen bis hoch zur AIX Plattform anwenden.

In dem ersten grundlegenden Administrationskursen werden Konzepte wie Point to Point Messaging und Remote Messaging, sowie die Grundlagen eines Clusteraufbaus erklärt. Neben dem Einstieg in Security runden Konzepte und Übungen zur Sicherung des Systems, sowie die Nutzung und Konfiguration von Clients den ersten Kurs ab.

Wer das Thema Clustering vertiefen und das Thema Publish and Subscribe kennen lernen möchten, sowie vertiefte Kenntnisse zum Thema Security haben möchte, der kann den zweiten Teil des Kurses besuchen.

IBM WM213 – IBM MQ V9 Advanced System Administration (Distributed) OB2231. Der nächste Termin ist:

01.03.-04.03.2021 | WM213G – IBM MQ V9 Advanced System Administration (Distributed)

Bei weiteren Fragen können Sie sich gerne über die Kontaktseite melden.

Inhouse Trainings

Neue Webseite