Blogg'nWickler

Netbeans 6.5 (mit PHP Plugin) ist IMHO die derzeit beste Entwicklungsumgebung für PHP. In einem Vergleich zwischen Netbeans 6.5 und Eclipse PDT auf Webseite des PHP Magazins geht Netbeans als Sieger hervor.

Dass PHP nicht nur irgendsoein Plugin für Netbeans ist, sondern ernsthaft als Entwicklungs-Sprache angesehen wird, merkt man nicht zuletzt daran, dass Netbeans PHP einen eigenen PHP Learning Trail widmet.

Und weil Netbeans sehr innovativ ist und viele Informationen auch über Screencasts zur Verfügungstellt, gibt es auch zur PHP Entwicklung auf Netbeans Einführungs-Videos:

Demo of PHP support in NetBeans 6.5


Demo of PHP support in NetBeans 6.5 - Part II: Editor Features

Class Property Variables in NetBeans IDE 6.5 for PHP


Zudem gibt es einen eigenen Weblog zu PHP mit Netbeans

In seinem Vortrag "How to hack and secure your Java web application" stellt Sebastien Deleersnyder Angriffsszenarien auf Webseiten vor. Sebastien Deleersnyder ist Mitglied der belgischen OWASP Gruppe. OWASP steht für Open Web Application Security Project, dabei handelt es sich um eine unabhängige Organisation, die mit der Veröffentlichung von freien Artikeln und Tools zur Sicherheit von Webanwendungen beitragen möchte. Das Video hat eine Länge von ca. 50 Minuten.

Zwei Forscher der Uni Bonn haben einen Netzwerk-Scanner entickelt, über den man nach dem Conficker Wurm suchen kann. Dabei ruft der Scanner die Windows-Funktion NetpwPathCanonicalize() auf, die von Conficker manipuliert wird. Dazu muss allerdings der Port 445 geöffnet sein.

Ab dem 1. April lädt Conficker Updates aus dem Internet nach, die zu nicht vorhersehbaren Verhalten von Computersystemen führen können.

Wer sein Netzwerk auf infizierte Systeme scannen möchte, kann hier den Scanner runterladen. Bei dem Tool handelt es sich um ein Python-Programm. Es gibt aber auch eine compilierte Windows-Exe.

Nach dem Entpacken kann man in der Dos-Console den Scanner mit

scs <Start-IP-Adresse> <End-IP-Adresse>

aufrufen, um ein komplettes Netzwerk zu scannen. Möchte man nur einen einzelnen Rechner scannen, kann
man den Befehl

scanner <host>

ausführen.

In dem JAR-Entpacker unpack200 wurde eine Buffer-Overflow Lücke entdeckt, die es erlaubt beliebigen Code im Kontext des Benutzers auszuführen zu lassen. Dazu reicht schon der Aufruf einer entsprechend manipulierten Webseite aus.

Das unpack200 Tool ist ab JDK-Version 1.5 verfügbar und ermöglicht das entpacken von Java Archiven. Die älteren Versionen 1.4.2 und 1.3.1 von JDK/JRE sind laut Sun nicht betroffen.

Wer testen möchte, ob seine Java-Installation betroffen ist, kann folgenden Link anklicken und ggf. auf die passende, gefixte Version updaten.

Verifying Java Version

Auf der Webseite von MySQL findet man eine neue Alpha-Verson 6.0.9 von MySQL 6.0. Sie enthält die zwei neue Storage-Enginges - die transaktionale Falcon Engine und die ausfallsichere Maria-Engine. Hier findet man einige Informationen zu den Änderungen in MySQL.

Für den produktiven Einsatz wurde der MySQL Community Server 5.1.32 veröffentlicht. Beschreibung der Neuerungen im Handbuch.

MySQL hat auf ihrer Website einen Anwenderbericht der Uni Duisburg-Essen veröffentlicht. Darin geht es um eine hochverfügbare eLearning Lösung auf Basis von MySQL.

Für .Net Entwickler gibt es ein neues Release des .Net Connectors in der Version 6.0 Alpha.

