Letzte Woche hat Microsoft mit einem kräftigem Statement aufsehen erregt. Der weltweit führende (und darum recht umstrittene) Software- und Betriebssystemhersteller will von seiner bisherigen Abwehrtaktik gegenüber Open-Source-Technologien abstand nehmen und offener werden!

Man kann jetzt etwas sarkastisch behaupten, MS will nur die Öffentlichkeit vom Versuch Yahoo! zu übernehmen ablenken. Nichts desto trotz ist diese Änderung in der strategischen Unternehmenstaktik schon sehr interessant. Nicht unbedeutend waren sicher die Bemühungen der EU den Softwareriesen mit hohen Strafen zu diesem Schritt zu zwingen.

Etwas was nach meiner (unbedeutenden) Meinung nach jedoch auch ersichtlich wird ist, dass sich Microsoft in Zukunft immer mehr bemühen wird, in der Öffentlichkeit ein positiveres Image zu erzeugen. Klar, man kann sich auf seinem Marktanteil ausruhen und einfach den Übermächtigen raushängen lassen. Ich kann mich aber auch daran erinnern, dass der amerikanische Flug-Gigant Pan Am als unantastbar bezeichnet wurde. Das hielt das Unternehmen aber nicht davon ab pleite zu gehen.

Ob Microsoft es mit den Ankündigungen wirklich ernst meint werden wir in naher Zukunft sehen. Ob sich die Open-Source-Davids auf ein tet-a-tet mit dem Markt-Goliath einlassen werden ist dann aber wieder eine ganz andere Geschichte. 

Ich habe mich schon öfter gefragt, in welchen Kernpunkten sich Microsoft.NET von J2EE unterscheidet.

Nach einigem Research habe ich folgende Unterscheidungsmerkmale gefunden:
2 herausstechende Merkmale, die für .NET sprechen, sind wohl seine Mehrsprachigkeit, die in J2EE nicht vorhanden ist und
die native Unterstützung für XML, SOAP, UDDI und WSDL, die in J2EE in der gegenwärtigen Version leider fehlen.

weitere Untescheidungsmerkmale sind:

● Das .NET Framework kennt mehrere Sprachvarianten, die alle denselben ausführbaren Code erzeugen (C#,VB,J#), unter J2EE gibt es nur JAVA
● J2EE ist plattformunabhängig, .NET prinzipiell auch, jedoch fehlen noch die entsprechende Implementierungen für alle Plattformen
● J2EE ist vollständig standardisiert, .NET (bisher) nur teilweise.
● J2EE trennt klar zwischen Framework und Betriebssystem, .NET nicht.
● In J2EE ist mit den Enterprise Java Beans ein serverseitiges Komponentenmodell implementiert, dem .NET Framework fehlt dieser Ansatz
● Der Applikationserver in J2EE übernimmt Aufgaben die in.NET vom Betriebssystem ausgeführt werden
● Remoting muss in .NET explizit programmiert werden. Es unterscheidet sich von dem Remoting Model der Enterprise Java Beans mit  derm Ansatz der Location Transparency.
● Das Transaktionshandling wird in.NET vom Betriebssystem übernommen, in J2EE vom Application Server

In vielen Bereichen der SW-Entwicklung stösst man über sehr mächtige Open Source Libraries, die in JAVA implementiert sind.
Ein Beispiel ist die mächtige Volltextsuchengine Lucene. (weiter Infos unter Wikipedia)
Um diese Libraries in .NET nutzen zu können wurde eine virtuelle Maschine für JAVA in .NET entwickelt, die es erlaubt, von .NET aus JAVA-Klassen aufzurufen.
Das Tool nennt sich IKVM.NET.
Neben der Implementierung einer virtuellen Maschine wurden auch die Core Java Klassenbibliotheken in .NET implementiert.

Für Umsteiger aus JAVA in .NET eine erstklassige Hilfe, seine liebgewonnenen Funktionalitäten weiter verwenden zu können.

MASSIVE ART hat die Engine u.a. in Kombination mit Lucene, Apache FOP (PDF Rendering) und .NET im Einsatz.

In .NET können Objekte sehr einfach serialisiert werden, um sie z.B. im Filesystem abzulegen.
Alles was man dazu braucht, ist ein Tag, dass man vor die Klasse stellt.
<Serializable()>
Mann muss allerdings beachten, dass in der Klasse alle inkludierten Objekte (Klassen) ebenfalls serialisiert werden können. (wiederum mit dem Tag <Serializable()> versehen sein müssen).

MASSIVE ART verwendet diese Funktionalität unter anderem im Cache Management von Webseiten. Ein Cache behält alle Objekte in einer Application Variablen, die zyklisch ins Filesystem gesichert wird.) Bei einem Reload des Webservers oder Recycle des Application Pools im IIS wird der Cache aus der gesicherten Klasse wieder rekonstruiert, anstatt sämtliche Inhalte zu verlieren.

Hier als Bsp. die Save und Load Methode in VB.NET implementiert ('myCacheFile - Filename' ist als Platzhalter gedacht) :

 Public Shared Sub SaveCacheIndex()
       Try
                Dim bF As New BinaryFormatter()
                Dim fStream As New FileStream('myCacheFile - Filename', System.IO.FileMode.Create)
                'Get object to serialize
                Dim myCacheManager As CacheManager = GetCurrentCacheManager()
                bF.Serialize(fStream, myCacheManager)
                fStream.Flush()
                fStream.Close()
            Catch ex As Exception
                ' we are not able to save cacheindex-file
                'Throw New Exception("Error on saving cacheindex: " + ex.Message)
            End Try
        End Sub
        Public Shared Function LoadCacheIndex() As CacheManager
            Try
                Dim cM As CacheManager
                Dim bF As New BinaryFormatter()
                Dim fi As New FileInfo('myCacheFile - Filename')
                If (fi.Exists) Then
                    Dim fStream As New FileStream(Client_Main.cacheTableFile, System.IO.FileMode.Open)
                    cM = bF.Deserialize(fStream)
                    fStream.Close()
                    Return cM
                End If
                Return Nothing
            Catch ex As Exception
                Throw New Exception("Path: " & "'myCacheFile - Filename'" & " : " & ex.Message)
            End Try
        End Function

Ein Problem, dass sich in unserer Entwicklungsabteilung ergeben hat, ist im Web vielfach diskutiert. Jedoch konnte  ich in keinem Forum eine Lösung finden.

Webservices ermöglichen uns auf elegante Weise definierte Schnittstellen mit anderen Applikationen aufzubauen. Innerhalb von .NET Anwendungen funktioniert das auch sehr gut. Mit ein paar Clicks erstellt oder konsumiert man einen .NET Wer-Service.

Leider ist das aber aus JAVA heraus nicht so einfach. Nach längerem Research habe ich jedoch eine Lösung parat. Das Geheimnis ist, dass man einen eigenen Soap Header über die Webservice Methoden setzt.

Ein Beispiel:
<SoapRpcMethod(Action:="http://www.massiveart.com/DoSomething",        RequestNamespace:="http://www.icubus-software.com/DosNamespace",        ResponseNamespace:="http://www.icubus-software.com/DosNamespace"), WebMethod(Description:="This is a sample description.",
MessageName:="myMessageName",
EnableSession:=True)>

Erst nach diesem Header, kann das Webservice auch aus Java aufgerufen werden.