• Detect and list available zones
• Group zones together
• Stop/play/next/previous
• Playlist management
• Browse music
• Browse radio stations
• Volume control, both individual and group volume

I’ve also managed to add some more special features:

• Quickplay list – I use it for starting my favorite radio without having to navigate the browsing structure
• Indexing and freetext search
• Last.fm integration – covers are fetched automatically if none existed locally, and extra info (tags and play count) can be retrieved. Also, it’s possible to love a song using last.fm

All the features of the regular controller which I normally use are done, so I’m more or less ready to drop my iPhone. Now begins the hard part of adding new valuable features – most of them are not particularly easy to implement:

• Faster – the Android platform is pretty nice to work with, but Andronos is not exactly as fast as the native controller. Caching can add some performance, but in the end, I’ll probably have to do some pretty low-level optimizations all over the place
• Cover browsing – it should be possible to browse the music archive based on a list of covers
• Rhapsody and Pandora – probably not hard to do, but neither of the two are available in Denmark. Help is appreciated here – I don’t quite know how yet, but if you’re interested, please contact me.
• Dynamic playlists – Andronos should be able to dynamically create playlists based for example on loved songs, previously played songs, and so on. Also, it should be able to select music based on a general category (party, relaxing, cooking, whatever)

I’ll probably think of more features to add, but it should be enough for now – there should also be something left for Sonos to do when they get around to making a supported controller for Android.

And then to something a little different, but related. Someone asked me today if I had an opinion of mobile development with Android. Having worked with Android for a couple of my pet projects, there are some things I’ve noticed, and here are some of them, in no particular order. Hopefully, I’ll get time to elaborate on them later on.

• As a Java programmer, nothing really beats having your normal environment, in my case Eclipse, and all the standard libraries. Need UPnP? Download a library. Need last.fm integration? Download a library. Need raw network access? Download a library using JNI. (in the last case, be prepared to fiddle around with Make-ish files, but it can be done). No need to learn a new language or new basic tools, you just have to learn a new API.
• It can be a little hard to drop all the fancy patterns and design principles, but it’s often necessary to get acceptable performance. Object allocation and garbage collection is pretty expensive, which is the complete opposite of the regular Java VM, so you have to be careful, and that can hurt in a number of ways (think maintainability, API design, testability)
• The declarative UI approach works pretty well, but the Eclipse plugin does a pretty bad job of rendering the UI, so in most cases, you have to fire up the app on either an emulator or a phone to get a real look at the UI. A simple thing: Why are styles not rendered in the plugin?
• The UI does have a number of bugs and undocumented features. Drawables are probably the worst I’ve met. They can be defined in XML, and can be used for eg background gradients, button borders, and much more, but they are truly trial-and-error
• Android Market works pretty nicely, in principle, at least. I wouldn’t have been able to create Andronos if I’d had a turnaround time of a month for each release. Of course, Andronos is a little special, because Sonos systems can be configured in so many different ways, and I do not have one of each player model, but still. Being able to get a bug report, fix the bug, and release a new version in a matter of 10 minutes is pretty cool.
• A couple of things about Android Market, though: Why can’t I see the comments in a regular browser, and why can’t I reply to the comments?
• Fortunately, Andronos is pretty flexible in the layout, so it runs without any serious problems on both small and large screens. However, this can easily become a problem if you haven’t defined the UI in device-independent units, and even then, you might be forced to having different layouts for different devices. I’m guessing Apple will have to cope with this too, now that the iTablet (I forgot its name) is out
• I can see why root access is something you don’t want to give out to everybody, but couldn’t there be some way of getting partial root access? For example, if I want to send an ICMP packet, I need write access to the network device, but I can’t get that. Why?
• Error handling could be better when an application crashes. I’ve installed a custom exception handler which emails me stack traces, but couldn’t this just be built-in?
• The Android API itself is at points somewhat strange. Why do I sometimes need to bitwise add flags to a component? Why must I always remember to call super? Most of the time, it’s just like doing Swing, and I can live with that. The API could be more “modern”, however, and not use inheritance quite as much as it does.
• Testing isn’t as easy as it could have been (and with Andronos, it’s even harder, because most functionality only makes sense when connected to a Sonos device), but that’s at least in part because GUI testing has never been easy. Just learn to separate UI logic from “business” logic, and then the business logic can be tested as you would normally do it.
• Most importantly, and this outweighs any disadvantages Android might have: The platform is open, there’s an active community, there’s lot of open source, and you’re not forced into anything

