So, today we're going to look at a quick overview of Eclipse Swordfish, which is a new project for SOA that was started up in September, if I remember correctly, so quite recently. And would you like to introduce yourself? Yeah, I'd like to introduce myself, my company, and the project. My name is Rico Deutscher. I'm one of the two managing directors of SOPARA. SOPARA is a newly founded company in Germany. It was founded in March this year. And we positioned ourselves as a provider for open source SOA platform. And we became a strategic member of Eclipse Foundation and initiated a new project called Swordfish. The goal of this project is to provide a runtime framework for SOA platform. Eclipse is very strong on the tooling side, has a SOA tooling platform called STP, but no SOA runtime framework. And this was the reason why we initiated that within Eclipse. And then just to be clear, I mean, what you mean by SOA runtime is, while there's tooling in Eclipse for creating SOA sort of components, or an SOA, if you will, what this is is more, when you've already created your SOA, you want to actually run it. And this is sort of like a deployment thing or a runtime, if you will, for running whatever SOA you might have come up with. For example, Enterprise Service Bus is a SOA runtime component. Right. That makes sense. So this is actually code that you'll use at production, not just during development. Yeah. This code is quite mature because it was developed the last six years as part of Deutsche Post in Germany.
2:04And it's now contributed as part of this Swordfish project. Right. So let's jump into the technical part of this presentation. We see that there were two major technical inhibitors for a coherent SOA platform in the past. Number one, a split of relevant standards. Number two, gaps in the component models. If we go to point number one, we see that JBI and SCA are the two major standards in regards to SOA. And the political view in the past is that they compete. And you see it from the industry initial drivers, Sun, Iona, and Tipco pushed very much JBI. And IBM, BA, SAP pushed very much SCA. Right. And you see it in the open source implementations. There is no platform available on the market, no commercial one, and no open source implementation, which implement two standards, both standards. ServiceMix, OpenESB, implement JBI, and Tuscany, FAPI-3, implement SCA. But there's no one implementing both of them. And do you think that's just because people sort of put stakes on the ground and they're just interested in developing those two things out? I mean, there's not really a – is there a technical reason for it? No. I think really from a technical point of view, they're very much complementary. Yeah. The overlap is very small. And they could fulfill different roles as part of a runtime environment. SCA could be responsible for assembly and deployment of composite applications. And JBI could become a runtime execution of service components.
4:08Right, right, right. But let me come to a second reason and explain it in detail. The second reason was that in the past, component models show gaps for SOA platform. We see two major component models in the past. JEE is very heavyweight and very complex. Spring is lightweight but does not have dynamic deployment or reconfiguration. Therefore, we see OSGI as a winning component model for the next innovation cycle because OSGI shows dynamic behavior. It's easy to use, has a small footprint, and it's quite mature. Right. And what do you mean exactly by the dynamic part? For example, a hot deployment. Hot deployment of bundles is a component that's not possible in JE, neither in Spring, but it is possible in OSGI. Why do you call it enterprise OSGI instead of just OSGI? Well, because OSGI was designed for the development environments, so this is the basis for Eclipse IDE. Right, right. In order to bring that to the runtime, to the server side, it needs some extensions. Right. And currently, there are initiatives in the OSGI expert group driving OSGI standard towards server side, and it's underway. Right. And there's a lot of – has a lot of industry backing from major vendors as, for example, IBM and BA and others. And so there's enough momentum to bring OSGI enterprise, server side enterprise ready. If you combine the two arguments together, it's very obvious that we need a major open source SOA initiative which combines all three standards.
6:22Right. OSGI on the lowest level for a component, common deployment model and runtime component model. A JBI in the middle for a common messaging model and SEA on top for a common programming model and common assembly description format. Right. So the question now was who drives that initiative and who hosts this initiative? And the answer today is that this project is called Swordfish. It's hosted in Eclipse Foundation, and SOPRA is a driver behind this initiative. Let's quickly have a look at the Swordfish architecture. Right, right. You can see here on this picture that everything is bundled into OSGI bundles. So it's really based on OSGI. And the components within these bundles are implementation – it's implementation of JBI in the first step and of SEA in the second step. So you're going to sort of tackle the JBI things first and then get on to the SEA things after that? Exactly, because JBI was used at Deutsche Post. Right. And this is pretty much available with some modification needed. And once we have that achieved, we move towards SEA, because this is also an important standard, as I said at the beginning. So each of the – in the middle, we have the OSGI runtime, which I would assume is Equinox, right? And then each of the things – each of the different, I don't know, sort of popsicles that are attached to it are – I mean, those are the different services that the Swordfish platform is going to provide, right? Exactly. Okay. Last chart here outlines a high-level roadmap. So we started with incubation phase, I guess it was September, and have an initial submission by Deutsche Post, I guess it was a week ago.
8:33Right. And we think we have a first milestone in February next year. We'll try to achieve a first release 1.0 at the end of the third quarter next year with SEA support. We think it will not go into Ganymate, but we hope to get – to reach a maturation phase in the fourth quarter next year and to make the second release part of the next Eclipse release train. And so, I mean, what do you anticipate people being able to do with the 1.0 version once it comes out? I mean, what's the sort of scope of projects that they could use it on? This is the last chart here. You see here what the current user community of Swordfish is. Right. There are some projects which we leverage within Swordfish, for example, EclipseLink and Higgins and maybe ALF. We collaborate with WTP and STP to make deployment into Swordfish happen. And there are a number of projects we will benefit from Swordfish. For example, ALF, again, OOSE and EclipseLink and the OHF. I think it's the Open Health Project, Healthcare Project. Oh, right, right, right. And this chart is already outdated. I know a number of other projects which also think about using Swordfish as a basis component. So, I mean, what do you anticipate the – so you have different tooling like STPs to sort of help out with making,
10:37whether it's an SOA thing and tooling to make the different OSGI bundles or whatever may be involved. But once you sort of have something built on top of Swordfish, I mean, how do you go about setting it up in runtime? There are different options. You can run it in an application server. We – yeah, in an application server, you can run it in an OSGI environment. Uh-huh. Whatever is available, I would say each major Java runtime environment, you can operate Swordfish. So, Swordfish will need some sort of container, if you will, to run inside of. Right. And it more just provides a layer. Like if you were running it on top of an OSGI, like Iconox or something, it's more of a layering on top of that runtime to sort of help your architecture. Exactly, exactly. Use that runtime. So, if – whenever Swordfish was ready, right, and if I wanted to use Swordfish on my software project, right, I mean, like what I just need to know about JBI, SCA, and OSGI, or is there – what I need to know about how Swordfish does things? Like I'm trying to figure out if it's sort of like a new – like a model of doing development, like done the Swordfish way, or if it's more sort of – in the same way that Spring is sort of some helper APIs to help you out with existing code bases. We – I think if you – if the project used JBI in the past, it can leverage Swordfish, the same with SCA, but I think Swordfish will potentially bring up some own APIs in the future. Because – because – and the different sort of APIs and services that provide, like we were seeing in that – the diagram a few slides back, those are – it's more providing those different services for you to use in your project than necessarily dictating a way that you develop your project, if I understand it correctly.
12:43Definitely, yeah. So it's sort of like if you need a messaging bus service or you need a service to help you, you know, whatever those various services are instead of writing – It is a framework to build a SOA environment, runtime environment. Right. It does not surprise a messaging service. So you need to have a messaging system below. So you need that. It does not provide a service registry. Right. You – well, you need a service registry to run it. For both, there are open source candidates for messaging, active MQ or a JORAM. For a service registry, you could use OpenUDDI and Shure as a UDDI server, version 3 server. Right. So you can combine this together. Swordfish is somehow a glue, a framework, which combines all elements necessary for a SOA platform. Right. Now, yeah, that makes perfect sense because I think in the Java world, people are familiar with that. Yeah, and this is exactly what Zopra provides as a product. A whole SOA platform builds out of major open source components, and Swordfish will be just one of these open source components. You see here on the screen, it's the very last chart. Right. You see here outlined on the bottom, you see four major types of plug-ins needed for a SOA runtime platform. It's a messaging, a registry, a security, a people engine. Yeah. And for all these type of plug-in, there are commercial candidates and open source candidates. And in order to integrate that into one SOA platform, you need Swordfish.
14:45Okay. So this chart outlines the role of Swordfish code as part of an open source, of an SOA suite in general. Yeah, that makes sense. So you can use existing commercial components. You can use open source components if there's no use in a company. And, yeah, build a complete SOA suite out of that. Right. Well, that makes sense. Yeah. That's pretty exciting, actually. The conclusion is for users, always consider open source products in your SOA project. Right. Right. The conclusion for ISVs is become a contributor to the Eclipse Swordfish project in order to leverage commodity components to reduce your cost. And the conclusion for system integrators is consider open source products in SOA projects for your clients. Right. And developers, if you want to work with SOA technology, become a contributor of the Eclipse Swordfish project. Right, right. Well, that sounds great. Well, thanks for taking the time to go over this with us. It'll be, I guess, a little bit, you know, two-thirds of the way through next year, we'll see the 1.0 version. And, of course, there'll be the betas and whatnot, but it'll be fun to see. It's always nice to have more glue in the SOA world to help make things easier, right? Thank you for having the opportunity to outline this. Absolutely.