Internet = Google, Google = Internet. Diese Gleichung gilt schon seit Jahren. Das Internet als universaler Wissenspeicher wird fast immer über die Suchmaschine mit den bunten Buchstaben angezapft. Einfach Stichwort eingeben und meist hat man dann auch relevante Treffer. Ich persönlich gehe sogar oft so vor, dass meine Anfragen als Satz ausformuliere, in der Hoffnung, dass genügend relevante Suchbegriffe enthalten sind, die zu den gewünschten Ergebnissen führen.

Google enttäuscht die Hoffnung zumeist nicht und gibt einem die Illusion, ein intelligenter, dienstbarer Geist hätte die Suchanfrage bedient. Natürlich stecken jede menge intelligente Suchalgorithmen hinter der Technik, die von cleveren Programmierern und Mathematikern bei Google entwickelt wurden...dabei handelt es sich nicht um ein KI-System im Sinne einer schwachen oder gar starken KI. Zumindest noch nicht. In einem Vortrag von 2007 bekräftigte Larry Page das Bestreben von Google, eine Suchmaschine mit Künstlicher Intelligenz zu bauen. Jetzt könnte der Suchmaschinengigant auf diesem Gebiet allerdings ernsthafte Konkurrenz bekommen.

Der britische Wissenschaftler Stephen Wolfram (Erfinder von Mathematica) plant eine neue Super-Suchmaschine namens Wolfram Alpha (eine eher nüchterne 50er-Jahre-style Namensgebung im vergleich zu Google & Co.), die im Mai 2009 online gehen soll. Diese Suchmaschine bezeichnet Wolfram selbst als computational Knowledge Engine. Eine Maschine, die alle Fragen beantworten kann, die man ihr stellt und zwar in natürlicher Sprache. Ich vermute mal, mit natürlicher Sprache meinen die Entwickler erstmal Englisch, aber was ist mit Bayerisch

Die Antworten werden berechnet. Dabei wird die natürliche Sprache in Rechenaufgaben übersetzt, die anhand von Algorithmen und einer riesigen Datenbasis die Ergebnisse liefert. Bei den Daten selbst handelt es sich um sog. kurartierte Daten, die von den Mitarbeitern Wolframs
ausgewählt wurden.

Solche Ansätze mit manuell gefilterten Daten gab es früher schon bei den Webkatalogen wie Yahoo oder Web.de. Jedoch fehlte es hier zum einen an den ausgefeilten Suchmechanismen und zum anderen an genügend Daten. Schließlich muss für jedes Faktum von einem Menschen (quasi eine natürliche Intelligenz) die Bewertung vorgenommen werden, was aufwändig und kostenintensiv ist. Die Frage ist, wie Wolfram dieses Problem lösen will. Angeblich arbeitet ein Team von ca. 100 Mitarbeitern an diesem Projekt. Aber selbst 1.000 oder 10.000 Mitarbeiter dürften nicht reichen, um den Anspruch zu erfüllen, alle Fakten der Welt zusammenzutragen und zentral zu speichern.

Vielleicht kommt hier Nova Spivack ins Spiel. Er ist Unternehmer und Spezialist für das semantische Web. Sein Lösungsansatz basiert auf dem social Web. Spivack dürfte als bisher einer der Wenigen Wolfram Alpha testen und schreibt darüber auch in seinem Blog. Ein "wikipedisiertes" Wolfram Alpha, bei dem die Inhalte von unzähligen User eingepflegt werden, könnte die Lösung sein um einen riesigen Wissenspeicher intelligent zu verstöpseln.

Wie schreibt Spivack in seinem Blog: "Wolfram Alpha is like plugging into a vast electronic brain". Klingt fast nach Skynet von Cyberdyne Systems. Die Frage ist nur, welche Antwort gibt die neue Super-Suchmaschine auf die Frage nach dem Sinn des Lebens und des Universums? Vermutlich 42


Weitere Links:
Blog von Stephen Wolfram

Software-Genie verspricht den Google-Killer (Spiegel Online)