That’s it for now. And no new releases tonight (but that’s probably just because I’ve been musically cultural tonight).

This has been quite a learning experience, both in regard to Android and Sonos – Sonos is controlled using UPNP, so now I probably know much more about that than I’d ever want to. However, it seems to have paid off, because I finally have something that works, at least somewhat. Performance isn’t great, and some features are still missing, but that should all be fixable.

My plans are to build some extra last.fm support into the remote control, so that it can, for example, generate queues based on track popularity, display album/artist/track info, and much more. Already, album covers are retrieved from last.fm (I’ll probably change this so it checks the Sonos system first, at some point).

The features implemented now are: basic playback control (previous, next, play, pause), mute/unmute, volume control, adding/removing from queue, and browse available music. Most important missing feature is probably zone management, but hopefully, I’ll get time to fix that soon. Also, internet radio isn’t working, and it seems that you cannot change from radio to regular playlist.

The application is available on Android Market under the name Andronos, so if you own an Android phone and a Sonos system, please try it out. Any bugs or suggestions can be reported on the Google Code site. If you’re really ambitious, I’m also accepting patches (the project is open source, after all). The code is hosted at Gitorious, so just go ahead and check it out.

All of this can be done more or less automatically with Metro (at least when using a nightly build) by using this service policy:

Here, we express that the service requires an issued token of type SAML 2.0. Issued token means that the token has been created by an STS. In this case, we specify that the STS identified by urn:localsts must issue a token of type SAML 2.0. The exact location of the STS needs to be configured in the client.

Unfortunately, WS-SecurityPolicy does not make it possible to express the requirements for the WS-Trust Issue request. When using identity delegation, two sets of credentials should be passed to the STS: The client credentials, for example an X509Token or a UsernameToken, and the user credentials. The client credentials are provided using standard WS-Security mechanisms, and the user credentials are included in the Issue request using the ActAs element.

As shown in the STS example, the STS policy file takes care of the client credentials by specifying the appropriate tokens. The user credentials token cannot, however, be expressed in the policy, so it needs to be agreed upon out of band. This also means that you have to provide it manually to the client.

Luckily, it's pretty easy to add an ActAs token to the client. Normally, the client is generated using wsimport. In this example, the service is called ProviderService:

Here, we create a new configuration object, set the endpoint information for the STS, and add an ActAs token. The contents of the ACT_AS attribute should be an instance of com.sun.xml.ws.security.Token, for example a com.sun.xml.wss.saml.Assertion. Normally, you don't generate the token yourself. Instead, you get it as part of the initial authentication response - for example, if you're using SAML 2.0 web SSO, one of the attributes received might be the ActAs token that should be passed to the STS when invoking services.

First of all, OIO-Trust is a Danish WS-Trust profile, which basically says how Issue requests should look. The basic premise is that in order to invoke a SOAP service, you need a token. The STS issues the token based on some criteria using the WS-Trust protocol on top of SOAP.
In OIO-Trust, the Issue request must be signed, and it must contain a so-called bootstrap token. The bootstrap token is a SAML 2.0 assertion. Furthermore, the request must contain the X509 certificate which is used to sign the message. The token requested in the Issue request is a PublicKey (that is, asymmetric) of type SAML 2.0. So, the input is a SAML 2.0 assertion, and the output is also a SAML 2.0 token. More specifically, the output is a holder-of-key token, which has the requestors X509 certificate in the SubjectConfirmationData. The assertion is signed by the STS, and contains by default all the attributes from the input assertion.

In order to create an STS using Metro, you need to

• Configure the Metro servlet in web.xml
• Implement a simple STS endpoint class
• Create a WSDL and a security policy
• Create a number of services for handling attributes, configuration, etc

