Recently, we’ve discovered - thanks to a number of customer requests - that support for EDI and EDIFACT is a must-have feature. Currently, with our SOPERA DI we are delivering the first version of our EDI/EDIFACT related components, based on an open source smooks framework. These components work quite well for simple EDI messages. You can configure the EDI mapping and read EDI messages into your SOPERA DI Jobs. We have already used them in a few customer cases and have learned quite a lot from it. Here are some of the major issues we encountered:

• You need to specify the mappings manually, even when processing standard EDI messages, for example, UN EDIFACT.
• It’s hard to read the UN/EDIFACT interchange that contains multiple messages of the same type, and it’s impossible to read UN/EDIFACT interchange with multiple messages of different type.
• The current state of components is not capable of writing out EDI files, only parsing/reading is supported to date.
• The tooling provided to read EDI messages inside the SOPERA DI needs to be improved. For example, we could display the message structure to simplify the mapping with a point-and-click feature.

At the same time the framework we were previously using for parsing EDI messages in SOPERA DI EDI components has made significant progress in the areas mentioned above allowing us now to take advantage of these improvements as well as to continue with our efforts to test and fix bugs. Here I would like to give you a short preview of the improvements we’ve made in this area.

UN/EDIFACT Mappings

The first area we improved is the manual definition of EDIFACT mapping files. This task can be quite tedious - one has to convert the UN/EDIFACT definitions into an XML-based mapping that can be used for EDI parsing. With the updated EDIFACT tooling you can get them automatically generated from UN definitions. Let us take for example the UN Customs cargo report message (CUSCAR). The picture below demonstrates this process:

Automated Mapping Generation

Here we take the CUSCAR definition which is available for download for example from within the package d99a.zip, and automatically generate XML Mappings according to the CUSCAR description from the UN. Now you can be sure all segments, segment groups, fields, and components are available in the mapping with all cardinalities as well as optional and mandatory flags. Moreover, since the ZIP file from the UN contains not only a single CUSCAR dialect definition but many others you will also get them packaged and ready to use.

UN/EDIFACT Inter-exchange processing

As you might know the EDI inter-exchange may contain multiple EDI messages of different types, each messages starts with the header segment that defines the message type (dialect), release year etc. For example, here is the header for the CUSCAR message:

UNB+UNOA:2+SENDER+SENDER+100421:0437+1918'
UNH+163477+CUSCAR:D:99A:UN:SCPRBL'

The second field of the UNH segment defines the dialect - here it’s CUSCAR released in the first part of the year 1999 (D99A) by the UN. The updated UN/EDIFACT parser is able to recognize individual messages as well as message dialects and dynamically chooses the appropriate mapping from the mapping JAR files generated before, as shown here:

Dynamic UN/EDIFACT Interexchange parsing

Writing out UN/EDIFACT files

Currently, our SOPERA DI EDI components do not support EDIFACT file generation. Basically, EDIFACT files are just simple text files, and one could simply use a plain template approach to generate EDI. However, we’d like to have additional semantic and syntax checks as well as validation checks. For this purpose we could use an EJC compiler as shown in this figure:

EDI-to-Java roundtrip

The basic idea is that we could generate a set of Java classes based on the UN/EDIFACT mapping files. These classes would then represent segments, segment groups or fields/components specified in the mapping file, and the best part is- you can use them to read EDI as well as write EDI out. It’s similar to the Java API for XML Data Binding, but in this case we bind the Java objects to the EDI content.

Improved UI for SOPERA DI Components

All of the features mentioned above are very useful but our experience shows us that we need to improve the user interface of SOPERA DI EDI components. Right now we are still in the planning and investigation phase. So if you think you have a nice feature proposal we would be glad to hear from you, just leave your comment on this blog post.

Conclusion

All in all with the new functions of the extended EDI processing we can provide a significantly improved user experience that will greatly simplify EDI processing. However, there is still some work to do, but what is clear right now is that all of it will be brought to you by SOPERA and the smooks team as an open source project so you are welcome to participate, contribute, and improve it.

