Schnittstellen

[Lude]

Hi,

seit fuenf Jahren habe ich in mehr oder weniger regelmaessigen Abstaenden die Gelegenheit gehabt Schnittstellen (Dateien)bereitzustellen. Von der Cobol-Datei (das war vermutlich nicht mal das Bekloppteste) mit festen Laengen der Datenfeldern, 'CSV'-Dateien, 'INI'-Dateien, 'TXT'-Dateien und XML-Dokumenten war alles dabei. - Zwingend erscheint mir heute der Einsatz von XML; alles andere ist suboptimal. Was sagen die hochschulgehaerteten Forumsteilnehmer dazu? (Eingeladen zur Stellungnahme sind natuerlich und naturgemaess alle.)

Gruss,
Lude

[sschumann]

Schnittstellen

*glaubt an das XML-EDI* wie sagte doch mal ein gewisser Herr Mintert zu mir: "Ich denke, Performance-Probleme müssen auf der Hardwareseite erschlagen werden". Na dann.

[Lude]

Hi,

*glaubt an das XML-EDI* wie sagte doch mal ein gewisser Herr Mintert zu mir: "Ich denke, Performance-Probleme müssen auf der Hardwareseite erschlagen werden". Na dann.

danke fuer die Erwaehnung von 'XML/EDI'. Dennoch wuenscht sich der Threaderoeffnende etwas substanziellere Statements.

Gruss,
Lude

[Erwin]

Hi,

seit fuenf Jahren habe ich in mehr oder weniger regelmaessigen Abstaenden die Gelegenheit gehabt Schnittstellen (Dateien)bereitzustellen. Von der Cobol-Datei (das war vermutlich nicht mal das Bekloppteste) mit festen Laengen der Datenfeldern, 'CSV'-Dateien, 'INI'-Dateien, 'TXT'-Dateien und XML-Dokumenten war alles dabei. - Zwingend erscheint mir heute der Einsatz von XML; alles andere ist suboptimal. Was sagen die hochschulgehaerteten Forumsteilnehmer dazu? (Eingeladen zur Stellungnahme sind natuerlich und naturgemaess alle.)

XML ist nicht zwingend.

Bei mir sieht jede META Datei anders aus. Je nach Lust und Laune ;-)

Gruss, Erwin

[Tim Tepaße]

Hallo Lude,

Zwingend erscheint mir heute der Einsatz von XML; alles andere ist
suboptimal.

Wieso erscheint Dir das zwingend? Ist das nicht immer anhand der
Datenstruktur zu entscheiden? Beispiel: Unter Unix ist Plaintext
als Format für Dateien und zum minimalen Programmoutput immer noch
sehr erfolgreich. Mit Recht. Schließlich ist es menschenlesbar und
kann dennoch weiter von Programmen verarbeitet werden. Man stelle
sich vor, der Output von 'ls' käme plötzlich in XML.

Tim

[Lude]

Hi,

Zwingend erscheint mir heute der Einsatz von XML; alles andere ist suboptimal.
[...] Man stelle sich vor, der Output von 'ls' käme plötzlich in XML.

ich meinte Schnittstellen zwischen mindestens zwei Systemen mit eigenen Datenhaltungen. (Haette ich mich in der Tat deutlicher ausdruecken sollen.)

Gruss,
Lude

[Tim Tepaße]

Hallo Lude,

ich meinte Schnittstellen zwischen mindestens zwei Systemen mit eigenen
Datenhaltungen. (Haette ich mich in der Tat deutlicher ausdruecken sollen.)

Da gewinnt XML meist natürlich.

Tim

[Danny]

Hallo Lude,

im öffentlichen Dienst sind feste Satzlängen oder CSV-Daten auch heute noch üblich und bei Neuprojekten gefordert. Das wird sich auch so schnell nicht ändern...

Noch immer sind einige Cobol-Programme im Einsatz und auch in jeder anderen Sprache ist es weniger aufwendig, flache, einfache Textdaten separiert durch Zeilenwechsel oder andere Delimiter zu verarbeiten als Daten im XML-Format.

Bei XML gestaltet sich das Parsen technisch aufwendiger, die Verarbeitung komplexer und bei tausenden oder gar millionen Datensätzen sehr viel langsamer als auf die altmodische Art und Weise. Ich denke da speziell an Rechenzentren, die z.B. Änderungen von Rentendaten oder Kontobewegungen verarbeiten...

Sollen Daten für diverse Medien, bzw. Formate aufbereitet werden, z.B. PDF oder Web oder werden Daten mit komplexer, baumartiger Struktur ausgetauscht, ist XML ideal.

Gruß
Danny

[Lude]

Hi,

Sollen Daten für diverse Medien, bzw. Formate aufbereitet werden, z.B. PDF oder Web oder werden Daten mit komplexer, baumartiger Struktur ausgetauscht, ist XML ideal.

