Friday, December 05, 2008

SSHD becomes an Apache Mina subproject

Just an update on the SSHD project I started a few weeks ago. It has been accepted yesterday as a MINA subproject :-)
You can find all the needed pointers on the web site.

Tuesday, November 25, 2008

ServiceMix4: much more than a JBI container

David Greco has posted a nice blog entry about ServiceMix Kernel.
I do totally agree: ServiceMix 4 is not only a JBI container, and more precisely the ServiceMix Kernel which can be run standalone is a universal container (which does not include JBI by default) where you can deploy virtually any kind of artifact from web applications, to JBI applications or plain JAX-WS services.

Thursday, November 13, 2008

SSH Server in Java

ServiceMix Kernel is a small container based on OSGi. The latest release allows external clients to connect to it and issue commands using a simple protocol implemented on top of TCP or SSL. However, this remoting protocol has some drawbacks as the internals makes it unable to do another remote login from a remote session. In addition to that, completion and history do not really work great.

So I've been thinking about using the SSH protocol, which is widely used, secured, with tons of different clients available. Unfortunately, no SSH server is available in Java. Over the past weeks, I've been working on implementing this SSH server, based on the IEFT specifications, the JSch SSH client library, and the OpenSSH server source code. The server itself is based on Apache Mina which is a great framework for using NIO.

The project is available at http://code.google.com/p/sshd/ and although there are lots of limitations right now, the basics of the SSH protocol work. I plan to integrate it in a bit into ServiceMix Kernel as the default remoting protocol. Maybe over time, we'll be able to implement SFTP or even a full SSH server integrated with Unix OS (I've already made some tests, but I'm missing a few bits on the PAM integration for authenticating against the OS).

Anyway, if anyone want to contribute or have any problems trying to use it, just send me an email. I may set up a google group list for that later if there is any need.




Update: the code is now developed as a subproject of Apache Mina and available at http://mina.apache.org/sshd/

Wednesday, October 15, 2008

FUSE ESB 4 release!

FUSE ESB 4 has just been released. I welcome everybody to download and give it a try.

Thursday, September 18, 2008

Apache ServiceMix Kernel 1.0.0 released!

Apache ServiceMix Kernel 1.0.0 has just been released.

Apache ServiceMix Kernel is a small OSGi based runtime which provides
a lightweight container onto which various bundles can be deployed.
Amongst the list of supported features, Apache ServiceMix Kernel supports:
  • hot deployment of OSGi bundles, exploded bundles or custom artifacts (spring xml configuration files support is provided)
  • services configuration stored as property files are monitored and provided as standard OSGi configurations
  • a centralized logging back end supported by Log4J, ServiceMix Kernel supports a number of different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi)
  • provisioning of libraries or applications can be done using simple commands via simple xml descriptors
  • native OS integration as a service so that the lifecycle will be bound to your Operating System.
  • an extensible shell console to manage services, applications and libraries
  • operations on the console can be done remotely via a secured and encrypted channel
  • a security framework based on JAAS
  • new instances can be created using a single command line

This release, with the detailed release notes, is available at:
http://servicemix.apache.org/kernel/servicemix-kernel-100.html.

IONA FUSE Open Source Group now offically part of Progress

I'll just quote Rob's blog entry:

Progress completed its acquisition of IONA Technologies last Friday. The FUSE open source group will be running as its own business unit as part of the Progress Software Corporation - so we are still operating as before - but with considerably more investment.

Progress saw the number and quality of enterprise customers we have using our integration products, saw that we consistently met and exceeded our sales targets and realized our potential to grow significantly.

So although we currently employee a lot of open source developers - we will be recruiting even more - and have some exciting new software projects in development for release in 2009 :)

Tuesday, September 09, 2008

Bundling third party dependencies in ServiceMix 4

I'd like to talk a bit about third party dependencies in ServiceMix 4.

ServiceMix 4 is based on OSGi and when deploying applications to it, you have two choices:
  • use the JBI packaging
  • use the OSGi packaging

