2. Agenda
ubigrate – Business ActivityMonitoring
Von der Plattform zur Architektur
Entwicklungsaspekte: Objektmodell, Fehlercodes
Laufzeitaspekte: Kommunikation, Datenbankzugriff
Organisatorisches
Fazit
3. Agenda
ubigrate – Business ActivityMonitoring
Von der Plattform zur Architektur
Entwicklungsaspekte: Objektmodell, Fehlercodes
Laufzeitaspekte: Kommunikation, Datenbankzugriff
Organisatorisches
Fazit
4. U NTERNEHMENSPROFIL UBIGRATE G MB H
• Spin-Off von SAP Research
• gegründet 2008
• 15 Mitarbeiter
• Hauptsitz Dresden
• Vertriebsbüros in Dortmund und
Karlsruhe
• ubigrate = ubiquitousintegration
4
5. D AS G RUNDPROBLEM
Geschäftsprozesse (Planung und Überwachung)
Software on Business Level (ERP, MES, WMS, etc.)
Informationen über
die phyischen
verspätet, fehlerhaft,
? unvollständig, nicht vorhanden.
Prozesse sind oft...
?
Physische Prozesse (Ausführung)
Probleme: Langsame Reaktion, manueller Aufwand, suboptimale Entscheidungen!
5
6. D ER L ÖSUNGSANSATZ
Software auf der Geschäftsebene (ERP, MES, WMS, etc.)
Business Activity Monitoring in Produktion und Logistik
Effiziente Erfassung und Analyse aktueller, vollständiger, fehlerfreier und exakter
Daten über die physischen Prozesse.
IT und intelligente Geräte (RFID, Sensors, Controls, …) auf Prozessebene
Vorteile: Schnellere Reaktion, automatische Erfassung, bessere Entscheidungen
6
7. G EQOO B OXES : B EHÄLTERMANAGEMENT
Reinigung/Reparatur Produktion Versand
Erfassung der
Nutzung in der
Produktion
Erfassung des Eingangs in Erfassung des Versandes
die Reinigung/Reparatur an Kunden
Kundenvorteile
Schwund verringern
Produktionsausfälle vermeiden
Unnötige Reinigung/Reparatur
verhindern
Behälterüber/-unterbestand
vermeiden
Automatisierte Abrechnung
7
8. G EQOO C OOL C HAIN : K ÜHLKETTENÜBERWACHUNG
+
!
Erfassung von
Übergaben zwischen
Transporteuren
Erfassung des Erfassung des
Transportbeginns Wareneingangs
Kundenvorteile
Lückenlose Erfassung der
Transport- bzw.
Lagerbedingungen
Vereinfachte Dokumentation
Erkennung von Problemstellen
während Transport/Lagerung
Verbesserung der
Abrechenbarkeit
88
9. A DS T EC
Industrietaugliches Terminal
Touchscreen 8“...15“
CPU: Intel Atom
RAM: bis zu 2GB
HD oder SSD möglich
OS: Windows XP, 7 oder Embedded
9
10. N ORDIC ID M ERLIN
Mobiles Terminal
RFID (UHF/HF) möglich
Barcodescanner
CPU: ARM, 532 MHz
RAM: 256 MB
Flash: 288 MB
OS: Windows CE 6.0
10
11. M ITSUBISHI C C ONTROLLER
Automatisierungshardware
(immer in Kombination mit SPS)
CPU: Renesas SH4, 400 MHz
RAM: 256 MB
Flash: ≤ 4 GB CF
OS: VxWorks 6.x
11
12. C LOUD S ERVER
Standard-HW bei Cloud-Anbieter
CPU: AMD OpteronQuadcore, 1.7 GHz
RAM: 4 GB
HDD: 2x250GB
OS: Ubuntu 8.4 LTS
12
13. C LIENT PC S
“Büro-PCs”
JederTyp von PCs, der in den letzten 10 Jahrenproduziertwurde
CPU: x86 (Intel, AMD, …)
RAM: 512 MB…4 GB
HDD: > 25GB
OS: Windows (in allenVersionen)
13
14. A NFORDERUNGEN AN DIE A RCHITEKTUR
Nr. Anforderung
A1 EinfacheBedienung, insbesondereUnterstützungfürTouchscreens
A2 Unabhängigkeitvominstallierten Browser auf Büro-PCs (IE 6…IE 9, Firefox,
Chrome, Opera)
A3 RobustheitauchbeiintermittierendenVerbindungenzwischen Terminals
und Cloud Server
A4 Persistenz in verschiedenenrelationalenDatenbanken
A5 Import und Export von Stamm- und Bewegungsdaten per HTTP/XML
14
15. Agenda
ubigrate – Business ActivityMonitoring
Von der Plattform zur Architektur
Entwicklungsaspekte: Objektmodell, Fehlercodes
Laufzeitaspekte: Kommunikation, Datenbankzugriff
Organisatorisches
Fazit
16. PL ATTFORM
Definition nach dem Linux Information Project [The Linux Information Project, 2011]
The term platform as used in a computer context can refer to (1) the type of processor and/or
other hardware on which a given operating system or application program runs, (2) the
type of operating system on a computer or (3) the combination of the type of hardware and
the type of operating system running on it.
Teilweise auch Einbeziehung eines Applikations-Frameworks
Hier: Kombination von Hardware und Betriebssystem
Begriff auch in anderen Industrien üblich, z.B. Automobilbau, Pharmaindustrie
Beispiele
Windows auf x86
Windows CE auf ARM
Android auf SnapDragon
VxWorks auf RenesasSHx
16
18. T ECHNOLOGIERAUM
Definition nach Ivan Kurtev[Kurtev et al., 2002]
A technological space is a working context with a set of associated concepts, body of
knowledge, tools, required skills, and possibilities. It is often associated to a given user
community with shared know-how, educational support, common literature and even
conference meetings.
Ergänzung des Plattform-Begriffs
Fokus stark auf BeziehungzwischenModell und Metamodell
KaumBetrachtungderWerkzeuge
Verwendung des BegriffsimFolgenden
Definition istsinnvoll
andererFokus: wegvomMetamodell/Modell-Beziehung, hinzuProgrammiersprache,
Applikationsframework, Werkzeuge
18
23. T ECHNOLOGIERAUM - ÜBERGREIFENDE
P ROGRAMMIERUNG
Fazit
Keiner der vorgestellten Technologieräume erstreckt sich über alle gewünschten
Plattformen
Wahl mehrerer Technologieräume → „Technologieraum-übergreifende Programmierung“
Probleme
Wiederverwendung von Code
Objektmodell
Reimplementierung von Features in mehreren Technologieräumen
Überbrückung Technologieraumgrenzen
Spezialisierung der Teammitglieder auf einen/mehrere Technologieräume
23
24. Agenda
ubigrate – Business ActivityMonitoring
Von der Plattform zur Architektur
Entwicklungsaspekte: Objektmodell, Fehlercodes
Laufzeitaspekte: Kommunikation, Datenbankzugriff
Organisatorisches
Fazit
26. O BJEKTMODELL
Objektmodell
Eigentliches Modell der Domäne (hier: Behälterverwaltung)
Objektmodell sehr agil, Änderungen in jeder Iteration
Beispiel: ContainerDescription – Beschreibung eines Behältertypens
Name, Beschreibung
Identifizierbarkeit einzelner Instanzen
Zustandsmodelle
26
27. I NSTANZEN IN DEN T ECHNOLOGIERÄUMEN
5a. 4.
2. 1.
5b.
3.
ContainerDescription-Instanzen existieren in allen Technologieräumen
Änderung des Objektmodells muss in allen Technologieräumen nachvollzogen werden
27
28. Z ENTRALES M ODELL : XML S CHEMATA
Zentrales Modell zur Generierung des Objektmodells
Mögliche Modellierungstechniken: UML, textuell, XML Schema
ubigratebenutzt XML Schemata zurBeschreibung des Objektmodells
Ableitung von Artefakten in Java, C#, ActionScript, MXML, OR-Mapping, Ruby
28
29. XML S CHEMA C ONTAINER D ESCRIPTION . XSD
Verhältniszwischen XML Schema und UML siehe [Carlson, 2001]
29
33. XMLS CHEMA → C# (1)
ExistierendeLösungen
MS bietet Compiler (“xsd.exe”)
Compiler hat Einschränkungen (xsd:union und xsd:import)
Diverse andereLösungen, eherwenigeraktiventwickelt
Plugin-Mechanismus in XJC
PluginshabenZugriff auf
XML Schema
AST dergenerierten Java-Klassen
Zusatzinformationen (Binding)
→ PluginzurGenerierung von C#-Klassen
Generierung des C#-Codes über AST und selbstentwickelteBibliothekzurSerialisierung
33
35. XMLS CHEMA → A CTION S CRIPT
XJC-Plugin
Generierung des ActionScript-Codes über AST-Bibliothek meta-as
http://www.badgers-in-foil.co.uk/projects/metaas/
Kein XML-Binding-Framework in ActionScript
→ keine Binding-Information im Code
35
36. Z WISCHENFAZIT
Generierung des Objektmodells
Vorteile
Verringerung des Entwicklungsaufwandes
bei richtiger Anwendung und in Abhängigkeit von der Sprache Fehlerprüfung durch Compiler
Nachteile
Unterschiede der Sprachen: kovariante Rückgabewerte, Enumerationen
Ansatz erfordert Strukturgleichheit der Objektmodelle
XML Schema zur Beschreibung des Objektmodells
Vorteile
Schnelle Erfolge bei der Generierung
UML immer noch zur Beschreibung der XML Schemata möglich
Nachteile
Keine grafische Ansicht
36
38. F EHLERCODES (1)
Löschen einer ContainerDescription-Instanz kann aus verschieden Gründen
fehlschlagen
Existierende Behälter dieses Typs
Fehlende Benutzerrechte
Typischerweise Kommunikation per Rückgabewert/Exception
38
39. F EHLERCODES (2)
public intdeleteContainerDescription(Stringuuid)
In Java implementiert, von ActionScriptausgerufen
Interpretation des Fehlercodes
GenerierungderFehlercodesausgemeinsamen “Modell”
39
40. Z WISCHENFAZIT
Generierung von Enumerationen von Fehlercodes
Vorteile
Refactoring der Fehlercodes möglich
Pflegeaufwand für Fehlercodes bleibt bei einem Entwickler
Kommunikation zwischen Entwicklern nicht mehr nötig
Automatische Auswertbarkeit des Fehlercodes
Nachteile
Keine
40
41. Agenda
ubigrate – Business ActivityMonitoring
Von der Plattform zur Architektur
Entwicklungsaspekte: Objektmodell, Fehlercodes
Laufzeitaspekte: Kommunikation, Datenbankzugriff
Organisatorisches
Fazit
43. K OMMUNIKATION
Übertragen der Instanzen des Objektmodells zwischen Technologieräumen
Diverse Standard-Technologien: CORBA, Webservices...
43
44. J AVA → F LASH /F LEX UND ZURÜCK
Webservice
Kein Problem in Java
Overhead für UI fraglich
XML über HTTP
Kein Problem in Java
Marshalling/Unmarshalling in Flash/Flex nicht verfügbar
AMF
Binäres Austauschformat, optimierter Resourcenbedarf
Funktioniert über JavaBeans und dazu passende ActionScript-Klassen
In Java verfügbar über BlazeDS oder LCDS
Probleme
Enumerationen
Wrappertypen
44
45. J AVA → C# UND ZURÜCK
JMS für die Kommunikation zwischen Terminal und Server
Technologieraum Java->Java: unproblematisch
Versand der Nachrichten serialisiert oder als XML-Botschaften möglich
Technologieraum C#->Java bzw. Java->C#:
Versand der Nachrichten nur als XML-Botschaft möglich
JMS-Anbindung im .NET-Bereich (speziell .NET CF) fehlt
Nachimplementierung basierend auf REST
Zuverlässige Zustellung über Ablage im Dateisystem
45
46. Z WISCHENFAZIT
Übertragung von Instanzen über Technologieraumgrenzen hinweg
XML-Serialisierbarkeit ist hilfreich, aber nicht in jedem Technologieraum
u.U. Einsatz alternativer Serialisierungsformate notwendig
Asynchrone Kommunikationsmechanismen wie JMS sind in der Regel stark
technologieraum-gebunden
46
49. K ONFIGURATION OR-M APPER
ExistierendeLösungen
Existierendes XJC-PluginHyperJAXBfür JPA
Idee gut, Umsetzungfragwürdig
Eigenentwicklung XJC-Plugin
Generierung von Hibernate-Mappings
(Hibernate-Mappings sind XML-Files, daherGenerierung per JAXB)
Zusatzinformationfür den OR-Mapperwird in Binding-Files hinterlegt
49
51. G EMEINSAME D ATENBANKNUTZUNG
ubigrate Express
Einfache Zusammenstellung von Integrationslösungen durch Endkunde im Web
Sofortige Erstellung
Nicht kommerzialisiert
Gemeinsame Datenbanknutzung
Beschreiben der Datenbank mittels Java
Lesen/Schreiben der Datenbank mittels Ruby
Datenbankschema durch unseren gewählten Ansatz bereits vordefiniert
Adaption von ActiveRecord zur Parametrisierung durch Hibernate-Mappings
Convention-over-Configuration verursacht größere Probleme bei gemeinsamer
Datenbanknutzung
Besonderes Problem: Abbildung der Vererbung
siehe [Grünberg, 2011]
51
52. Z WISCHENFAZIT
Generierung von OR-Mapper-Konfigurationen
Vorteile
Zeitersparnis
Verringerung von Fehlern in den Mappings
Zentrale Vorgaben leichter durchsetzbar
Nachteile
Strukturgleichheit von Persistenz- und Serialisierungsobjekten
Gemeinsame Datenbanknutzung
Machbar
Aufwand hängt von Technologieräumen ab, kann u.U. höher als erwartet sein
52
53. Agenda
ubigrate – Business ActivityMonitoring
Von der Plattform zur Architektur
Entwicklungsaspekte: Objektmodell, Fehlercodes
Laufzeitaspekte: Kommunikation, Datenbankzugriff
Organisatorisches
Fazit
54. B UILD - UND R ELEASE -M ANAGEMENT
Grundfrage
Build jeweils durch “native” Mittel der Technologieräume oder
durch Mittel eines ausgewählten Raumes
Unser Ansatz
Auswahl eines Technologieraums für zentrales Build-Management
Zusammenfassung der Ergebnisse (gemeinsames Setup)
Java mit ANT und Jenkins
Naheliegend wegen XJC-Einsatz
Build-TargetFlash/Flex unproblematisch (ANT-Tasks verfügbar)
Build-Target C# erfordert u.U. Nacharbeiten an existierenden ANT-Tasks
54
55. T EAM -S ETUP
Gesichtspunkte
Effizienz
Ausfallsicherheit
Geringe Einstiegshürde
Ansätze
Paare von Spezialisten
Alles-Könner
Mischung
Unser Ziel
Jedes Team-Mitglied in zwei Technologieräumen unterwegs.
Jeder Technologieraum wird von zwei Team-Mitgliedern beherrscht.
55
56. Agenda
ubigrate – Business ActivityMonitoring
Von der Plattform zur Architektur
Entwicklungsaspekte: Objektmodell, Fehlercodes
Laufzeitaspekte: Kommunikation, Datenbankzugriff
Organisatorisches
Fazit
59. A BKÜRZUNGEN (1)
AIR Adobe Integrated Runtime
AMF Action Message Format
AST Abstract Syntax Tree
CORBA Common Object Request Broker Architecture
CST Concrete Syntax Tree
DBMS/RDBMS Database Management System (Relational ~)
DOM Document Object Model
JAXB Java Architecture for XML Binding
JAXP Java API for XML Processing
JMS Java Message Service
JSON JavaScript Object Notation
MDA Model Driven Architecture
OSGi Open Services Gateway Initiative
59
60. A BKÜRZUNGEN (2)
ORM Object-Relational Mapper
REST Representational State Transfer
RFID Radio-Frequency Identification
SAX Simple API for XML
StAX Streaming API for XML
SPS SpeicherprogrammierbareSteuerung
WPF Windows Presentation Foundation
YAML YAML Ain't Markup Language
60
61. I N EIGENER S ACHE
Java User Group Sachsen
www.jugsaxony.org
www.facebook.com/jugsaxony
@jugsaxony
19. Januar 2012
Einführung in Android und Androids Open ADK-Implementierung
Rainer Fritzsche, Noser Engineering AG
01. März 2012
RAP wirdmobil Jochen Krause, EclipseSource
61