Configuring web.xml
This assumes that you're using a simple servlet container. If the container supports JAX-WS, it shouldn't be necessary.
When using Metro, all requests go through the same servlet, the WSServlet. The exact endpoint implementation used is then configured in another file, WEB-INF/sun-jaxws.xml. Therefore, simply add the following to web.xml:

This maps all requests to /services to Metro.

Implement the STS endpoint
Implementing the endpoint is quite simple, as it's simply a question of extending a Metro class and injecting a resource. Here is a basic implementation:

No changes should be necessary, as the BaseSTSImpl class will handle all WS-Trust communication. What you need to do is to configure the base class according to the local requirements. More on that a little later.

In order to wire the STS endpoint into Metro, you need to create a WEB-INF/sun-jaxws.xml file. The file should contain something like this:

This binds the TokenService implementation to the url /services/sts using SOAP 1.1 (specified by the binding attribute).

Creating the WSDL and policy file
This is by far the hardest part of creating an STS for Metro. The WSDL should be pretty standard, and the same file can be used for all implementations. However, the WSDL file must also contain a security policy, as defined by WS-SecurityPolicy, and writing the policy can be pretty complicated. Netbeans has some support for writing policies, but I prefer to do it by hand because then you're sure what you'll get (once you understand WS-SecurityPolicy, that is).

The WSDL file tends to get somewhat large, so I won't include it here - instead, you can download it if you want to see it. Basically, the WSDL is split into two parts: The regular WSDL stuff with types, messages, porttypes, bindings, and services, and the WS-SecurityPolicy stuff. Normally, the policy consists of 3 parts: The service policy which defined which tokens should be used, and how the security header layout should be, a policy which defines signature and encryption requirements for the request, and a policy for the response. These parts are then wired into the normal WSDL using PolicyReference elements.
In the example file, the service policy defines that we're using an asymmetric binding (that is, the tokens should be different in the request and response - for example when using public/private keys). The policy also says something about the layout, and that the security header must contain a timestamp. Finally, it also enabled WS-Addressing.

Because this is an STS, the WSDL also contains a third part, namely static configuration of the STS. This includes configuring which certificates to use, how to validate incoming requests, and how tokens should be created.

Basically, this finishes the configuration of a very basic STS. However, there are some aspects which probably require some adjustments.

Checking if the requesting entity is allowed to access the requested service
When a client requests a new token, it includes a reference to the service in the AppliesTo element. Sometimes, there might be restrictions on who can access what. The Metro STS can check if the client is allowed to access a service by implementing the com.sun.xml.ws.api.security.trust.STSAuthorizationProvider interface. The interface has one method, isAuthorized(subject, appliesTo, tokenType, keyType), which returns true or false:

Metro uses the standard JDK service mechanism to discover implementations of this interface. That means that you should create the file /META-INF/services/ under your source directory and populate the file with the fully qualified classname of the implementation - in this example, create /META-INF/services/com.sun.xml.ws.api.security.trust.STSAuthorizationProvider with the contents dk.itst.oiosaml.sts.AuthorizationProvider.

Speficying attributes
Normally, you probably want to be able to configure the contents of the generated assertion, at the very least the attributes used, as well as the NameID of the subject. This is also done using a service implementation, this time using the com.sun.xml.ws.api.security.trust.STSAttributeProvider interface.

The STSAttributeProvider interface has one method, getClaimedAttributes(subject, appliesTo, tokenType, claims), which returns a map of all the attributes and their values.

The subject contains information about the requesting client, in our example identified by a X509 certificate. The claims object contains any claims included in the request. It also holds any tokens included in OnBehalfOf or ActAs. These tokens are placed in claims.getSupportingProperties(), where they can be read as Subject objects. Here's an example on reading an assertion, which has been included in ActAs:

The attribute provider can then be implemented - here's an example where the attributes from the ActAs assertion are simply copied to the resulting assertion:

Notice the last statement, where the NameID is added. The Metro STS will check if an attribute with the name STSAttributeProvider.NAME_IDENTIFIER is present, and in that case use that as the NameID of the subject in the generated assertion.