Wikipedia Artikel zu KI

In diesem Artikel möchte ich euch zeigen, wie man gezielt eine RFC-Funktion bzw. genauer gesagt ein BAPI über PHP aufruft und das Ergebnis verarbeitet.

In meinem letzten Artikel bin ich bereits darauf eingegangen, wie man grundsätzlich ein PHP-Script mit einem SAP-Server verbinden kann. Dabei habe ich als SAP-Server das Test-System von SAP verwendet. Wobei ich mit dem Begriff Test-System vorsichtig sein muss, weil damit in einer typischen SAP Drei-System-Landschaft meist auch das Qualitätssicherungs-System gemeint ist. Also ihr braucht dagegen so eine kostenlose 90-Tage Ausprobier-Version, entweder Mini-SAP oder Mini-WAS, die ihr z. B. im SAP Developer Network downloaden könnt.

Wenn man ein Datenbank-Anwendung kennenlernen will, benötigt man Testdaten. Was die Nordwind-Datenbank bei MS Access ist, ist die Flugdatenbank bei SAP Mini-WAS. Unter diesem Link findet man übrigens eine Übersicht über die Tabellen der Flugdatenbank.

Als Ziel setzen wir uns, die Kundendaten aus Tabelle SCUSTOM auszulesen. Dabei können wir mit PHP natürlich nicht direkt auf die Datenbanktabelle zugreifen. Stattdessen benötigen wir einen ABAP-Funktionsbaustein, den wir über RFC aufrufen und der uns die Ergebnisse zurück liefern soll. So einen FuBa könnten wir natürlich selber in ABAP programmieren. Das Problem ist, eigene Programme liegen im sog. Z-Namensraum und weichen vom SAP-Standard ab. Besser ist es, wenn man Standard-Funktionen von SAP aufrufen kann. Außerdem, warum das Rad neu erfinden? Wir haben Glück. Für die Ausgabe einer Kundenliste existiert die BAPI-Funktion BAPI_FLCUST_GETLIST.

BAPI steht für Business Application Programming Interfaces. BAPIs gehören zum SAP Business Frameworks und stellen eine Kommunikations-Schnittstelle nach außen dar. Während klassische Funktionsbausteine explizit als Remote-Baustein deklariert werden müssen, damit sie von extern aufgerufen werden können, sind BAPIs automatisch Remote-fähig.

Nun zu unserem Script. Damit wir auf den SAP-Server zugreifen können, brauchen wir wieder die Verbindungs- und Logindaten. Für eine leichtere Wiederverwendung habe ich diese Daten in ein externes Script conf/sap_connection.conf.php ausgelagert:

//

// Verbindungsdaten zum SAP-Server

//

$sapServer = array();

// NSP

$sapServer["NSP"] = array(  'USER'      => 'bcuser',            // SAP User

                            'PASSWD'    => 'minisap',           // SAP User Passwort

                            'NSP'       => 'NSP',               // SAP SID

                            'ASHOST'    => '127.0.0.1',         // SAP Application Server

                            'SYSNR'     => '00',                // System Nummer

                            'CLIENT'    => '000'                // Mandant

);

?>

Im Haupt-Script wird diese Datei mit

include("conf/sap_connection.conf.php");

eingebunden.

Danach führen wir einige Vorbelegungen durch:

define("RFC_FUNCTION_NAME", "BAPI_FLCUST_GETLIST");

$rfcReturnTable = "CUSTOMER_LIST";

$rfcCon = null;

$rfcResult = array();

Zunächst mal geben wir die gewünschte BAPI-Funktion BAPI_FLCUST_GETLIST an. Diese BAPI gibt ihr Ergebnis u.a. in die Tabelle CUSTOMER_LIST zurück. Danach verbinden wir uns mit dem SAP-Server.

$rfcCon = saprfc_open($sapServer["NSP"]);       // Verbindungsdaten als Array

if( !$rfcCon )      // Verbindung fehlgeschlagen

{

    die( "RFC Verbindung fehlgeschlagen: " . saprfc_error() );

}

