SlideShare ist ein Scribd-Unternehmen logo
1 von 62
Technologieraum-
übergreifendeSoftwareentwicklungimUmfeldintelligent
erGeräte

Falk Hartmann, ubigrate GmbH
Agenda




   ubigrate – Business ActivityMonitoring
   Von der Plattform zur Architektur
   Entwicklungsaspekte: Objektmodell, Fehlercodes
   Laufzeitaspekte: Kommunikation, Datenbankzugriff
   Organisatorisches
   Fazit
Agenda




   ubigrate – Business ActivityMonitoring
   Von der Plattform zur Architektur
   Entwicklungsaspekte: Objektmodell, Fehlercodes
   Laufzeitaspekte: Kommunikation, Datenbankzugriff
   Organisatorisches
   Fazit
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
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
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
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
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
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
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
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
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
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
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
Agenda




   ubigrate – Business ActivityMonitoring
   Von der Plattform zur Architektur
   Entwicklungsaspekte: Objektmodell, Fehlercodes
   Laufzeitaspekte: Kommunikation, Datenbankzugriff
   Organisatorisches
   Fazit
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
P LATTFORM - ÜBERGREIFENDE P ROGRAMMIERUNG


Ziel: Einsparung von Entwicklungskosten
 Wiederverwendung möglichst unveränderter Artefakte (Code)
 Cross-platformDevelopment
 vgl. Portierbarkeit (z.B. ANSI-C)
Beispiele
 Java („Writeonce, runanywhere“)
 .NET
 Flash
 Perl




                                                              17
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
T ECHNOLOGIERAUM (K URTEV )




                   nach [Kurtev et al., 2002]
                                                19
Ü BERSICHT T ECHNOLOGIERÄUME




                               20
P LATTFORM VS . T ECHNOLOGIERAUM




                                   21
A RCHITEKTUR




          A1




               A3
                         A5   A2

                    A4




                                   22
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
Agenda




   ubigrate – Business ActivityMonitoring
   Von der Plattform zur Architektur
   Entwicklungsaspekte: Objektmodell, Fehlercodes
   Laufzeitaspekte: Kommunikation, Datenbankzugriff
   Organisatorisches
   Fazit
Problematik 1: Objektmodell
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
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
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
XML S CHEMA C ONTAINER D ESCRIPTION . XSD




Verhältniszwischen XML Schema und UML siehe [Carlson, 2001]




                                                              29
XMLS CHEMA → J AVA (1)


JAXB – Java-XML Binding [Reinhold, 1999]




 Intra-level transformation (siehe [Kurtev, 2005])


                                                      30
XMLS CHEMA → J AVA (2)




                         31
XMLS CHEMA → J AVA (3)




                         32
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
XMLS CHEMA → C# (2)




                      34
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
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
Problematik 2: Fehlercodes
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
F EHLERCODES (2)


public intdeleteContainerDescription(Stringuuid)
 In Java implementiert, von ActionScriptausgerufen
 Interpretation des Fehlercodes
 GenerierungderFehlercodesausgemeinsamen “Modell”




                                                      39
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
Agenda




   ubigrate – Business ActivityMonitoring
   Von der Plattform zur Architektur
   Entwicklungsaspekte: Objektmodell, Fehlercodes
   Laufzeitaspekte: Kommunikation, Datenbankzugriff
   Organisatorisches
   Fazit
Problematik 3: Kommunikation
K OMMUNIKATION




Übertragen der Instanzen des Objektmodells zwischen Technologieräumen
 Diverse Standard-Technologien: CORBA, Webservices...




                                                                        43
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
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
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
Problematik 4: Datenbankzugriff
D ATENBANKZUGRIFF




OR-MapperbenötigtZusatzinformationen
 Primary Keys
 Verwaltung von Assoziationen (Sortierung, Kaskadierung von Operationen)




                                                                            48
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
G ENERIERUNGDER OR-M APPER -K ONFIGURATION




                                             50
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
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
Agenda




   ubigrate – Business ActivityMonitoring
   Von der Plattform zur Architektur
   Entwicklungsaspekte: Objektmodell, Fehlercodes
   Laufzeitaspekte: Kommunikation, Datenbankzugriff
   Organisatorisches
   Fazit
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
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
Agenda




   ubigrate – Business ActivityMonitoring
   Von der Plattform zur Architektur
   Entwicklungsaspekte: Objektmodell, Fehlercodes
   Laufzeitaspekte: Kommunikation, Datenbankzugriff
   Organisatorisches
   Fazit
