Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an

Transkript

1 Middleware Versuch einer Einleitung Host dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Mainframe enthält vollständige Anwendung Typ. COBOL, C

2 Mainframe contd.! Nachteile! Mainframe ist teuer (Millionen!)! (damals) keine grafische Oberfläche! Kaum Integrationsmöglichkeiten (anderer Systeme)! Proprietäre Systeme (OS, DB, Anwendung,...)! Vorteile! Nur ein System (das ausfallen kann, gewartet werden muss,...)! Clients (Terminals) benötigen keine Konfiguration, Installation,...! Entwicklung! PCs sind billig und leistungsfähig! Zentral nur noch Datenbank, der Rest (Anwendung,...) läuft auf Client --> Mainframe wird entlastet (überflüssig?) Client Server Server Anwendung läuft auf Clients (PC) Typ. C++ Programm (Visual Studio) Beispiel: SAP R3, WWW?

3 Client Server contd.! Vorteile! HW (auf Clients) wird optimal ausgenutzt! Grafische Oberfläche! Client kann auf mehrere Server zugreifen! Kleiner Server --> billig, flexibel (verschiedene Hersteller, Unix- Plattform)! Nachteile! Client erfordert Konfiguration/Installation --> hoher Installations-/ Support-Aufwand! Unter Umständen hohe Anforderungen an Client-HW, Netzwerk! Entwicklung! Thin Clients: Client ist nur für Ausgabe/Eingabe zuständig! Aber wie?! Browser! (und ggf. Applet,...) Thin Client, 3 tier Typ. ASP, JSP, Servlet, PHP usw. Anwendung läuft im Webserver und greift auf Datenbank zu

4 Thin Client contd.! Vorteile! Wie bei Mainframe + modern! Nachteile! Bei hohem Interaktionsgrad Anwendungsentwicklung komplex und aufwendig! Probleme! Enge Kopplung zwischen Webserver und Datenbank! Skalierung, Flexibilität!! Anwendungsprogramm enthält Geschäftslogik! Lösung! Trennung durch Applikationsserver, Middleware Architekturen! Von Client/Server zu EAI! Überblick, technische Details komplex (später)! Szenario:! Unternehmen verwendet SAP als ERP-System! wickelt Versand über Dienstleister, hier UPS ab! UPS bietet Verfolgung der Lieferung über Web-Schnittstelle! Daten im ERP (z.b. Auftrag) und beim Dienstleister müssen abgeglichen werden! Verschiedene Lösungswege

5 Separate Clients SAP GUI SAP Browser Spezieller Client für jede Anwendung Abgleich erfolgt manuell (copy-paste,...) Probleme: Effizienz, Konsistenz usw. UPS Spezieller Client Client SAP Client Client Client Spezieller Client für diese Anwendung integriert die Daten Probleme: Aufwand! Für jede mögliche Anwendung muss neuer Client entwickelt werden (und installiert, Gewartet,...) UPS

6 Integration SAP-GUI SAP Kopplung zwischen den (Server-) Systemen SAP greift auf Daten aus Fremdsystem zu Problem: Programmierung (auf Server) nötig Wie kommunizieren die verschiedenen Systeme? UPS Middleware! Techniken zur Kopplung von Systemen! Selbst gebastelt (Text, TCP/IP sockets, FTP,...)! RPC (Remote Procedure Call)! CORBA (Common Object Request Broker Architecture)! COM+ (Common Object Model,.NET)! RMI (Remote Method Invocation)! XML-RPC! SOAP (Simple Object Access Protocol)! Web Services! usw.

7 Schnittstellen SAP UPS System 2 System 1 System 3 Bei N Systemen N*(N-1)/2 Schnittstellen! EAI Keine Punkt zu Punkt Schnittstellen sondern gemeinsame Architektur mit (mehr oder weniger) zentraler Vermittlung Bus Hub Sieht einfach aus, ist es aber nicht