Die Variable $rfcCon erhält das Connection-Handle und muss in den folgenden Funktionen mit angegeben werden. Als nächstes registrieren wir die RFC-Funktion (also unser BAPI), die Rückgabe-Tabelle und den Import-Parameter. Wobei der Import-Parameter als Übergabe-Parameter an die RFC-Funktion zu verstehen ist.

$rfcFunction = saprfc_function_discover( $rfcCon, RFC_FUNCTION_NAME );

if( !$rfcFunction )

{

    die( "RFC Funktion konnte nicht ermittelt werden" );

}

@saprfc_table_init( $rfcCon, $rfcReturnTable );

saprfc_import( $rfcFunction, "MAX_ROWS", 20 );

Es gibt zwei Möglichkeiten, die Signatur einer RFC-Funktion festzulegen. Entweder man definiert die Signatur einer RFC-Funktion direkt über saprfc_function_define() oder man ermittelt die Signatur über saprfc_function_discover() automatisch. Die erste Variante ist aufwändiger dafür schneller, die zweite Variante bequemer, dafür aber etwas weniger performant. Wie man sieht, mag ichs bequem

Ist alles korrekt festgelegt, können wir den RFC-Aufruf ausführen:

$rfcStatus = saprfc_call_and_receive( $rfcFunction );

if( $rfcStatus != SAPRC_OK )

{

    if( $rfcStatus == SAP_EXCEPTION )

    {

        die( "RFC Exception: " . saprfc_exception( $rfcFunction ) );

    }

    else

    {

        die( "Fehler RFC-Aufruf: " . saprfc_error( $rfcFunction ) );

    }

}

Hat alles geklappt, können wir die Ergebnismenge zeilenweise auslesen. Dazu ermitteln wir mit saprfc_table_rows() die Anzahl der Reihen in der Ergebnistabelle und verarbeiten dann die Tabelle über eine for-Schleife. Die einzelnen Zeilen lesen wir mit saprfc_table_read() aus und speichern diese in einem Array.

$rows = saprfc_table_rows($rfcFunction, $rfcReturnTable);

for( $i = 1; $i <= $rows; $i++ )

{

    $rfcResult[$i] = saprfc_table_read( $rfcFunction, $rfcReturnTable, $i );

}

Ab jetzt können wir die Daten mit PHP so verarbeiten wie gewünscht. Z. B. könnten wir die Daten in einer Tabelle ausgeben:

<table border="0" cellpadding="3" cellspacing="0">

<tr>

    <th>Kunden-ID</th>

    <th>Kunden-Name</th>

    <th>Straße</th>

    <th>PLZ</th>

    <th>Ort</th>

    <th>Telefon</th>

    <th>eMail</th>

</tr>

<?php

foreach( $rfcResult as $record )

{

    echo "<tr>";

    echo "<td>" . $record["CUSTOMERID"] . "</td>";

    echo "<td>" . $record["CUSTNAME"] . "</td>";

    echo "<td>" . $record["STREET"] . "</td>";

    echo "<td>" . $record["POSTCODE"] . "</td>";

    echo "<td>" . $record["CITY"] . "</td>";

    echo "<td>" . $record["PHONE"] . "</td>";

    echo "<td>" . $record["EMAIL"] . "</td>";

    echo "</tr>";

}

?>

</table>

Das Ergebnis sollte dann im Browser in etwa so aussehen (Ok, ich hab hier etwas das SAP-GUI nachgebaut ):




In der Erweiterten Ansicht dieses Artikels ist der komplette Code nochmal dargestellt.


Links:

Allgemeine Einführung in die BAPIs (CA-BFA)

BAPI List

Absicherung der SAP RFC-Schnittstelle (BSI)

Ich habe noch einen weiteren guten Artikel gefunden, der die unterschiedlichen Möglichkeiten beleuchtet, wie man PHP und Java miteinander verheiratet.

Integration von PHP mit der Java Enterprise Edition, ein Artikel von Markus Eisele auf entwickler.de vom Oktober 2007.