Last year we launched the new SOPERA Partner Program. Our partners get earlier access to new product versions and technologies. They have the opportunity to give input to the SOPERA roadmap and release plans, and benefit from best practices in dedicated areas of application. Trainings to increase the technical know-how are included in the partner fee.

New Partners

Today we welcome our new partners:

• CapGemini
• CSC
• cologne intelligence
• saxonia
• senacor
• tarent
• USU AG
• Meyer Business Services

You can find more information about our Partner Program here.

Ich denke, man sieht hier noch immer die Unsicherheit dieser Firmen im Umgang mit Open Source Projekten. Die verbliebenen Mitglieder Obeo, itemis und SOPERA, deren Geschäftsmodell auch eng mit Open Source Projekten verbunden ist, haben die Arbeit trotzdem fortgeführt. Schließlich trat die Firma Engineering, Italiens größter Systemintegrator, der Industry Group im Februar 2010 bei und gab mit den zwei neuen SOA-Projekten ( eBPM und eBAM) der ganzen Initiative ein neues zusätzliches Momentum. Deshalb wird die Eclipse SOA Industry Working Group nun mit einem halben Jahr Verzögerung diese Woche auf den SOA Days der Deutschen Post offiziell durch eine Keynote von Mike Milinkovich gestartet.

SOPERA’s SOA open source software is based on a building a community for developers. SOPERA has created a partner program to extend our ability to reach members of this community. Our partner pogram offers strategic alliances and enables us to offer customized and innovative solutions.

Types of Partnerships

SOPERA offers a partner program with various options for cooperation. Here is a short list of what our partner program covers:

• System Integrators
• Master Resellers
• Independent Software Vendors
• Technology Partners

For more information, see Partner Program.

1. Zu meinem großen Erstaunen teilen weitere Eclipse-Mitglieder unsere Vision und haben ihre Teilnahme angekündigt, und
2. die Foundation stellt seit Kurzem eine neue Organisationsform - die Industry Working Group - bereit, die die Ziele der Initiative organisatorisch sinnvoll abbilden kann. Das  Konstrukt der Industry Working Group erlaubt die Bildung von Sub-Konsortien innerhalb des Eclipse-Konstortiums mit eigenen Governance-Regeln und eigenem Branding. Nun, wo ich das Konstrukt erstmals verstanden habe, bin ich total begeistert davon und überzeugt, dass das es ein sehr großes Potential für die Eclipse-Foundation darstellt (Mike - die Credits gehen an Dich. Great Job!)

Zurück zur Eclipse SOA Initiative. Die Ziele dieser Initiative haben sich nicht geändert:

• Bereitstellung einer auf Equinox basierten, integrierten und erweiterbaren Eclipse SOA Platform inkl. Tooling und Runtime
• Förderung der Adoption dieser Platform durch Vendoren, System Integratoren und Distributoren
• Erreichung von Interoperabilität zwischen verschiedenen Produkten der teilnehmenden Vendoren

Dieses Ziele werden nunmehr durch zwei Maßnahmen innerhalb der Foundation erzielt:

1. Es wird ein neues Top-Level-Projekt “Eclipse SOA Platform” gebildet, das initial aus STP (dem Tooling) und Swordfish (der Runtime) besteht. Es soll das Zuhause für alle zukünftigen SOA Projekte werden (z.B. BPM, BAM, Registry/Repository). Dafür wurde eine neue Charter entwickelt. Das STP PMC hat dieser Charter bereits zugestimmt. Die Zustimmung des Boards wird bei nächster Gelegenheit eingeholt.
2. Es wird eine Eclipse SOA Industry Working Group (IWG) gegründet (Wir suchen noch einen coolen Nick name. Wer eine Idee hat, kann sie mir gern posten), die (a) die Anforderungen an die Eclipse SOA Platform definiert, (b) eine neue Marke für diese Platform entwickelt, und (c) messbare Kriterien festlegt, wer diese Marke wie nutzen darf. Diesen Brand sollen insbesondere auch von Nicht-Mitglieder wie ISVs und Systemintegratoren genutzt werden.