8 Portal Client Browser Webserver Portal SAP Verlagerung der Komplexität an eine Stelle (Portal) Konsequenz für Informationsanbieter? Wie kommt das Portal an die Daten? z.b. Web Services UPS klassisch Anbieterseite Browser Webserver z.b. PHP z.b. DB jetzt Browser Webserver z.b. PHP z.b. DB Webservice Applikation muss mehrfach entwickelt werden!! deshalb Browser Webserver Webservice Applikationsserver DB

9 4 tier Architektur Darstellung Logik Daten Verschiedene Middleware Technologien, etwa CORBA,.NET, J2EE, Webservices usw. zur Kommunikation (insb.) zwischen Webserver und Applikationsserver Midleware! Vorteile! modern, flexibel,...! SW-technisch optimal: Trennung in einzelne Funktionalitäten: Präsentation, Anwendung, Geschäftslogik, Datenhaltung! Stand der Technik! Probleme! Komplexität, Administration,...! Unübersichtliche Technologie-Vielfalt: Ebene 1 und 4 meist klar, aber 2 und 3 bieten Vielzahl an Technologien! Entwurf der Middleware-Schnittstelle nicht einfach: Auf welcher Ebene soll hier abstrahiert werden (Daten, Funktionen, Prozesse,...)! Performance teilweise schlecht

10 Java Server Pages! Warum?! Servlets sind Programme! Werden von Programmierern erstellt! Wer schreibt HTML?! unterschiedliche Kenntnisse/Personen!! Viel Logik/viel Design! Wie?! Java Code wird in HTML-Seiten eingebettet! Oder besser: ausgelagert (Beans,...)! Trennung zwischen Layout und Funktionalität Hello.jsp <HTML> <HEAD><TITLE>Hallo</TITLE></HEAD> <BODY> Hallo </BODY> </HTML> Jede (gültige) HTML-Seite ist eine JSP! Engine erzeugt ein servlet (pagecompile) public class Hello_jsp extends HttpJspBase {... public void _jspservice(httpservletrequest request,... {... out = pagecontext.getout();... out.write("<html>\n"); out.write("<head>"); out.write("<title>viel Hallo"); out.write("</title>");

11 MuchHello.jsp <HTML> <HEAD><TITLE>Viel Hallo</TITLE></HEAD> <BODY> <% for (int i=0;i<10;i++) out.print( Hallo ); %> </BODY> </HTML> Eher Programm, besser Trennung: <% for (int i=0;i<10;i++) { %> <TABLE>... <%=i%> Hallo </TABLE>... <% } %> Beans <html> <%@ page session="false"%> <body bgcolor="white"> <jsp:usebean id='clock' scope='page' class='dates.jspcalendar' type="dates.jspcalendar" /> <font size=4> <ul> <li> Year: is <jsp:getproperty name="clock" property="year"/> <li> Month: is <jsp:getproperty name="clock" property="month"/> <li> Time: is <jsp:getproperty name="clock" property="time"/> <li> Date: is <jsp:getproperty name="clock" property="date"/> </ul>... Oder <till:date format= dd:mm:yyyy > (custom tags) Logik/Code steckt in Bean, in JSP nur Darstellung --> JSP für Ebene 2, Bean in Ebene 3

12 Dates/JspCalendar.java package dates;... public class JspCalendar { Calendar calendar = null; public JspCalendar() { calendar = Calendar.getInstance(); public int getyear() { return calendar.get(calendar.year); } public String getmonth() { int m = getmonthint(); String[] months = new String [] { "January", "February", "March","April", "May", "June", "July", "August", "September", "October", "November", "December" }; if (m > 12) return "Unknown to Man"; return months[m - 1]; Schicht 3! Hier noch unübersichtlicher, wichtigste Techniken:! J2EE!.NET! CORBA! Kommunikation zwischen Schicht 2 und 3 je nach verwendeter Technologie, Ausnahme: Web-Services J2EE.NET CORBA Webservice Sprachen Java C#, C++, VB,.. Fast alle alle Plattform alle MS Fast alle alle Performance gut Sehr gut mittel schlecht Verbreitung mittel hoch mittel niedrig