FAZIT


Technologieraum-übergreifendeProgrammierung
 u.U. einzigeMöglichkeit, mehrerePlattformenzubedienen
 ErhöhterAufwandgegenüberplattformübergreifenderProgrammierung


 MinimierenderAnzahlderTechnologieräume
 Reduktion des AufwandsüberCodegenerierung




                                                                  57
L ITERATUR




             58
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
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
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
K ONTAKT


Falk Hartmann                       ubigrate GmbH
Leiter Softwareentwicklung          Schnorrstr. 76
Tel.:  +49 (351) 21187-27           01069 Dresden
Fax:   +49 (351) 21187-28           Germany
Email: falk.hartmann@ubigrate.com   Web: www.ubigrate.com




                                                            62

Weitere ähnliche Inhalte

Andere mochten auch

Social media marketing
Social media marketingSocial media marketing
Social media marketing
idealogues
 
Protocol Engineering: Beschreibung und Entwicklung von Kommunikationsprotokollen
Protocol Engineering: Beschreibung und Entwicklung von KommunikationsprotokollenProtocol Engineering: Beschreibung und Entwicklung von Kommunikationsprotokollen
Protocol Engineering: Beschreibung und Entwicklung von Kommunikationsprotokollen
Falk Hartmann
 
PASTOR ARQUITECTES
PASTOR ARQUITECTESPASTOR ARQUITECTES
PASTOR ARQUITECTES
c_pastor
 