irgendwie sind alle Daten komplexer Struktur (zumindest die, die bei mir auf dem Schreibtisch landen). BTW - ich beschaeftige mich gerade mit der Java-Schnittstelle der 'Creditreform' und die Art und Weise wie die eine "Dokumentstruktur" in COBOL abbilden. Das sind schon echte Koenner bei der 'Crefo'.   :-)

Gruss,
Lude

[Klaus Mock]

Hallo,

XML klingt auf dem ersten Blick sicherlich ideal, da sehr flexibel. Allerdings hat man nicht immer (eigentlich eher selten) die Möglichkeit, es sich auszusuchen, in welchem Format man die Daten bereitstellt oder muß aus anderen Gründen eine Alternative suchen.

• Zum einen kann es durchaus sein, dass man auf eines der betroffenen Systeme nicht Einfluss in vollem Umfang nehmen kann.

• Zum anderen können technische Gründe gegen XML sprechen (keine XML-Parser-Bibliotheken im Zielsystem usw.).

• Ausserdem könnte die Situation bessere Alternativen anbieten (Beispiel: Database-Links in Oracle mit Austausch-Tabellen oder Views).

• Die Performance bei Massendatenverarbeitung wurde (denke ich) hier sicher schon angesprochen.

[Liste beliebig fortsetzen..]

Ich hoffe, dass jetzt ein bisschen rübergekommen ist, dass XML heute ganz und gar nicht 'zwingend' ist;-)

Grüße
  Klaus

[Lude]

Hi,

XML klingt auf dem ersten Blick sicherlich ideal, da sehr flexibel.

danke fuer Deine Meldung - Du weisst ja, dass der "erste Blick" fuer mich immer zaehlt.   ;-)

Allerdings hat man nicht immer (eigentlich eher selten) die Möglichkeit, es sich auszusuchen, in welchem Format man die Daten bereitstellt oder muß aus anderen Gründen eine Alternative suchen.

Wenn es um Schnittstellen geht, und ich diese bereitstellen darf, dann hat man ja soz. ein Zwischenstueck zwischen mindestens zwei Systemen und dieses Zwischenstueck darf ja (wenn keine Performance-Ueberlegungen (der Laufzeit oder der umsetzung z.B.) dagegensprechen) soz. unabhaengig von den umgebenden Systemen formuliert werden (OK, das Netzwerkprotokoll (und die Netzwerkumgebung) muss allgemein (beruecksichtigt) gekonnt werden).

• Zum einen kann es durchaus sein, dass man auf eines der betroffenen Systeme nicht Einfluss in vollem Umfang nehmen kann.

Die "Leistungsstaerke" des genannten Systems ist zu beruecksichtigen, aber "Einfluss" auf das genannte System wird m.E. ohnehin nicht benoetigt?!

• Zum anderen können technische Gründe gegen XML sprechen (keine XML-Parser-Bibliotheken im Zielsystem usw.).

Das inspiriert mich zu der Frage, ob es fuer Perl 'W3C Schema'-validierende Parser gibt. Gibt's die?

• Ausserdem könnte die Situation bessere Alternativen anbieten (Beispiel: Database-Links in Oracle mit Austausch-Tabellen oder Views).

Oeff. - Ich kenne nur den 'M$ SQL Server', aber Schnittstellen mit sog. Database-Links zu realisieren?! Also, wenn ich recht verstanden habe, die Schnittstelle nicht als eigenes Objekt sondern als Teilobjekt des Datenzugriffs zu implementieren?

• Die Performance bei Massendatenverarbeitung wurde (denke ich) hier sicher schon angesprochen.

Nach meiner Erfahrung ist es in _meinem_ Bereich (der Finanzdienstleistung) von untergeordnetem Interesse, dass die Sache performant ist. (Wichtiger schon, dass z.B. die COBOL-Fraktion i.p. Datenstruktur und Datenzugriff nicht alles kaputt macht ;-).

[Liste beliebig fortsetzen..]

Ich bin gespannt.

Ich hoffe, dass jetzt ein bisschen rübergekommen ist, dass XML heute ganz und gar nicht 'zwingend' ist;-)

Ja, das mit dem 'zwingend' war schon provokativ. Es war schon eine emotionale (also eine hochwertige ;-) Aussage.

Gruss,
Lude

[Klaus Mock]

Hallo,

Wenn es um Schnittstellen geht, und ich diese bereitstellen darf, dann hat man ja soz. ein Zwischenstueck zwischen mindestens zwei Systemen und dieses Zwischenstueck darf ja [...] soz. unabhaengig von den umgebenden Systemen formuliert werden [...] .

Ich weiß ja nicht wie Du 'Schnittstelle' definierst, ich für meinen Teil sehe da schon eine Bindung zwischen den einzelnen Systemen und der Schnittstelle. Irgendwie muß diese ja von allen verbundenen Systemen angesprochen werden (lesend, schreibend oder beides).

