Umstellung eines(riesen)Programmes auf Java:Was bietet Java

[Adventstee]

Hallo Community.

Wir sind eine Hard/Softwarefirma und haben ein Programm in dem 20 Mannjahre drinstecken.
Da dieses nun etwas betagt ist und langsam unübersichtlich und einfach veraltet wollen wir uns auf neue Wege begeben.
Bisher ein reines Windows Programm.

Wir machen folgendes:
Zeiterfassung und Zutrittskontrolle.
Wir haben also unsere Hardwareterminals die an der Wand hängen und per TCP/IP, Rs232, Rs 485 oder USB angesprochen werden.
Die Daten der Terminals werden per Software abgeholt und darin verrechnet.
Es gibt natürlich auch reine Software Lösungen für die Erfassung.
Wir haben auch Karten die per USB-Leser gelesen und beschrieben werden können.

Wir haben auch ein "Webprojekt" welches per Berkeley Socket an die Software anfragt und die Daten im Browser darstellt.
Das Problem hierbei ist, daß immer eine Verbindung zum Server bestehen muss. Gibt es keine Verbindung kann auch nicht gebucht werden.

Wir wollen nun folgenes:

Gänzlich neue Oberfläche. Bunt, übersichtlich und modern.
Der Code der alles berechnet soll gleich bleiben, bzw. soll dann irgendwie in Java implementiert werden können.
(Ist ein (ANSI)reiner C-Code.)
Es dreht sich also rein um die Oberfläche.

Die Frage ist nun was Java alles kann.
Hier die anforderungen:

- Oberfläche soll grafisch modern sein (kein Einheitsgrau)
- Menü soll dem User entsprechen angepasst werden können. Also Menüpunkte hinzufügen/entfernen.
- Multi User und Multithreading fähigkeit
- Es sollen die gleichen Klassen für ein Java Applet und Java Anwendung benutzt werden können.
- Ansprechen der Seriellen und USB Schnittstellen auf allen Plattformen.
- Einbinden und verwenden der vorhandenen C-Funktionen (ca. 600 C- Dateien mit 500-3000 Codezeilen)
- Nutzen von Airport unter Mac OSX (iMAc)


Es sollen viele Funktionen aus der jetzigen Software rausfliegen und nur auf das meist gebrauchte beschränkt werden.
Wir werden und dafür 2 Jahre Zeit lassen und unsere Vorhandenen Produkte weiterhin verbessern und supporten.

Es soll eine Software geben die also Applikation läuft also auch verteilt im Webbrowser.
wenn jetzt der Kollege Klassen schreibt für die Applikation, zb. Datenzugriff und bereitstellung dieser, kann ich dann diesselbe als Applet für den Webbrowser einbinden?

Mit Asp.net/C# geht das, das hab ich schon getestet.

Daß man USB Schnittstellen nicht ansprechen kann, weiß ich bereits, die Frage ich jedoch, geht das wenigestens unter Windows?
Kann ich da vorhandene C/C++ Bibiotheken einbinden?

Wie sieht es mit Linux und vor allem Mac OSX aus?
Gibts dafür vorhandene Bibiotheken? (jUSB, was taucht das?)

Die Software wird von 5-1000 Mitarbeiter, je nach Anforderung gleichzeitig genutzt.
Eignet sich Java dafür?

So, das wars erstmal.
Danke fürs lesen und antworten...
Grüße Adventstee

 

[The_S]

Hi Advenstee,

bist du dir sicher, dass für eine derartige "Planung" ein öffentliches Forum die richtige Ansprechstelle ist? Sollte das nicht evtl. druch einen/mehreren professionellen Consultants erledigt werden? Also ich als Chef, würde mich nicht nach den Beiträgen eines Forums richten, aber ok ...

- Oberfläche soll grafisch modern sein (kein Einheitsgrau)

Durch die Unterschiedlichen Look and Feels ist das sehr einfach in Java zu realisieren

- Menü soll dem User entsprechen angepasst werden können. Also Menüpunkte hinzufügen/entfernen.

kein Problem

- Multi User und Multithreading fähigkeit

kein Problem

- Es sollen die gleichen Klassen für ein Java Applet und Java Anwendung benutzt werden können.

Es muss irgendwo natürlich angegeben werden, ob ein JFrame (Anwendung) oder ein JApplet (Applet) verwendet werden soll. Aber Wenn das Applet dann signiert wird, sollte das auch ohne größere Probleme möglich sein.