The first solution is a good thing if you want to abide by the JBI specification completely or if you want to use non OSGi aware components. However, you'll come into the known limitations of the JBI packaging with respect to classloaders: the JBI specification is quite limited in this area.
The second solution is more powerful as, in addition to being able to leverage the OSGi classloader mechanisms, you'll also be able to access the OSGi registry, thus registering or retrieving services in the registry.

However, when using the OSGi packaging, you need to deal with third party dependencies. OSGi is becoming more and more popular, so more and more projects are now distributing the jars as native OSGi bundles. But not all have converted to OSGi yet. And of course, you also need to transform your own jars into OSGi bundles.

Costin Leau has covered most of the aspects of creating OSGi bundles in his blog post. But there are a few tweaks that I want to talk about.

When repackaging a library as an OSGi bundle, one as to take care about package imports. I had a question recently about a problem when repackaging c3p0. This library is a JDBC connection pool, so it needs the class for the JDBC driver to be available in its classpath. A simplistic way to handle the problem is to force an optional import of the package containing the driver you use. This would be something like:
   Import-Package: *, com.mysql.jdbc;resolution:=optional

The drawback is that you tie your mysql bundle to the driver you use, which will break things if you want to switch to another database.
OSGi has a solution for such things which is called Dynamic Imports. This is needed when a library uses the Class.forName() method to load classes dynamically, such as the c3p0 library. The big difference between static imports and dynamic imports is that dynamic imports are resolved ... dynamically. This means that when the Class.forName() method is called, the OSGi framework will look for the requested package and wire it to your bundle at runtime. The OSGi headers would look like:
   Import-Package: *
DynamicImport-Package: *

But this feature must be use with caution, and only when possible to avoid having unwanted wiring between bundles.

A second use case if the legal problems encountered while dealing with proprietary software of non liberal open source licenses. IANAL, so take the following with the appropriate caution and check with your legal department before doing anything. Back to the point: proprietary software often forbid any modification to the jars. In such a case, the only alternative is to embed the jar in an OSGi bundle. Basically, when you repackage a library into an OSGi bundle, you extract the content of the jar, add some OSGi headers to the manifest, and rebuild the jar. There is an alternative though, which is to create a bundle and include the full jar inside it. The bnd tool and felix bundle plugin for maven (which uses bnd) both support that and you end up with using the Bundle-Classpath header:
   Import-Package: *
Bundle-Classpath: .,bin/mysql-connector-java-5.1.6.jar

The only drawback is that the bundle jar can not be used anymore in a non-OSGi environment.

Before bundling a jar, check the existing bundle repositories (the ServiceMix one or the SpringSource one) for an existing bundle. And if you write one for an open source library, feel free to submit a patch if you want ServiceMix to host it...

Happy bundling!

A fun physic game

I found Fantastic Contraption a small, but very fun game to play. Here is my solution to the last free level. Enjoy!

Monday, September 08, 2008

What's new in ServiceMix 4.x?

Rod Biresch has posted a nice blog post about what's new in ServiceMix 4.x. Definitely worth a read!

Tuesday, July 29, 2008

Is JBI so bad?

Ross Mason, the CTO of MuleSource, recently started a discussion about JBI.

His first point is that JBI is no TCP/IP, meaning somehow that JBI is targeted at vendors and not at developers. Well, I'm not sure about the TCP/IP thingy, but he's a bit right about JBI being targeted at vendors and not developers. Why? If you have some knowledge about JBI, you know that there are multiple JBI components (bindings that handle a particular protocol such as HTML, JMS, etc... and engines that provides business logic such as a rules engine, a BPEL engine and so on). The developer will mostly see those components, not the JBI APIs: if you work with a BPEL engine and write a process, you won't see the JBI APIs surface in the BPEL at all. If you write a WSDL to define a SOAP/HTTP service, you won't really see JBI there either. So, yes, at some point, he is right that JBI 1.0 hasn't focused on the developer, or I should say, the user. Because if you need a custom component for your JBI container, you, as a developer, will need to dive into JBI and fully understand it. At this point, if you don't use JBI, you'd have to dive into a proprietary set of APIs to write your component. JBI aims to be mostly hidden for the users.