Der TIOBE Programming Community Index ermittelt die populärsten Programmiersprachen anhand der Anzahl der Programmierer, Kurse oder Anbieter von Lösungen. Zusätzlich werden zur Berechnung der Popularität die Suchtreffer (Suchstring: " programming") der Suchmaschinen Google, MSN, Yahoo! und Youtube herangezogen.

Nach dem TIOBE Index vom Februar 2009 rangiert Java mit 19,4% an erster Stelle, gefolgt von C (15,8%) und C++ (9,6%). Das '"Stockerl" knapp verpasst haben Visual Basic mit 8,8% auf Platz 4 und PHP mit 8,7% auf Platz 5. Der TIOBE Index gibt auch die Differenz zum Vorjahreszeitraum an. So lässt sich eine Entwicklung über die letzten 12 Monate ablesen. Demnach haben sich die C-basierten Compiler-Sprachen wie C#, C++ oder Java verbessert oder sind etwa gleich geblieben.

Ich habe hier noch einen Ausdruck vom Stand September vor mir liegen, also ein knappes halbes Jahr alt. Interessant ist hier die Entwicklung von C#. Microsofts .Net Kernsprache hat sich von Platz 8 auf Platz 6 vorgeschoben. Auch bemerkenswert, Logo landet auf Platz 15 und zeigt einen starken Trend nach oben?!? Wer bitteschön programmiert denn in Logo?

Ebenfalls interessant ist die Entwicklung von ABAP. Vor Jahresfrist noch auf Platz 29, im September 2008 auf Platz 24 und im Februar 2009 schon auf Platz 17. Hat SAP nicht vor kurzem einen Einstellungsstop verhängt? Und überhaupt, propagiert SAP nicht ihren neuen SOA-Ansatz über Java. Anscheinend suchen immer noch viele Berater- und Anwender-Firmen R/3 Experten für den klassischen ABAP-Stack.

Der Markt für ERP-Experten ist aber wohl so leer wie die Atacama-Wüste trocken. Daher findet man an jeder (Web)-Ecke Jobangebote für SAPler oder solche, die es noch werden wollen. Dieses erhöhte Hintergrundrauschen im Web wirkt sich natürlich auch auf so einen Index wie TIOBE aus.

Zu PHP muss man sagen, dass sie sich als reine Webprogrammiersprache wacker auf Platz 5 hält. Schließlich bieten die anderen Programmiersprachen drumherum ein breiteres Einsatzspektrum. Daher vermute ich, dass allein bezogen auf den Bereich webbasierte Softwareentwicklung PHP die Nase vorn hätte. Aber hierzu ist mir leider noch keine stichhaltige Statistik untergekommen.

Mit PHP auf SAP zugreifen? Viele werden sich vielleicht fragen, wat?!? Warum dass denn? Schließlich hat SAP doch seine eigene Programmiersprache - nämlich ABAP. Der Allgemeine Berichts-Anwendungs-Prozessor, äh sorry, natürlich heißt's ja seit langem schon Advanced Business Application Programming. SAP ändert ja gerne mal die Namen ihrer Produkte.

Das derzeit wichtigste Produkt, der Netweaver, bietet eine enge Integration von Java über den hauseigenen J2EE-Server und dem Java Connector JCO. Außerdem existieren in SAP seit jeher Schnittstellen nach außen - klassische wie die RFCs oder moderne über HTTP/Webservices - SOA lässt grüßen. Ahh jetzt! Der Zugriff von PHP auf SAP läuft also über SOAP oder so ähnlich. Falsch gedacht! Obwohl dies natürlich auch ginge. Die Unterstützung von SOAP ist in PHP5 sehr ausgereift.

Nein. Der Zugriff erfolgt über die RFC-Schnittstelle. Möglich wird das durch die SAPRFC Extension, die 2001 von Eduard Koucky entwickelt wurde. Diese Extension wird allerdings seit 2005 nicht mehr weiterentwickelt. Es gibt aber mit SAPNWRFC, eine interessante Neuentwicklung von Piers Harding.