- Ansprechen der Seriellen und USB Schnittstellen auf allen Plattformen.

Für diese Schnittstellen gibt es einige gute Libs - aber inwieweit diese plattformabhängig sind, kann ich nicht beurteilen, da ich noch nicht mit diesen Libs gearbeitet habe. Ich denke aber mal, dass man das auch Plattfromunabhängig hinbekommen sollte

- Einbinden und verwenden der vorhandenen C-Funktionen (ca. 600 C- Dateien mit 500-3000 Codezeilen)

Über JNI ist es möglich C(++) Code in Java einzubinden

- Nutzen von Airport unter Mac OSX (iMAc)

Uff ... kA was das ist. Ich war noch nie vor einem MAC gesessen

 

[Adventstee]

Hi Advenstee,

bist du dir sicher, dass für eine derartige "Planung" ein öffentliches Forum die richtige Ansprechstelle ist? Sollte das nicht evtl. druch einen/mehreren professionellen Consultants erledigt werden? Also ich als Chef, würde mich nicht nach den Beiträgen eines Forums richten, aber ok ...

Hallo Hobbit.
Ja das ist schon klar und das werden wir auch tun.
Es ist nur so, daß in einem Forum indem viele Erfahrene Leute zusammenkommen es viele verschiedene Meinungen gibt und genau diese Interessieren mich

Deine Antworten klingen schonmal gut, die (schmerzliche) Erfahrung werden wir dann schon selbst machen müssen
Airport für Mac ist nichts anderes als eine eingebaute WLAN Karte

 

[neumi]

Also zum Thema RS232 Schnittstellen und verschiedenen OS

Grundsätzlich kann java nicht auf die Schnittstellen zugreifen, aber nätürlich hat SUN eingigen Lösungen einfallen lassen.

In Windows muss dazu eine DLL eingebunden werden, welche natürlich unter UNIX nicht funktioniert.

Aber auch dafür gibt es einige Lösungen. Aber ich habe da meine Zweifel das dieser Zugriff auf die RS232 Schnittstelle Betriebssystem unabhängig ist. [lasse mich gerne verbessern]

 

[Adventstee]

Naja vielleicht weiß das der eine oder andere hier.

Da es die Serielle Schnittstelle immer weniger gibt, denke ich ist das nahezu vernachlässigbar und wir sollten verstärkt auf USB 2.0/3.0 setzen.

Das Problem hierbei ist: Es geht immer mehr richtung Web-Applikation.
Also es soll eine Web-Desktop Anwendung werden.
Der Abgleich mit einer Java anwendung auf einem Webhoster im Internet (Java läuft ja überall, im Browser oder)
usw usf...

Die Alternative wäre eben asp.net/c# wobei wir dann Plattform gebunden wären...

 

[J.C.]

Hallo,

die frage die sich heut zu tage stellt ist doch: Java oder .Net... und da tendiere ich doch klar zu Java. Warum? Kostengünstig, moderne Techniken und Frameworks (OSGi, EJB) gute Applikationsserver (JBoss) einfache realisierung von Fontends (JSP).

Soll das Frontend nur im Browser "erscheinen" dann könnte man auch mit anderen Programmiersprachen arbeiten. Will man aber anwendungen auf verschiedenen BS laufen lassen dann bleibt "nur" Java als alternative. .Net anwendungen auf einem Linux oder Mac rechner laufen zu lassen ist quasi nicht möglich. Es gibt bereits erste ansätze, die das realisieren >wollen< ist aber auf keinen Fall für professionelle Software empfehlenswert.

Wie von Hobbit im Blutrausch erwähnt, lassen sich Bibliotheken anderer Programmiersprachen mit dem Native Interface einbinden.

Das wars was mir dazu einfällt


MfG,
J.C.

 

[Adventstee]

Das hieße also, ich könnte irgendwelche unix Bibliotheken nehmen und damit die USB Schnittstelle ansprechen?
Das Problem bei Java und Mac OS ist eben, daß Apple immer hinterher ist.
FÜr JAva 6 müsste jeder Anwender das neueste Mac OX (Leopard) haben...das wird auch nicht jeder wollen...

Die Anwendung soll dann eben auf allen möglichen Ebenen laufen. Vom Handheld über den Tablet PC bis zum handy...(eingeschränkt natürlich)

 

[Gast]

Hallo,

Wieviel Erfahrung habt ihr eigentlich mit Java allgemein bzw. in der objectorientierten Softwareentwicklung ?

