O2 Send your mobile number to every website you visit!

chris    Blog, Code    

Today in my RSS feed an interesting article appeared, stating that O2 send your mobile number to every webpage you visit. I couldn’t believe this so decided to spend 5 minutes confirming that they do and it’s stupidly easy for anyone to get your number to spam you.

A bit of background.

When you send a request to a website for a page you send along a number of headers stating things like what device you are on, what screen size you have and what features your browser support. This means web pages can change to show you less images for your mobile, some even change the formatting to make it easier to read, all very good stuff.

However this news reveals that O2 add an extra header in that tells the website what your mobile number is! Think about how many websites you visit, think about how many people could grab your mobile number from this! I spent all of 30 seconds writing the following script to dump out the http headers to the screen to check this, here is the entire script:

<?php
   foreach($_SERVER as $header => $value){
     if(ereg('HTTP_(.+)',$header,$hp)){
       echo "<li>$header = $value</li>";
	 }
	}
 ?>

You can see this script running here: http://bite-code.com/scripts/dumpHeaders.php

Just make sure you visit over 3G not WiFi and you will see your mobile number listed there in the headers! It’s called HTTP_X_UP_CALLING_LINE_ID.

Don’t worry I don’t record any headers or log this information, but other websites could!

This probably explains how spammers keep getting your mobile number. I suggest you call O2 immediately and complain, I know I will.

Full credit for the original discovery and info is here: http://t.co/7IOw7gqI

Loading the OSGi Web Console into Glassfish

chris    Code     glassfish, j2ee, osgi

For a while now Glassfish has been built on OSGi, which is a fantastic win for a lot of developers working with enterprise java. Want to include modular OSGi software in your stack without having to install new servers and runtimes? No problem to those of you running Glassfish!

Here ill go through the process of starting the OSGi web console (which is like the normal admin screens, but for OSGi). Soon ill be posting a few guides on setting up a stats reporting system which will allow you to easily log events from within your code into a Graphite server.

Setup

Are your running version 3 of glassfish? Then your all done!

Unfortunately those of you on older versions of Glassfish are out of luck, this is V3 only.

Deploying

You can deploy bundles into Glassfish in 4 ways, these are via asadmin commands, osgi remote shell commands, auto deploy file locations and the web console.

Ideally we want to only use the web console to make life easy, but to set that up we need to deploy the web console itself. I would note that for more involved work, CI servers, scripted deployment, etc that command line and auto deploy do come into their own, but for our simple needs right now the web console is a great start.

Glassfish will automatically deploy any bundles it can find in the location:

<install path>/glassfish/domains/<your domain>/autodeploy/bundles/

All you need to do is drop your bundles in there and Glassfish will deploy them, if you remove them they get undeployed and you can even do this with the server running if you want. Therefore to setup the web console you just need to get the latest full web console jar from the Felix downloads page and drop it in here.

Thats it, if you check the logs you should see it installed and was started!

Console

Finally all thats left to do is log into the Glassfish web console, go to your server at the following address:

http://<hostname>:8080/osgi/system/console

You will need to login, the default user and pass is admin/admin and you should end up at the following screen.

Next up, will be creating some OSGi bundles that will allow you to extend Glassfish…

dOSGi – The network is the computer

chris    Code     dosgi, osgi

OSGi is fast becoming the de-facto way to create modular java applications, however when running large scale enterprise applications often the bottleneck becomes the computer itself. Usually the culprits are RAM & CPU, eventually you hit a limit and things just won’t go any faster.

So whats the point in modular code if each computer works in isolation? Yes you may have very flexible software, well design, decoupled and all those other things, but if your not solving issues for your customers then what does it really matter? Remember real artists ship!

dOSGi aims to take all those cool things that OSGi provides an easy way to share them out over your computers, hence the d for distributed. The idea of deploying components and wiring them up as you want, independent of what computer they were run on really does sound like the future, so it was time to boot up eclipse and set myself a challenge. To do a basic evaluation of the performance aspects of dOSGi.

dOSGi ships with a couple of ways to make your computers talk to each other, but the most suited for general comm’s without too much hassle is the web service implementation from CXF. So I decided to see if I can get distributed components talking with this system, and see how fast it is.

The App