Ein guter Artikel, wie man SAP mit PHP connected ist "Integrating SAP with PHP" von Jason Simmons. Nach diesem Artikel bin ich auch vorgegangen.

Zunächst mal, ich hatte fürs rumspielen mit ABAP bereits eine 90-Tage Testversion von Netweaver 7.1 installiert. Diese kann man sich von sdn.sap.com runterladen. Mit dem SAP-GUI Client wird auch die notwendige librfc.dll installiert. Als PHP Umgebung verwendete ich XAMPP unter Windows. Für Windows gibt es eine DLL von SAPRFC. Diese php_saprfc.dll habe ich ins Extension-Verzeichnis von PHP kopiert und in der php.ini mit dem Eintrag

extension=php_saprfc.dll

die Extension aktiviert. Dies sollte dann über phpinfo() erkennbar sein.

Danach habe ich das mitgelieferte Script saprfc_test.php ausgeführt. Es erschien dann ein Formular, über das ich dann die Verbindungsdaten zum Mini-SAP System eingegeben habe:

Application Server: 127.0.0.1
System Number: 00
User: BCUSER
Passwort: minisap
System Name: NSP
Client: 000

Der Test war erfolgreich.

Es wurde also Zeit für ein erstes Script.

// Verbindungsdaten

$sapConnectionData = array( 'USER'      => 'bcuser',

                            'PASSWD'    => 'minisap',

                            'NSP'       => 'NSP',

                            'ASHOST'    => '127.0.0.1',

                            'SYSNR'     => '00',

                            'CLIENT'    => '000'

);

//

// RFC Verbindung zum Server aufbauen

//

$rfc = saprfc_open($sapConnectionData);

//

// prüfen ob Verbindung steht

//

if( !$rfc )

{

    echo "Fehler Verbindung: ";

    print_r( saprfc_error() );

    die();

}

else

{

    $info = saprfc_attributes($rfc);

    print_r($info);

}

saprfc_close($rfc);

Entscheidend ist die Funktion saprfc_open(), welche die Verbindung zum SAP-Server aufbaut. Als Parameter übergibt man der Funktion die Verbindungsdaten als Assoziatives Array. Der Rest des Scripts ist simpel. Es gibt einfach nur die Verbindungseigenschaften aus, die über saprfc_attributes() ermittelt werden.

"Du hast den ersten Schritt in eine neue Welt getan, Luke".

Das Script hat einwandfrei funktioniert und der Zugriff auf SAP mit PHP war garnicht so schwierig. Stellt sich immer noch die Frage, warum man denn überhaupt PHP für den SAP-Zugriff verwenden sollte. Nunja, mit Scriptsprachen lassen sich schnell und effizient Anwendungen entwickeln. Außerdem sind Scriptsprachen längst reif für den Enterprise-Einsatz, wie Grails, Ruby und nicht zuletzt PHP5 beweisen. Aber dazu mehr in einem anderen Blog-Eintrag.

Weitere Links:

SAP RFC Homepage

Blog-Seite von Piers Harding zur neuen sapnwrfc Extension

Working with PHP and SAP (Artikel von Stoyan Stefanov)


HOWTO: SCRIPTING LANGUAGE SUPPORT FOR SAP SERVICES - PHP (SAP Developer Network - Vasil Bachvarov)

Diese Frage stellte mir neulich ein Bekannter, der übers Internet elektronische Bauteile verkaufen möchte. Webshops. Ein Thema, mit dem ich mich seit Jahren nicht mehr befasst habe. Dabei hatte ich zu Anfangszeiten des WWW selbst mal einen Webshop gebaut - rein in JavaScript. Damals war ich stolz darauf, heute ist mir das Teil fast peinlicher als meine Vokuhila-Frisur aus den Achtzigern ;->