His second point is about some of the restrictions in JBI 1.0, mainly the use of XML, WSDL and no support for streaming. About XML, JBI has ways to convey binary data in non XML formats using attachments (don't you use attachments in your emails?). About WSDL, this point seems a bit weird since MuleSource has a product named Galaxy which is a registry of services described by WSDLs. Everyone knows WSDL is the standard for describing services. Anyway, the JBI specification says each endpoint has to be described by a WSDL, however, since the early days of ServiceMix, WSDL has not been a requirement and you can deploy your endpoints without any WSDL at all. With respect to data streaming, I'm not sure to understand the supposed flaw of JBI here: in the JBI world, a message contains an XML payload (which can be a stream, a DOM document or any kind of XML representation) and a set of attachments (which can also be streams). Just leveraging these APIs, JBI components are able to transfer very large amount of data using streams only.

His third point is about component reuse in JBI. We have users using ServiceMix components inside OpenESB and others using OpenESB components inside ServiceMix. It's true that most of the JBI vendors offer their own set of components. Let me ask the question: doesn't Mule come with its own set of transports? It would not make sense at all to distribute an ESB without any support for the most commonly used transports. It does not mean that these components can not work together.

Last comes some points about the existing standards. Since a long time, I don't think SCA should be viewed as a competitor to JBI. For some reasons exposed above, JBI does not really target the end users, while SCA does. However, SCA does not allow components to interoperate together. Hence, those two standards are complementary, not competitors.

All in all, I think JBI is a good specification. It does not address all the possible use cases in the best way (I'm thinking about handling non XML data) and sometimes goes beyong what should have been required (on the packaging and deployment side), but the core messaging APIs are well defined, and given the success of ServiceMix, I'm far from thinking that JBI should be dismissed.

Monday, May 26, 2008

Java EE specs in OSGi

For ServiceMix 4, I've been working on making sure the Java EE specifications can be used in OSGi. The first step was to release OSGi versions of the various specifications by just adding the needed manifest entries to make them usable in OSGi. This was done inside the Geronimo project (on which I am a committer). This means that since a few months, most of the Java EE specification jars are available as OSGi bundles (you can grab those from maven 2 public repositories.

However, this is not always sufficient. Some of these specifications (mostly JAXB, SAAJ, JAX-WS and Stax) do not work well in OSGi. The mean reason is that the implementation is discovered using different mechanisms by the API. The most commonly used one is to find a file on the classpath in the META-INF/services directory and find the main entry point class of the implementation. Unfortunately, to make this work in OSGi, the client bundle (the one using one of these APIs) has to have the required file in its classpath, which means the inability to use one provided by the runtime in which the bundle is deployed and that it can not be switched without changing and re-compiling the bundle. Another way would be to add a Require-Bundle OSGi manifest so that the classpath of the implementation becomes part of the client bundle, but this also ties the client bundle to the implementation used.

The solution came to me after a chat with Dan Kulp: an OSGi specific discovery mechanism can be easily plugged into these spec jars. It consists in two small classes shared amongst these spec jars: an OSGi bundle activator and another class not tied to the OSGi api that maintain a list of available implementations. The final step if to rewrite the factory of those jars to look inside this map before performing the usual lookup.

This means that in a non OSGi environment, the jar behaves as usual, but when deployed into an OSGi runtime such as ServiceMix Kernel, the spec bundle will be able to locate dynamically the implementation to use. Therefore, the client bundle using the spec jar is now free of any requirements.

Wednesday, May 21, 2008

JAAS in OSGi

I've working on implementing the security framework for ServiceMix 4. ServiceMix 3 used JAAS for the authentication part, and it also makes sense to use it in ServiceMix 4 for several reasons: reuse of existing login modules, integration with the JMX and the console security which are already based on JAAS.
However JAAS is not very OSGi friendly (well, most of the JEE specifications are not, and I'll talk about the others in another post), mostly because is makes some strong assumptions upon the thread context classloader, and this, mainly on the client code. This means the client that uses the JAAS api to authenticate has to have all the login modules available in its thread context classloader. This is usually not the case in OSGi.
So the solution is to use a proxy login module that will be available to all bundles (by using the boot framework delegation package). This proxy login module can use some OSGi properties on the login module configuration to determine the actual class to use and the bundle to load it from.
Using a simple XML schema for Spring, you can deploy a JAAS realm very easily:

<jaas:config id="realm" xmlns:jaas="http://servicemix.apache.org/jaas">
<jaas:module className="org.apache.servicemix.kernel.jaas.config.SimpleLoginModule" flags="required">
key=value
</jaas:module>
</jaas:config>


This will register a service in OSGi that the OSGi specific Configuration for JAAS will discover and make it available for clients.

Find more informations on the ServiceMix Kernel JAAS doc.

Thursday, May 15, 2008

ServiceMix 4 NMR on Equinox

I've done some experiments today to check that ServiceMix 4 NMR can be easily deployed on Equinox instead of Felix. Have a look at this wiki page.

Tuesday, May 13, 2008

Apache ServiceMix Kernel 1.0-m3

We've just released the third milestone of ServiceMix Kernel 1.0-m3. This small OSGi based container is really nice, if you haven't had a look at it yet, go and grab it.

It adds a bunch of cool new features. For example you can run:

osgi list | utils grep ServiceMix

or

log d | utils grep WARN


If you want to have a quick run at it, go and look at the quick start guide.

Wednesday, April 30, 2008

Spring App Server

I've just seen the annoucement that SpringSource has launched a new App Server based on OSGi (Spring-DM).
I find it a bit weird that they tend to rewrite existing stuff: the JMS JCA layer in Spring 2.x is somehow derived from the Jencks project, Spring Integration looks a lot like Camel, and now this app server which looks very similar to ServiceMix Kernel with WAR support (which we already had in ServiceMix 4 from the Pax Web project).

Friday, April 25, 2008

Ziphone

A friend of mine has cracked an iPhone a few months ago (shame on him...) but was quite reluctant to upgrade to a newer version in case the phone would be bricked.
Fortunately, I gave him a link to ZiPhone, which is the best way to unlock your iPhone I've found so far: just upgrade your phone using iTunes, launch the application and click. 5 minutes later, you have a jailbroken and unlocked iPhone with the latest firmware :-)

Dan has also blogged about Fring, a very nice application to to VoIP over the iPhone.

If you like to twitter, have a look at Twinkle too.

Friday, April 04, 2008

ApacheCon EU 2008

Bruce and I will be both at ApacheCon Europe in Amsterdam next week to talk about ServiceMix and Camel, so if you want to meet with us, send us a mail.
There will be a BOF about ServiceMix on Wednesday, so it will be a good opportunity to meet too.

JBI and SCA (again)

I've just seen this post saying:
One of the major motivations for doing so is that currently, the Java community is still split between SCA and JBI.

Well, this is somewhat true, I can't really deny it, but it should not be that way. JBI and SCA are not really competitors, even if they are usually seen that way. The JBI specification explains how to create an ESB that allows pluggable components to be wired easily thus allowing vendor independant components to be created. SCA defines a way to write composite applications in a clearly defined way that can be applied to different languages (though you can't really mix those, so you end up with one runtime per language you support).

As a standard, SCA offers value, but I really think both could be supported in a single runtime like FUSE ESB. We've discussed several times about supporting SCA on top of JBI in ServiceMix, but I haven't heard much needs on that. We are currently working hard on ServiceMix 4, based on OSGi and allowing lots of technologies to be plugged onto a single bus, including JBI, Camel, JAX-WS, EJB3, etc... Supporting SCA would only be another profile.