Also mittlere bis groesere JavaProjekte benoetigen eine Architektur. Insbesondere, wenn man eine Mulitchannelfaehigkeit (Desktop + Weboberflaeche) herstellen moechte.

Desweiteren ist Java ein sehr sehr weites Feld angefangen von Spring, JPA, Hibernate bis zu JSF, Struts, Eclipse RCP etc.. Uebrigens ganz zu schweigen von MDA etc...

Mal ein Skizze was auf euch zukommt um SINNVOLL Java Projekte abwickeln zu koennen.

Definition eines passenden Entwicklungsprozesses
- Anforderungsanalyse
- Formalisierung der Anforderungen
- Dokumentation der Anforderungen

Erstellung einer ReferenzArchitektur
- DB Anbindung (JPA ...)
- Interaktion der einzelnen Schichten und "Module" (Spring, WebServices ...)
- Frontendentwicklung (JSF, Swing, RCP ...)
- "Verbindung mit der Hardware"
- Transformation der Doku in Code ("Transformaionsmodell")

Erstellung eines BuildManagement (z.B. mit maven)

Erstellung Testmanagement

Werkzeugauswahl etc. etc. etc.

Die Liste duerfte noch weitaus laenger sein...

Am Ende eine Schlussbemerkung:

Du stellst hier grundlegende technische Fragen, ihr habt wenig oder keine Erfahrung mit Java Projekten und ohne euch zu nahe tretten zu wollen: Ihr habt vermutlich die technische Entwicklung der letzten zwei bis vier Jahre verpennt... (Spring, JPA, Hibernate, JSF, MDA, Flex...)

aber ihr habt bereits einen Rahmenterminplan:

Es sollen viele Funktionen aus der jetzigen Software rausfliegen und nur auf das meist gebrauchte beschränkt werden.
Wir werden und dafür 2 Jahre Zeit lassen und unsere Vorhandenen Produkte weiterhin verbessern und supporten.

DAS KANN SO NICHT FUNKTIONIEREN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

weitere Anmerkung:

Sagen euch Begriffe wie Ajax ,Flex oder auch JavaWebStart eigentlich etwas ?



Ich hoffe ich war nicht zu direkt, falls ja moechte ich mich dafuer entschuldigen...

Es ist zwar eine etwas komische Art der Kundengewinnung aber einige Dinge muessen einfach ausgesprochen werden... Falls du dennoch ein Interesse an einer Zusammenarbeit hast wuerde ich mich freuen, wenn du an folgenden E-Mail Adresse ein Nachricht schicken koenntest. "klarkimming@gmx.net" (dies ist nicht meine "normale" Geschaeftsemailadresse!, die moechte ich hier nicht veroeffentlichen).

KurzProfil:

- Teil eines Zwei Personenteams
- Spezialisiert auf Java-Softwareentwicklung. Als Basis dienen modere Technologien und Ansaetze
- meine Berufserfahrung mehr als zwei Jahre
- Berufserfahrung meines Teammitglieds (ueber 15 Jahre...)

Fazit wir haben eine gute Mischung aus Innovationsfreude und sehr viel Erfahrung... Der Bereich Hardwareanbindung gehoert allerdings nicht zu unseren Kernkompetenzen.

Gruesse

Gast

 

[byte]

Uebrigens ganz zu schweigen von MDA

[...]

- Formalisierung der Anforderungen

[...]

- Transformation der Doku in Code ("Transformaionsmodell")

Das klingt aber sehr akademisch... erinnert mich an meine Studienzeit. :roll:

 

[tfa]

DAS KANN SO NICHT FUNKTIONIEREN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Unser anonymer Gast hat in seinen mehr als zwei Jahren Berufserfahrung wohl noch nicht so viel gesehen, was in der realen Welt alles möglich ist. :lol:

 

[Janus]

2 jahre für die portierung einer ansi c anwendung mit ca. 1 mio zeilen code nach java sind aber schon recht sportlich angesetzt.

 

[Gast]

2 jahre für die portierung einer ansi c anwendung mit ca. 1 mio zeilen code nach java sind aber schon recht sportlich angesetzt.

1 mio Zeilen? Geht aber aus den Anforderung nicht hervor. Bestehender c Code soll ja nach Möglichkeit wiederverwendet werden. (JNI)