Aber zurück zur Webshop-Frage. Spontan fiel mir osCommerce ein, weil ich das mal im Zusammenhang mit dem CMS Mambo angeschaut habe. Und da war noch so ein XY-Commerce-Ding, achja xtCommerce. Diese Webshops gibts natürlich immer noch und sind OpenSource. Allerdings sind, was man so hört die Templates dieser Shops mühsam zu customizen. Die Frage meines Bekannten war für mich Anlass, meine Lauscherchen auf Google-Frequenz einzustellen um im Internet mal nach den neuesten Trends auf dem Webshop-Markt zu horchen.

Mittlerweile gibt es weitere gute Webshops aus dem OpenSource-Bereich (siehe Linkliste). Hervorzuheben sind hier Magento und Oxid eShop.

Der Oxid eShop war ursprünglich kostenpflichtig, ist aber seit kurzem unter der GPL kostenlos verfügbar. Allerdings hat die Sache einen Haken - für viele Zusatz-Module muss man dann doch Lizenzgebühren bezahlen. Der Shop präsentiert sich mit moderner AJAX-Technik und soll recht gut anpassbar und bedienbar sein. Vor allem das Template-Handling ist im Vergleich zu xtCommerce besser gelöst. Probleme gibt es aber noch mit rel="nofollow" Attributen, die sich negativ auf die Suchmaschinen-Indizierung auswirken. Wenn in absehbarer Zukunft aus der Community kostenlose Module zur Verfügung gestellt werden und das SEO-Problem gelöst wird, könnte Oxid eShop die Lösung für kleinere Webshops sein.

Magento gilt als Marktführer der OpenSource Webshops. Dem Webgeflüster nach ist Magento sehr flexibel und leistungsfähig, allerdings verbraucht es auch viel resourcen. Laut Doku wird ein Dedizierter Server mit ausreichend RAM vorausgesetzt. Außerdem erfordert es eine gewisse Einarbeitungszeit in das Customizing, also Templatedesign usw. Magento zielt damit wohl eher auf Anwender mit größerem Webshop und ausreichend Server-Power ab. Der Kleingewerbetreibende, der nebenher etwas verchecken will, sollte sich wohl eher nach einem anderen Shop umsehen. Wer einen Hoster findet, der seine Server auf Magento und Zend Framework (auf das setzt Magento nämlich auf - Fallstudie dazu) optimiert hat, könnte unter umständen auch mit einer Shared Hosting-Lösung zufrieden sein.

Hier mal eine Liste weiterer OpenSource Webshops:

PHPShop
PhPay
PhPeppershop
FWPShop
zen cart
OSIS Online Shop
Interchange
PrestaShop
PgMarket

Auf der "heise Developer" Webseite ist ein interessanter Überblicksartikel zur Integration von PHP und Java-Anwendungen veröffentlicht worden. Dabei geht es in erster Linie um die Anbindung Java-Backend Anwendungen an eine Webschnittstelle.

Warum sollte man sowas überhaupt machen, wo es doch Servlets und Java Server Pages gibt. Aber sogar Sun hat mittlerweile erkannt, dass Webfrontends mit Java Server Pages eben doch mühsamer zu erstellen sind, als wie mit Scriptsprachen wie PHP. Leider muss man feststellen, dass für die bestehenden Ansätze PHP und Java miteinander zu Verbinden noch viel Verbesserungsbedarf besteht. Weder die PHP Java-Extension auf PHP-Seite, noch die PHP-Servlet SAPI auf Java-Seite sind ausgereift genug für einen produktiven Einsatz. Abhilfe könnte hier vielleicht mal eine PHP Scripting Engine entsprechend der JSR 223 bringen (ab >Java6), die eine offizielle Spezifikation für die Integration von Scriptsprachen in Java darstellt.

Für den produktiven Einsatz bleibt vorerst wohl nur die lose Kopplung von PHP und Java über Webservices. Gerade seit Version 5 bietet PHP ja eine deutlich verbesserte Unterstützung für Webservices- und XML-Verarbeitung an.

Nachdem ich meinen Server neu installiert habe (inkl. Distributionswechsel), habe ich auch gleich meinen Weblog neu aufgesetzt und ihm ein neues Theme verpasst. Somit geht das Bloggen hier bald weiter...