The application itself formed a very simple OSGi app, my service has one method to log a report event, this method just prints some information to standard out. A separate project holds the interface definition for my service and 2 more projects are setup to place calls to the service locally and remotely over web services.

Lesson 1

dOSGi is built around declarative services within OSGi, my previous work had been with Spring DM so it was a real joy to see how easy declarative services are. I may see how I can wire things with Spring DM at some point, but for now be prepared to create your xml files for wiring things up in your OSGI-INF folder.

Wiring up a local service was easy, as with most OSGi you just declare its interface, implementation and your done, like this:

<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="Reporting Service">
  <implementation class="com.chriswhitcombe.reporting.impl.ReportingServiceImpl"/>
  <service>
     <provide interface="com.chriswhitcombe.reporting.ReportingService"/>
  </service>
</scr:component>

What I wasn’t prepared for would how easy it would be to turn my local service into a remotely accessible web service, a few property key’s and its done…

<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="Reporting Service">
  <implementation class="com.chriswhitcombe.reporting.impl.ReportingServiceImpl"/>

  <property name="service.exported.interfaces" value="*" />
  <property name="service.exported.configs" value="org.apache.cxf.ws" />
  <property name="org.apache.cxf.ws.address" value="http://localhost:9000/reporting" />
  <service>
     <provide interface="com.chriswhitcombe.reporting.ReportingService"/>
  </service>

</scr:component>

Lesson 2

Unless you setup your projects properly, your in for a lot of frustration. The errors coming out we’re not helpful so here’s a list of the 2 important things you need to remember to do:

1. Include the equinox DS libraries and dependancies, its simple but forgetting to do this means no services get hooked up. However you only find that out when you make a call and get a null pointer.
2. If your building, include your OSGI-INF folder in your build.properties, if you forget this all your DS wiring will be missing from you jar file

Lesson 3

Invoking services is just as easy as declaring them! You can declare to insert services in your standard DS wiring files, however thanks to an extra file stored at OSGI-INF/remote-service/remote-services.xml you can re-route the calls to remote services.

<?xml version="1.0" encoding="UTF-8"?>
<endpoint-descriptions xmlns="http://www.osgi.org/xmlns/rsa/v1.0.0">
  <endpoint-description>
    <property name="objectClass">
      <array>
        <value>com.chriswhitcombe.reporting.ReportingService</value>
      </array>
    </property>
    <property name="endpoint.id">http://localhost:9000/reporting</property>
    <property name="service.imported.configs">org.apache.cxf.ws</property>
  </endpoint-description>
</endpoint-descriptions>

Performace

Now, in all honesty, i’ve got a lot of work left on performance analysis before I can make a full comment on how this all works. The case I have picked out is probably one of the most simple as theres no complex objects, large sizes of objects, exceptions, etc. But it does serve as a start point to answer the question of if dOSGi looks like it could be a workable distributed systems architecture…

My method of testing the reporting system was to run 1000 calls to the reportEvent() function both locally within the same JVM and remotely from another JVM. This serves to test the remote invocation and serialisation functionality without including things like network IO etc.

Note: My actual test function places a call, waits 10ms and then repeats. This was to simulate more realistic call patterns and avoid unfair bias towards the local calls, if for example the network port needs to flush etc. It seemed worthless seeing what a service was like when being DDOS’d!

The results

1000 Local Calls – 10901ms

1000 Remote Calls – 13379ms

If you trim the sleep’s from those calls you can see that the remote calls are around 4 times slower than local invocation.

Summary

This is not a scientific test, this is a way for me to see if this technology could be a future building block of modular, distributed systems. I was expecting the time it takes to serialise to xml and back to be a lot worse, but I have to say a 4 times drop in speed is not bad.

As I stated before, when building distributed systems, often you are doing this to avoid problems like CPU, RAM limits so you can accept some performance loss as it may be better than the alternative of waiting for going to disc. For applications that require the highest of performance there are far better ways to solve such problems, but then again you probably don’t need highly modular solutions.

In summary I am really surprised with the performance characteristics of dOSGI, the simplicity with which it works and just how fast you can develop very complicated systems (but maintain tidy modular code). Apache has a binary XML format as well within CXF so hopefully in the future that drops in to give performance gains, in the meantime I think I need to build a more complex solution and test out on some cloud servers.