Diese Aufbauarbeit der letzten drei Monate war eine großartige Teamarbeit zusammen mit Oisin Hurley von Progress und Donald Smith von der Eclipse Management Organisation (Guys, es macht großen Spass mit Euch zusamenzuarbeiten!). Ich möchte mich an der Stelle auch für die Unterstützung bei Ralph Müller bedanken (Ralph - ich erinnere mich noch sehr gut an unser entscheidendes Meeting mit Mike am Frankfurter Flughafen. Danke für die Ausdauer mit mir!). In den nächsten wenigen Wochen wird sich herausstellen, wer die Gründungsfirmen neben SOPERA und Progress sein werden. Seit dem letzten Board Meeting ist jedoch klar, dass wir die kritische Masse an Gründungsmitgliedern erreicht haben. Wer das wird, wird demnächst hier publiziert. Stay tuned!

Ricco

Auch wenn diese Eclipse SOA Initiative zunächst eine SOPERA-Initiative ist, so suchen wir die Zusammenarbeit mit anderen SOA-interessierten Firmen und Eclipse-Mitgliedern. Eine solche Zusammenarbeit würde es erlauben, die entstehende Eclipse-SOA-Plattform noch schneller und noch näher an den Marktbedürfnissen zu entwickeln. Es gab gestern Abend mit dem EMO (Eclipse Management Organization) ein Gespräch zu der Frage, in welche organisatorische Form diese Initiative eingebettet werden könnte. Es scheint, das eine “Industry Working Group” für eine solche Initiative gut geeignet ist, da hier flexibel eigene Governance-Strukturen festgelegt werden können.

Wir erwarten bei den traditionellen Lizenz-Anbieter von SOA-Platformen auf die Eclipse SOA Initiative keine überschwengliche Begeisterung, da dadurch der Wert der kommerziellen Plattformen kanibalisiert werden könnte. Erste Gespräche mit Eclipse-Mitgliedern werden hier auf der EclipseCON stattfinden. Bei den Unternehmen auf der SOA-Nutzer-Seite stoßen wir nicht unerwartet auf sehr großes Interesse. SOPERA ist hier mit einigen Großkunden im Gespräch, die bereit sind, eine solche Initiative zu unterstützen.

Aber auch in einem solchen Szenario stellt sich die fundamentale Frage der Integration. Cloud Computing hat dabei über die traditionelle Applikationsintegration hinausgehende zusätzliche Anforderungen. Die Tatsache, dass Services von verschiedenen Providern bezogen werden können, erfordert ein Service-Level-Monitoring. Weiterhin müssen die verschiedenen Plattformen, auf denen die Services entwickelt und betrieben werden (hauptsächlich Java und . Net) völlig transparent sein. Es wird auch dazu kommen, dass ein Unternehmen für einen Service mehrere Provider nutzt, und die Auswahl des Providers dynamisch über die gerade für das Unternehmen benötigten Service Levels geschieht. Das sind Anforderungen, die der Internet Service Bus - der Enterprise Service Bus der Application Cloud - erfüllen muss. SOPERA hat mit dem auf der Cebit präsentierten Prototypen bewiesen, dass es wichtige Anforderungen eines Internet Service Bus bereits heute erfüllt. Dazu zählt:

• Eine dezentrale Bus-Architektur die Skalierbarkeit in der Cloud sicherstellt
• Native Implementierung in den beiden vorherrschenden Applikationsplattformen Java und .Net
• Eine dynamische, Policy-basierte Mediation zwischen Service-Provider und -Consumer

SOPERA ist damit bestens für den Zukunftsmarkt Cloud Computing positioniert.