Handling configuration
The Metro STS must be know all services for which it can issue tokens. These services can either be configured statically in the WSDL file, or they can be provided programmatically. The static configuration is probably only interesting when developing, in a production environment, you probably want to build a nice admin console where services can be added and removed at runtime.

Static configuration takes place in the STSConfiguration element in the WSDL file. It can contain a ServiceProviders tag, which can then contain a number of ServiceProvider tags. Each ServiceProvider must be configured with an endpoint (the AppliesTo value), a certificate, and a token type:

The static configuration also contains information about the STS' own id (the Issuer element), as well as the lifetime of issued tokens. The CertAlias value of a ServiceProvider must point to an alias in the trust store.

Programmatic configuration
Controlling configuration programmatically is a question of providing a service implementation of com.sun.xml.ws.api.security.trust.config.STSConfigurationProvider. This interface has a single method, getSTSConfiguration(), which returns a configuration object - either your own implementation or an instanceof DefaultSTSConfiguration.

That more or less concludes my findings for now. There are a number of details I haven't covered here, but I'll wait with that until another time.

I'm running on a MacBook Pro Santa Rosa with 4 GB mem, which means that if I use the standard 32 bit kernel, I cannot use all of the memory. That's not really a problem, I just recompile the kernel to support PAE.
However, I also use XMonad (because it's the best window manager available), and previously I launched it from ~/.xsession. However, the new version of GDM doesn't support that anymore, so now you have to drop a file in /usr/share/xsessions/xmonad.desktop - mine contains this:

Other than that, simply follow this little guide to make the keyboard and touchpad work properly.

Anyways, we're planning on using JXTA to create a distributed version of one of our big monolithic systems. The data model has been modified to support distribution, and we've had a prototype running with hardcoded communication channels. However, JXTA makes everything much more dynamic, and it also introduces the concept of rendezvous and relay nodes so all nodes don't have to be on the same network - they don't even have to connect to each other directly. Pretty sweet stuff.

It turns out, however, that the JXTA documentation really doesn't explain everything, so I have two things I want to share - not that I expect them to be useful to very many people.

The first thing is really just a problem rather than a solution. I develop on a nice Macbook Pro Santa Rosa. I don't particularly like Apple (as in not at all, actually. Developer-wise, they might even be higher on the hate-list than Microsoft), so I've removed OSX entirely and installed Ubuntu instead. Now you might ask why I then use a Macbook at all, but it turns out that they make pretty good hardware, so I go with that. Incidentally, I also have an iMac at home, also running Ubuntu. It turns out that this is a problem in one single regard: When I have the wireless network enabled and start a JXTA application, the kernel will freeze. Every time. And there will be no errors in any log files. Nothing bad happens if I use wired network or a 3G modem - which is my solution until now. Of course, it seems that nobody in the whole world has ever had this problem, so there's not much chance of getting it fixed (and where do you report such a bug?).

The other thing that's been consuming quite a lot of my time is JXTASockets. JXTASockets are basically regular Java sockets running over JXTA. Instead of connecting to a specific host on a specific port, you simply ask JXTA to give you a socket to an abstract host identifier. JXTA will then route the request to the appropriate host, and then you can send and receive data. Except for the connect phase, it works just like a normal socket. Except not entirely. In many cases you would do something like on the server side:

And on the client side something like this:

Of course, all sorts of error handling, buffering, and other stuff is missing, but the overall procedure should be clear: the client writes to the output stream and closes it. The server reads from the stream until it has been closed. The server then generates a response and writes it back. Add the appropriate resource handling, and this will work using normal sockets, but it will not work with JXTA. And no, it is not obvious why. In fact, I think the plot of "A Serious Man" is more obvious, and if you've seen the movie, you'll probably agree with me that it is, indeed, not obvious at all.
The problem with JXTA turns out to be that both streams must be open all the time. If you, for example, close the output stream on the client side to signal that there is no more data, the server side will simply get a read timeout at some point. This basically means that you cannot use a closed stream to signal the end of the data stream, so instead you have to write the data length to the stream first, and then the data. The receiving side can then read the data length first, and then read the actual data accordingly. Which is not bad, it just sucks when you've spent so many hours debugging that read timeout.

The gain in productivity is almost infinite...