Guest Lecture 2011.06 - Georg Greve - Mit FOSS Geld verdienen (Digital Sustai...
Guest Lecture 2011.06 - Georg Greve - Mit FOSS Geld verdienen (Digital Sustai...Guest Lecture 2011.06 - Georg Greve - Mit FOSS Geld verdienen (Digital Sustai...
Guest Lecture 2011.06 - Georg Greve - Mit FOSS Geld verdienen (Digital Sustai...
Marcus Dapp
 
Margelhs1
Margelhs1Margelhs1
Margelhs1
kabbada
 

Andere mochten auch (20)

Social media marketing
Social media marketingSocial media marketing
Social media marketing
 
Gesamt1
Gesamt1Gesamt1
Gesamt1
 
DJ HERO 2
DJ HERO 2DJ HERO 2
DJ HERO 2
 
Statistik, Tätigkeitsbericht 2010
Statistik, Tätigkeitsbericht 2010Statistik, Tätigkeitsbericht 2010
Statistik, Tätigkeitsbericht 2010
 
Digitalisierung für Einsteiger - Praxisorientierter Workshop für Unternehmer
Digitalisierung für Einsteiger - Praxisorientierter Workshop für UnternehmerDigitalisierung für Einsteiger - Praxisorientierter Workshop für Unternehmer
Digitalisierung für Einsteiger - Praxisorientierter Workshop für Unternehmer
 
Mobile Strategien und systematische Einführung in Unternehmen - Hagen Sexauer
Mobile Strategien und systematische Einführung in Unternehmen - Hagen SexauerMobile Strategien und systematische Einführung in Unternehmen - Hagen Sexauer
Mobile Strategien und systematische Einführung in Unternehmen - Hagen Sexauer
 
Protocol Engineering: Beschreibung und Entwicklung von Kommunikationsprotokollen
Protocol Engineering: Beschreibung und Entwicklung von KommunikationsprotokollenProtocol Engineering: Beschreibung und Entwicklung von Kommunikationsprotokollen
Protocol Engineering: Beschreibung und Entwicklung von Kommunikationsprotokollen
 
Brennpunkt eTourism: Bausteine erfolgreicher Suchmaschinenoptimierung
Brennpunkt eTourism: Bausteine erfolgreicher SuchmaschinenoptimierungBrennpunkt eTourism: Bausteine erfolgreicher Suchmaschinenoptimierung
Brennpunkt eTourism: Bausteine erfolgreicher Suchmaschinenoptimierung
 
PASTOR ARQUITECTES
PASTOR ARQUITECTESPASTOR ARQUITECTES
PASTOR ARQUITECTES
 
Innovationen durch Netzwerke - Beispiele aus Niedersachsen
Innovationen durch Netzwerke - Beispiele aus NiedersachsenInnovationen durch Netzwerke - Beispiele aus Niedersachsen
Innovationen durch Netzwerke - Beispiele aus Niedersachsen
 
Guest Lecture 2011.06 - Georg Greve - Mit FOSS Geld verdienen (Digital Sustai...
Guest Lecture 2011.06 - Georg Greve - Mit FOSS Geld verdienen (Digital Sustai...Guest Lecture 2011.06 - Georg Greve - Mit FOSS Geld verdienen (Digital Sustai...
Guest Lecture 2011.06 - Georg Greve - Mit FOSS Geld verdienen (Digital Sustai...
 
Vereinsdaten pflegen für Chöre im Schwäbischen Chorverband
Vereinsdaten pflegen für Chöre im Schwäbischen ChorverbandVereinsdaten pflegen für Chöre im Schwäbischen Chorverband
Vereinsdaten pflegen für Chöre im Schwäbischen Chorverband
 
Social Media - Jeder kann, keiner muss, jeder sollte!?
Social Media - Jeder kann, keiner muss, jeder sollte!?Social Media - Jeder kann, keiner muss, jeder sollte!?
Social Media - Jeder kann, keiner muss, jeder sollte!?
 
Social Media – Chancen und Gefahren, Dos und Don'ts und Praxisbeispiele für K...
Social Media – Chancen und Gefahren, Dos und Don'ts und Praxisbeispiele für K...Social Media – Chancen und Gefahren, Dos und Don'ts und Praxisbeispiele für K...
Social Media – Chancen und Gefahren, Dos und Don'ts und Praxisbeispiele für K...
 
Margelhs1
Margelhs1Margelhs1
Margelhs1
 
Lanz1
Lanz1Lanz1
Lanz1
 
Sami Khalaji Notfälle in der Zahnmedizin
Sami Khalaji Notfälle in der ZahnmedizinSami Khalaji Notfälle in der Zahnmedizin
Sami Khalaji Notfälle in der Zahnmedizin
 
Groups 2010.05: Google Street View Debatte (Digital Sustainability)
Groups 2010.05:  Google Street View Debatte (Digital Sustainability)Groups 2010.05:  Google Street View Debatte (Digital Sustainability)
Groups 2010.05: Google Street View Debatte (Digital Sustainability)
 
Kneipenabend
KneipenabendKneipenabend
Kneipenabend
 
Lanz2
Lanz2Lanz2
Lanz2
 

Ähnlich wie Technologieraum übergreifende Programmierung

Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Andreas Schreiber
 
07 06 Xpertivy (Office 2003)
07 06 Xpertivy (Office 2003)07 06 Xpertivy (Office 2003)
07 06 Xpertivy (Office 2003)
soreco
 

Ähnlich wie Technologieraum übergreifende Programmierung (20)

Die Bedeutung der Diagnose in der Fahrzeugentwicklung
Die Bedeutung der Diagnose in der FahrzeugentwicklungDie Bedeutung der Diagnose in der Fahrzeugentwicklung
Die Bedeutung der Diagnose in der Fahrzeugentwicklung
 
Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Top 10 Internet Trends 2001
Top 10 Internet Trends 2001
 
Python in der Luft- und Raumfahrt
Python in der Luft- und RaumfahrtPython in der Luft- und Raumfahrt
Python in der Luft- und Raumfahrt
 
Domain-Driven Design in der Praxis
Domain-Driven Design in der PraxisDomain-Driven Design in der Praxis
Domain-Driven Design in der Praxis
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
 
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
SAP_Basis_Klassisch.pdf
SAP_Basis_Klassisch.pdfSAP_Basis_Klassisch.pdf
SAP_Basis_Klassisch.pdf
 
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertRequirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
Forum Mobile Instandhaltung in Köln
Forum Mobile Instandhaltung in KölnForum Mobile Instandhaltung in Köln
Forum Mobile Instandhaltung in Köln
 
ICIS User Group - Oberflächentests mittels LCT deklarativ angehen
ICIS User Group - Oberflächentests mittels LCT deklarativ angehenICIS User Group - Oberflächentests mittels LCT deklarativ angehen
ICIS User Group - Oberflächentests mittels LCT deklarativ angehen
 
2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros
 
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
 
Python, Plone und Zope in der Luft- und Raumfahrtforschung
Python, Plone und Zope in der Luft- und RaumfahrtforschungPython, Plone und Zope in der Luft- und Raumfahrtforschung
Python, Plone und Zope in der Luft- und Raumfahrtforschung
 
OSLC in Aktion
OSLC in AktionOSLC in Aktion
OSLC in Aktion
 
Webinar: Effiziente Digitalisierungsstrategien für den Mittelstand
Webinar: Effiziente Digitalisierungsstrategien für den Mittelstand  Webinar: Effiziente Digitalisierungsstrategien für den Mittelstand
Webinar: Effiziente Digitalisierungsstrategien für den Mittelstand
 
07 06 Xpertivy (Office 2003)
07 06 Xpertivy (Office 2003)07 06 Xpertivy (Office 2003)
07 06 Xpertivy (Office 2003)
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
 

Mehr von Falk Hartmann (8)

Risikomanagement in der Softwareentwicklung
Risikomanagement in der SoftwareentwicklungRisikomanagement in der Softwareentwicklung
Risikomanagement in der Softwareentwicklung
 
An Introduction to AngularJS
An Introduction to AngularJSAn Introduction to AngularJS
An Introduction to AngularJS
 
Risiko Management in der Softwareentwicklung
Risiko Management in der SoftwareentwicklungRisiko Management in der Softwareentwicklung
Risiko Management in der Softwareentwicklung
 
D3ML Session
D3ML SessionD3ML Session
D3ML Session
 
An Architecture for an XML-Template Engine enabling Safe Authoring
An Architecture for an XML-Template Engine enabling Safe AuthoringAn Architecture for an XML-Template Engine enabling Safe Authoring
An Architecture for an XML-Template Engine enabling Safe Authoring
 
A Distributed Staged Architecture for Multimodal Applications
A Distributed Staged Architecture for Multimodal ApplicationsA Distributed Staged Architecture for Multimodal Applications
A Distributed Staged Architecture for Multimodal Applications
 
Drahtwanderung: Wir machen den NeXTen Schritt
Drahtwanderung: Wir machen den NeXTen SchrittDrahtwanderung: Wir machen den NeXTen Schritt
Drahtwanderung: Wir machen den NeXTen Schritt
 
Sichere templategestützte Verarbeitung von XML-Dokumenten
Sichere templategestützte Verarbeitung von XML-DokumentenSichere templategestützte Verarbeitung von XML-Dokumenten
Sichere templategestützte Verarbeitung von XML-Dokumenten
 

Technologieraum übergreifende Programmierung

  • 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
  • 17. P LATTFORM - ÜBERGREIFENDE P ROGRAMMIERUNG Ziel: Einsparung von Entwicklungskosten  Wiederverwendung möglichst unveränderter Artefakte (Code)  Cross-platformDevelopment  vgl. Portierbarkeit (z.B. ANSI-C) Beispiele  Java („Writeonce, runanywhere“)  .NET  Flash  Perl 17
  • 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
  • 19. T ECHNOLOGIERAUM (K URTEV ) nach [Kurtev et al., 2002] 19
  • 20. Ü BERSICHT T ECHNOLOGIERÄUME 20
  • 21. P LATTFORM VS . T ECHNOLOGIERAUM 21
  • 22. A RCHITEKTUR A1 A3 A5 A2 A4 22
  • 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
  • 30. XMLS CHEMA → J AVA (1) JAXB – Java-XML Binding [Reinhold, 1999]  Intra-level transformation (siehe [Kurtev, 2005]) 30
  • 31. XMLS CHEMA → J AVA (2) 31
  • 32. XMLS CHEMA → J AVA (3) 32
  • 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
  • 34. XMLS CHEMA → C# (2) 34
  • 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
  • 48. D ATENBANKZUGRIFF OR-MapperbenötigtZusatzinformationen  Primary Keys  Verwaltung von Assoziationen (Sortierung, Kaskadierung von Operationen) 48
  • 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
  • 50. G ENERIERUNGDER OR-M APPER -K ONFIGURATION 50
  • 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
  • 57. FAZIT Technologieraum-übergreifendeProgrammierung  u.U. einzigeMöglichkeit, mehrerePlattformenzubedienen  ErhöhterAufwandgegenüberplattformübergreifenderProgrammierung  MinimierenderAnzahlderTechnologieräume  Reduktion des AufwandsüberCodegenerierung 57
  • 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
  • 62. K ONTAKT Falk Hartmann ubigrate GmbH Leiter Softwareentwicklung Schnorrstr. 76 Tel.: +49 (351) 21187-27 01069 Dresden Fax: +49 (351) 21187-28 Germany Email: falk.hartmann@ubigrate.com Web: www.ubigrate.com 62

Hinweis der Redaktion

  1. - Intelligente Geräte eher einführen -> in der Agenda rausnehmen!
  2. - Steuerungsmöglichkeiten des XJC (Customizations)
  3. - Typischer Fall fürDiplomarbeit
  4. - Typischer Fall fürDiplomarbeit