Wenn es nur um eine neue Oberfläche geht, ist es auf jeden fall realistisch. Dazu kommt der Austausch der Hardwareanbindungsschicht, die aber sicherlich getrennt davon betrachtet werden kann. Somit könnte man mit und mit einzelne Komponenten der Anwendung auf Java migrieren.

Wobei die Modernisierung der Oberfläche eventuell die Kernaufgabe darstellt. Wenn alles andere weiterverwendet kann muss es nicht ausgetauscht werden ?!

 

[quippy]

Bei JNI aus einem Servlet im JBoss (oder anderem Applikationserver) habe ich immer etwas Bauchschmerzen - die vor allem daher rühren, daß wir damit schon mal gut auf die Klappe gefallen sind.

Grundsätzlich funktionert das JNI super. Dummerweise reißt ein Fehler in den angesprochenen NativeBibliotheken gerne die gesamte Virtuelle Maschine mit runter - d.h. in diesem Fall den ganzen Applikation-Server!

Das bedeutet, ein kleiner Fehler wie ein Memory-Leak in einer der Bibliotheken, welches so nicht auffällt, würde nun nicht in einem Käfig explodieren, sondern alle Anwendungen, die im Web hängen, mit betreffen und stoppen.

Wie gesagt, wenn das Zeuch läuft, dann ist das eine gute Idee - aber vielleicht sollte man darüber nachdenken, die C-Calls und den JBoss zu entkoppeln.

 

[maki]

Wie gesagt, wenn das Zeuch läuft, dann ist das eine gute Idee - aber vielleicht sollte man darüber nachdenken, die C-Calls und den JBoss zu entkoppeln.

Gehört JNI nicht zu den Dingen, die man in einem App Server nicht machen darf/soll, wie zB Dateien direkt mit java.io.File lesen/ändern?

 

[quippy]

Wie gesagt, wenn das Zeuch läuft, dann ist das eine gute Idee - aber vielleicht sollte man darüber nachdenken, die C-Calls und den JBoss zu entkoppeln.

Gehört JNI nicht zu den Dingen, die man in einem App Server nicht machen darf/soll, wie zB Dateien direkt mit java.io.File lesen/ändern?

Klar darfst Du JNI machen - wie gesagt, es ist gefährlich, aus beschriebenem Grund. Darum wird es nicht empfohlen.

Aber warum sollte man denn nicht mit java.io.File-Objekten arbeiten?

 

[maki]

Klar darfst Du JNI machen - wie gesagt, es ist gefährlich, aus beschriebenem Grund. Darum wird es nicht empfohlen.

Aber warum sollte man denn nicht mit java.io.File-Objekten arbeiten?

File ist nicht transaktional(!), ausserdem kann eine EJB einfach mal so auf einem anderen Server laufen als noch vor 30 Sekunden( darum geht es doch bei EJBs ), also ist java.io.File :noe: ein im AppServer.

Sage nicht das es nicht geht, aber es ist halt prinzipiell falsch
Genauso wie eigene Threads im AppServer starten.

 

[sliwalker]

Klar darfst Du JNI machen - wie gesagt, es ist gefährlich, aus beschriebenem Grund. Darum wird es nicht empfohlen.

Aber warum sollte man denn nicht mit java.io.File-Objekten arbeiten?

File ist nicht transaktional(!), ausserdem kann eine EJB einfach mal so auf einem anderen Server laufen als noch vor 30 Sekunden( darum geht es doch bei EJBs ), also ist java.io.File :noe: ein im AppServer.

Sage nicht das es nicht geht, aber es ist halt prinzipiell falsch
Genauso wie eigene Threads im AppServer starten.

Hi,

finde ich interessant...
Kann man das irgendwo genauer lesen?
Wir haben eine Schnittstelle die verschiedene Dateien einliest und dawird mit java.io.File Objekten gearbeitet.
Das würde ich dann natürlich gerne ändern wollen, wenn es wirklich so schlimm ist.

Kannst Du mir mehr darüber sagen oder eine Quelle geben wo ich was nachlesen kann?

Danke,

SLi

 

[maki]

Kann man das irgendwo genauer lesen?

Servus,

aus der EJB 3.0 SPek:

21.1.2 Programming Restrictions
This section describes the programming restrictions that a Bean Provider must follow to ensure that the
enterprise bean is portable and can be deployed in any compliant EJB 3.0 container. The restrictions
apply to the implementation of the business methods. Section 21.2, which describes the container’s
view of these restrictions, defines the programming environment that all EJB containers must provide.