Die "Leistungsstaerke" des genannten Systems ist zu beruecksichtigen, aber "Einfluss" auf das genannte System wird m.E. ohnehin nicht benoetigt?!

Das verstehe ich nicht. Vielleicht reden wir aber auch von zwei unterschiedlichen Dingen. Kannst Du Deine Vorstellungen etwas näher erläutern?

Das inspiriert mich zu der Frage, ob es fuer Perl 'W3C Schema'-validierende Parser gibt. Gibt's die?

http://search.cpan.org/~abw/XML-Schema-0.07/lib/XML/Schema.pm. Das war aber eine leichte Übung;-)

Also, wenn ich recht verstanden habe, die Schnittstelle nicht als eigenes Objekt sondern als Teilobjekt des Datenzugriffs zu implementieren?

Naja, wenn ich schon auf beiden Seiten eine (gleiche) Datenbank habe, bietet es sich doch an, die Datenbankschicht gleich gar nicht zu verlassen.

Nach meiner Erfahrung ist es in _meinem_ Bereich (der Finanzdienstleistung) von untergeordnetem Interesse, dass die Sache performant ist.

Und ich dachte bisher, wir reden allgemein über Schnittstellen;-) Und 'allgemein' kann Performance ein Thema sien, oder?

(Wichtiger schon, dass z.B. die COBOL-Fraktion i.p. Datenstruktur und Datenzugriff nicht alles kaputt macht ;-).

_Das_ kenne ich *gg*. Nichts gegen COBOL-Programmierer, allerdings fällt mir spontan auch nichts positives ein.

Grüße
  Klaus

[Lude]

Hi,

Ich weiß ja nicht wie Du 'Schnittstelle' definierst, ich für meinen Teil sehe da schon eine Bindung zwischen den einzelnen Systemen und der Schnittstelle.

es gibt mindestens zwei Systeme und wenn die kommunizieren, dann gibt es eine Schnittstelle (Ein Zwischenstueck, ein Daten-Adapter, soz. ein Vertrag zwischen den Systemen), die entweder als Objekt definiert wird (das Thread-Thema soz.) oder im Datenzugriff beinhaltet ist. Ich stelle mir das ganz doof so vor, wie zwei Elektrizitaets-Steckdosen anderer Norm, die miteinander verbunden werden. Das kann man mit einem Kabel und zwei verschiedenen Steckern machen oder man setzt auf eine der beiden Dosen einen Adapter, der die Angleichung an die jeweils andere Norm bildet. (Vielleicht hinkt der Vergleich ein wenig, aber ich nutze ihn bisher.)

Das verstehe ich nicht. Vielleicht reden wir aber auch von zwei unterschiedlichen Dingen. Kannst Du Deine Vorstellungen etwas näher erläutern?

Ich hatte Dich so verstanden, dass man die Schnittstelle nicht soz. unabhaengig von Allem sehen kann, sondern dass man zumindest manchmal "Einfluss" auf mindestens ein System benoetigt. Dazu meinte ich, dass man manchmal die Leistungsmerkmale der Systeme beruecksichtigen muss, aber "Einfluss" auf mindestens ein System nicht benoetigt. Aber Du kannst mich mit einem Beispiel widerlegen.

Das inspiriert mich zu der Frage, ob es fuer Perl 'W3C Schema'-validierende Parser gibt. Gibt's die?
http://search.cpan.org/~abw/XML-Schema-0.07/lib/XML/Schema.pm. Das war aber eine leichte Übung;-)

'The XML::Schema module set implements the necessary functionality to construct, represent and utilise XML Schemata' - Ich bin mal auf das Modul gestossen, aber habe es nicht weiter geprueft, denn ich benoetige einen Parser und 'expat' leistet nach meiner Kenntnis nicht die o.g. Validierung.

Also, wenn ich recht verstanden habe, die Schnittstelle nicht als eigenes Objekt sondern als Teilobjekt des Datenzugriffs zu implementieren?
Naja, wenn ich schon auf beiden Seiten eine (gleiche) Datenbank habe, bietet es sich doch an, die Datenbankschicht gleich gar nicht zu verlassen.

Wir beide koennten das machen.   ;-)
Aber wenn die Schnittstelle (die es ja immer gibt, sei es im Code irgendwo) aus dem Bewusstsein der Entwickler verschwindet und die bauen dann unnoetige Abhaengigkeiten an, dann kommen nicht selten schlecht skalierbare, kaum weiterentwicklungsfaehige und schwierig zu wartende Systeme heraus.

Und ich dachte bisher, wir reden allgemein über Schnittstellen;-) Und 'allgemein' kann Performance ein Thema sien, oder?

Klar.   :-)

_Das_ kenne ich *gg*. Nichts gegen COBOL-Programmierer, allerdings fällt mir spontan auch nichts positives ein.

:-)

Gruss,
Luddie