• An enterprise bean must not use read/write static fields. Using read-only static fields is
allowed. Therefore, it is recommended that all static fields in the enterprise bean class be
declared as final.
This rule is required to ensure consistent runtime semantics because while some EJB containers may
use a single JVM to execute all enterprise bean’s instances, others may distribute the instances across
multiple JVMs.

• An enterprise bean must not use thread synchronization primitives to synchronize execution of
multiple instances.
This is for the same reason as above. Synchronization would not work if the EJB container distributed
enterprise bean’s instances across multiple JVMs.

• An enterprise bean must not use the AWT functionality to attempt to output information to a
display, or to input information from a keyboard.
Most servers do not allow direct interaction between an application program and a keyboard/display
attached to the server system.

• An enterprise bean must not use the java.io package to attempt to access files and directories
in the file system.
The file system APIs are not well-suited for business components to access data. Business components
should use a resource manager API, such as JDBC, to store data.

• An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or
use a socket for multicast.
The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not
allow it to be a network server. Allowing the instance to become a network server would conflict with
the basic function of the enterprise bean— to serve the EJB clients.

• The enterprise bean must not attempt to query a class to obtain information about the declared
members that are not otherwise accessible to the enterprise bean because of the security rules
of the Java language. The enterprise bean must not attempt to use the Reflection API to access
information that the security rules of the Java programming language make unavailable.
Allowing the enterprise bean to access information about other classes and to access the classes in a
manner that is normally disallowed by the Java programming language could compromise security.
Runtime Environment Enterprise JavaBeans 3.0, Final Release Bean Provider’s Responsibilities
5/2/06 546
Sun Microsystems, Inc.

• The enterprise bean must not attempt to create a class loader; obtain the current class loader;
set the context class loader; set security manager; create a new security manager; stop the
JVM; or change the input, output, and error streams.
These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions
could compromise security and decrease the container’s ability to properly manage the runtime environment.

• The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or
the stream handler factory used by URL.
These networking functions are reserved for the EJB container. Allowing the enterprise bean to use
these functions could compromise security and decrease the container’s ability to properly manage the
runtime environment.

• The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise
bean must not attempt to manage thread groups.
These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads
would decrease the container’s ability to properly manage the runtime environment.

• The enterprise bean must not attempt to directly read or write a file descriptor.
Allowing the enterprise bean to read and write file descriptors directly could compromise security.

• The enterprise bean must not attempt to obtain the security policy information for a particular
code source.
Allowing the enterprise bean to access the security policy information would create a security hole.

• The enterprise bean must not attempt to load a native library.
This function is reserved for the EJB container. Allowing the enterprise bean to load native code would
create a security hole.

• The enterprise bean must not attempt to gain access to packages and classes that the usual rules
of the Java programming language make unavailable to the enterprise bean.
This function is reserved for the EJB container. Allowing the enterprise bean to perform this function
would create a security hole.

• The enterprise bean must not attempt to define a class in a package.
This function is reserved for the EJB container. Allowing the enterprise bean to perform this function
would create a security hole.

• The enterprise bean must not attempt to access or modify the security configuration objects
(Policy, Security, Provider, Signer, and Identity).
Container Provider’s Responsibility Enterprise JavaBeans 3.0, Final Release Runtime Environment
547 May 2, 2006 2:35 pm
Sun Microsystems, Inc.
These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions
could compromise security.

• The enterprise bean must not attempt to use the subclass and object substitution features of the
Java Serialization Protocol.
Allowing the enterprise bean to use these functions could compromise security.

• The enterprise bean must not attempt to pass this as an argument or method result. The
enterprise bean must pass the result of SessionContext.getBusinessObject, SessionContext.
getEJBObject, SessionContext.getEJBLocalObject, EntityContext.
getEJBObject, or EntityContext.getEJBLocalObject instead.
To guarantee portability of the enterprise bean’s implementation across all compliant EJB 3.0 containers,
the Bean Provider should test the enterprise bean using a container with the security settings defined
in Table 24. The tables define the minimal functionality that a compliant EJB container must provide to
the enterprise bean instances at runtime.

"Schlimm" ist relativ, in manchen Containern funktoniert das trotzdem (zumindest bis zu einem bestimmten Grad), aber der Standard sagt es ist "schlimm".

 

[sliwalker]

Hoi,

danke für Deine Mühe!
Hat mir sehr geholfen. (Hätt ich aber wohl auch selbst finden können ) Deshalb doppeltes Danke.

greetz
SLi