SIMON Main Wiki Page

Welcome to SIMON

Welcome to the SIMON developer wiki. Here you will find all important information and files to get your project - powered by SIMON - running.

I always recommend to read all from top to bottom. But If you are in a hurry: Select the topic you're interested in from the table of contents on the top right.

What is SIMON?

SIMON is a dual licensed Java(tm) API, that performs the object-oriented equivalent of remote procedure call. With SIMON you are able to use Java objects, which are located in another JVM on the current machine, on another machine in the local network or even on a servermachine somewhere on the internet.

Who uses SIMON?

Wir entwickeln eine plattformunabhängige Kanzleisoftware für Rechtanwälte. Um die Performance im Netzwerk zu erhöhen haben wir alle clientseitigen Zugriffe über ein Interface abgekoppelt und einen ApplicationServer entwickelt, der einen Teil der Geschäftslogik auf dem Server belässt (dafür benötigen wir SIMON).

... In einem ersten Schritt haben wir eine so genannte HotSeat-Version implementiert, welche das Spielen an einem Rechner ermöglichte. Für die spätere Client-/Server-Trennung haben wir einige Testszenarien mit RMI entwickelt, die wir allerdings frustriert verwerfen mussten. Mit SIMON war das anders! Wir haben innerhalb von einer halben Stunde einen Prototypen entwickelt, an welchem wir die SIMON-API kennenlernen und im Anschluss diese Erfahrung in das eigentliche Projekt übernehmen konnten. Mit Hilfe von SIMON war es uns möglich die gesamte Client-/Server-Trennung des Spiels innerhalb von zwei Tagen umzusetzen.

Wir haben die Kommunikation unserer Client - Komponenten mit den Servern von RMI zu SIMON portiert um damit die vielen Probleme, die beim Einsatz von RMI bei NAT, insbesondere Client - Callbacks, entstehen zu umgehen. Die Migration war innerhalb kurzer Zeit problemlos abgeschlossen.

Wollte einfach mal sagen, dass dein Projekt genial ist !
Nachdem ich einige Zeit in das Entwickeln eines RMI Programms gesteckt habe musste ich feststellen das RMI einfach nicht in der Lage ist mit Rechnern hinter einem Router zu kommunizieren. Bzw. es nur über Umwege halbwegs lauffähig wird.
Dein Projekt hat sozusagen meins gerettet :-)
Und das ganze hat nicht mal 20 min gedauert von RMI nach SIMON zu porten, echt klasse!
Danke !

Im Projekt eines Medien-Centers übernahm SIMON mit Bravour die bidrektionale Client-Server-Kommunikation (auch über das Internet) und den schnellen Datei-Transfer. Ein besonderer Pluspunkt bei der Nutzung der SIMON-API war der tolle Support. Durch den eingebauten Thread-Pool war die Handhabung mehrerer Clients völlig von der Applikationslogik entkoppelt.

... auch wir möchten uns bedanken für das großartige Projekt SIMON.

Projekt Einsatz Nr. 1)
Für einen Großkunden im Bereich Fahrzeugmarkt, wird SIMON als Übertragungsprotokoll zwischen mehreren Client Systemen und dem Mainframe eingesetzt. Alle Fahrzeug Anfragen werden von den Clients an den Master-Server propagiert, bis jetzt ohne Ausfall.

Projekt Einsatz Nr. 2)
Im zweiten Projekt verwenden wir SIMON in unserer eigenen Applikation. Um unseren Kunden und dessen Anforderungen an ein individuelles Java-basierendes Webhosting gerecht werden zu können, wurde ein auf SIMON basierendes Transaktionsgesteuertes Verwaltungssystem für das eigens entwickelte Hosting-Projekt entwickelt.

Die Applikation schafft dank SIMON tausende Jobs in wenigen Sekunden, die Konfiguration und somit die Sicherstellung zur Einhaltung unserer Security Policy wurde Dank SIMON mehr als vereinfacht. SSL konnte anhand der Beispiele schnell umgesetzt werden, dadurch verhalf SIMON uns auf die wesentlichen Dinge in der Entwicklung zu konzentrieren.

Wir können nur sagen, weiter so!

I am going to use it as an RMI replacement in an existing project. A client server CRUD app.

Einsatz im firmeneigenen ERP System

If you want to be added to the list (or removed), please drop me a mail: info[at]root1.de

Targets

Oracle's (formerly Sun's) JRE/JDK already contains a technique for using remote objects. It's called RMI. Today, this implementation is really old but widely used in many (enterprise)applications. It works quite well, but it has some disadvantages that (partly) where not present in the early days of RMI: It's not that easy to use as it could be, and you run into troubles if you use it in a non LAN environment (say: the Internet ;-) ). So the intention of SIMON development was to provide an API which is small, flexible, really easy to use and integrates seamless into more complex network environments. You'd say that SIMON is the RMI alternative for communicating via Internet.

Comparison to RMI

SIMON solves most of the issues RMI users complain about. Here is a comparison that shows the top most issues comparing Oracle's RMI and SIMON.

RMI SIMON
I/O technology Old Java IO implementation. Apache MINA Framework which uses Java N(ew)IO.
Transparent network socket usage? No Yes
No. of used socket connections between client and server? At least one At most one
No. of used threads on server side? Unknown. It depends among other things on the number of connected clients. It's not under your control. A few. It depends on the used thread pool settings in the filter chain. You can serve, i.e. 1000 clients with only 50 threads. It's totally up to you.
Firewall/Router friendly? Yes, as far as no callbacks are used. Yes
Connection via web proxy possible? Only via HTTP tunneling. This results in a very slow connection Yes, if proxy supports the "CONNECT" command. For security, "basic authentication" is supported
Secure communication with SSL? Yes, with some extra effort Yes
Protocol replaceable with own implementation? No Yes
Performant file/data transfers No Yes
Server Discovery No Yes

Features

  • Remote Procedure Call: client can call methods on server, server can call methods on client (callback)
  • Extremely scalable thanks to Java NIO and the use of thread pooling mechanism
  • Proxy support: Let a client connect f.i. via a company proxy to your SIMON server
  • SSL support: strong communication encryption with SSL
  • Transparency: SIMON uses only one bi-directional socket connection between server and client, even if you use more than one remote object and callbacks
  • Exchangeable protocol: You are not happy with the protocol SIMON uses? Then go ahead and create your own...
  • Connection loss detection: Detect a broken connection in less time
  • Connection statistics: Know at any time how many messages/bytes are sent/received
  • RawDataChannel: Transfer raw data from client to server (and vice versa) without time consuming reflection and serialization overhead
  • PublishService: Find SIMON servers automatically on a local LAN
  • Custom Invoke Timeout (1.2.x)

Why SIMON is better than ....

... RMI for internet applications???

As already mentioned above, RMI has problems in modern applications that communicate not only via LAN, but also via internet. On the internet we have obstacles like firewalls and routers. And it turned out that RMI has problems with that. Let me explain why. Have at look at the following figure:

As you can see, RMI uses more than one connection to call methods on both sides. The bad thing is that RMI by default opens an anonymous port on the client side which is used by the server to call methods on the client. With a Custom Socket Factory you can specify a port for this kind of callbacks. But then you still have the problem that the server's outgoing connection must pass the client's firewall or router.

A workaround would be, not to use callbacks and use a polling mechanism at the client side. But think of hundrets of clients polling all the time. Not a "good" solution.

Another solution would be a kind of blocking listener: The client calls a "listen" method on the server. The server blocks this call until there is some data to poll for the "listener".
This works, but is also not a simple and good solution. You need to have additional threads handling the listener and the blocking mechanism etc.

So let's have a look at how SIMON works:

There is only one connection between client and server which is established by the client. It is used for bi-directional method calling. You only have to allow the SIMON server port on the server's firewall or enable portforwarding on the server's router. That's all.

How it works

SIMON ist not just a copy of RMI. SIMON is doing many things different. At least internal. This is to give you an idea on what's going on internally...

  • SIMON uses TCP to establish the connection between the client and the server
  • This TCP connection is a statefull, permanent connection
  • A client "opens" a connection to a server using the "lookup()" methods
  • A client must "close" the connection by calling "release()" after it has finished using the remoteobject
  • SIMON reuses existing connections. Let's say you want to use two remote objects from one and the same server. Instead of opening two connections, one for each remote object, SIMON opens the first connection with the first object, and reuses the already existing connection for the second object. This does not have any negative impact on the performance. It's the other way around: You save the time that is required to open the connection as well as the additional socket-resource. Also on server side there does not need to be an additional socket and thus there is no additional effort for the socket selector.
  • The connection from client to server actually get's closed, when the last remoteobject that used this connection is released.
  • There is no automatic reconnect that brings a client back online after a connection interruption. This is due to the fact, that SIMON does not know anything about the context that exists between the client and the server. So reconnection and bringing back the last context has to be done on application level.

Performance

Test-Case 1 ("Stress"):

  • Servermachine: Intel Core i7 4x2,8Ghz, 8GB RAM, Windows 7 Ultimate 64bit
  • One single clientmachine: Intel Core2Duo 2x2,13Ghz, 4GB RAM, Ubuntu 10.10 AMD64
  • 100Mbit network via SOHO desktop-switch
  • Server provides simple remote object with method:
    • public void testMethod1(String aString, int aInt);
  • One testclient instance runs 50 threads, each calling testMethod1 with arguments "aString" and Integer.MAX_VALUE as fast as possible (forever-loop, no extra delay). SIMON is configured for cached thread pool
  • Server implementation simply discards the method arguments and returns

Test-Case 1 results:

  • ~7950 method invocations per second
  • Servermachine: ~20% CPU load over 4 out of 8 (CPU supports HT) cores
  • Clientmachine: ~60% CPU load over both cores
  • Client-to-Server network performance: ~1MiB/s TX, ~980kiB/s RX

Test-Case 2 ("Some more stress"):

  • Same setup as in Test-Case 1, but now with 2 testclient instances running on the client machine

Test-Case 2 result:

  • ~ 11700 method invocations per second in total on serverside
  • Servermachine: ~22% CPU load over 4 out of 8 (CPU supports HT) cores
  • Clientmachine: ~68% CPU load over both cores
  • Client-to-Server network performance: ~1.5MiB/s TX, ~1.3MiB/s RX

Test-Case 3 ("Some more real test ..."):

  • Same hardware setup as in Test-Case 1, but now with 20 testclient instances running on the client machine
  • Server provides simple remote object with method:
    • public void testMethod1(String aString, int aInt);
    • public Object testMethod2(ArrayList<Object> aList);
    • public boolean testMethod3(byte[] aByteArray);
  • Each testclient instance runs 50 threads, each calling one testmethod after another with 1sec delay -> should result in ~50 invocations per second per instance. As we have 20 instances this must result in 1000 invocations per second on server.
    • testMethod1 with arguments "aString" and Integer.MAX_VALUE
    • testMethod2 with a list of 100 POJOs containing an integer value, a String with length=3 and a long value
    • testMethod3 with a byte array with 512 bytes
  • Serverimplementation:
    • testMethod1: discard arguments and simply returns
    • testMethod2: return the first item in the list provided by client
    • testMethod3: return true if argument is not null and size>0, otherwise return false

Test-Case 3 results:

  • ~1000 method invocations per second in total on serverside, 50 on each testclient instance for each of the 20 instances
  • Servermachine: ~5% CPU load (yes, only five) over 4 out of 8 (CPU supports HT) cores
  • Clientmachine: ~30% CPU load over both cores
  • Client-to-Server network performance: ~1.1MiB/s TX, ~150kiB/s RX

Test-Case 4 ("Extreme load ..."):

  • Servermachine: Intel Core i7 4x2,8Ghz, 8GB RAM, Windows 7 Ultimate 64bit
  • 4 different client machines, running multiple testclient instances. In total, there are 13 testclient instances connected to server.
  • 100Mbit network via multiple switches (SOHO desktop-switchs + managed cisco switches)
  • Server provides simple remote object with method:
    • public void testMethod1(String aString, int aInt);
  • Each testclient instance runs 50 threads, each calling testMethod1 with arguments "aString" and Integer.MAX_VALUE as fast as possible (forever-loop, no extra delay). So in total we have 650 (!!!) threads (13*50) distributed over 4 machines calling methods on the server. SIMON is configured for thread pool with 10 worker threads
  • Server implementation simply discards the method arguments and returns

Test-Case 4 results:

  • ~37900 (!!!) method invocations per second in total on serverside. That's 0.026ms per method invocation!
  • Servermachine: ~60% CPU load in total
  • server side network performance: ~1.2MiB/s TX, ~3MiB/s RX

Versioning

The SIMON version number consists out of three parts: X.Y.Z

X = Major version number. This indicates the "generation" of the project
Y = Minor version number. This increments f.i. if an feature is added.
Z = Patch/Bugfix release number.

Each version, which has an identical major/minor version combination is compatible to each other. For instance:

1.0.5 <-compatible-> 1.0.6
1.0.0 <-compatible-> 1.0.2
1.1.0 <-not-compatible-> 1.0.2
1.5.0 <-not-compatible-> 1.1.6

There also might be "sub-versions", like 1.0.0-RC1 or 1.5.0-BETA1 ... These are kind of "pre releases".

License

SIMON is dual-licensed and offers licenses for two distinct purposes - closed source and open source development.

If you want to use the GPL version, you'll have to put your own program under the GPL as well. This means you'll also have to release your source code along with your binary version, which may in turn be altered and re-released. If you choose the Commercial License instead, you're allowed to release your software without making the source public.

If you go for the GPL license, I would be glad about an donation:

Prices for Commercial License

I don't ask for millions, but SIMON is not free of charge for GPL incompatible use. The following price table applies to root1.de Library Commercial License as described above:

  • Developer License (for 1 developer): 99.- EUR
  • Team License (for 5 developers): 359.- EUR
  • Workgroup License (for 25 developers): 1599.- EUR
  • Enterprise License (for 100 developers): 5499.- EUR

For purchasing the commercial license, please get in contact with me -> info[at]root1.de

If you have the feeling that the price for the above mentioned licenses is inappropriate, please have a look at what OpenHUB calculates:

If you then still believe that the price is improper, please drop me a mail -> info[at]root1.de

How to purchase a commercial license

Send me an email at info[at]root1.de which answers the following questions:

  1. Which License do you want to order?
  2. Which SIMON version you want the license for?
  3. Which address (postal + email) should be noted on invoice?

If no questions are open from both sides, you will be provided with an invoice plus the current commercial license. As soon as the invoice payment is completed (my account received the money), the license is valid.

What about updates for commercial licensed SIMON?

If, for instance, you order a license for SIMON 1.0.0, you are permitted to use any SIMON 1.0.x version which has been released. Means: You order version 1.0.0 and can update to version 1.0.1, 1.0.2, 1.0.3, ... for free.
If you want to upgrade to a later version (i.e. 1.1.x, 1.2.x, 1.3.x, 2.1.x, ...), a paid upgrade is necessary. In this case, please get in contact with us: info[at]root1.de

Get SIMON

Sourcecode

Access the source code repository for this project in one of following ways:

  • Browse source code online to view this project's directory structure and files.
  • Check out source code with a Subversion client using the following svn command. svn checkout http://svn.root1.de/svn/simon/trunk simon

If you are new to Subversion, you may want to visit the Subversion Project website and read Version Control with Subversion.

Compile from Source

You can easily build the project by using Maven. But first, you have to have a working Maven Environment. If you are new to Maven, you may want to visit the Maven Project website for more details.

Binaries

If you don't want to build SIMON yourself you can download pre-compiled binaries. You can choose between the latest release and the latest development snapshot.

Release

Visit this link for downloading latest release:

Direct Download: http://dev.root1.de/projects/list_files/simon
Maven Repository: http://nexus.root1.de/content/repositories/releases/de/root1/simon/

Snapshot

Visit this link for downloading latest snapshot:
http://jenkins.root1.de/job/SIMON%20-%20trunk/lastStableBuild/de.root1$simon/

Maven Site, JavaDoc, ...

With each deployment of SIMON to the maven repository, also a project site is generated. The site contains f.i.

  • JavaDoc
  • Reports like test coverage
  • Dependency Information
  • ...

Please follow this link:

http://dev.root1.de/project-sites/simon/

Setup your project

Depending on your IDE, there are different steps for setup your project to work with SIMON:

Help

You need help on using SIMON? You do not know how to start? In this section you will find a first "hello world" sample and useful tips on how to do <whatever>, explained with simple codesnippets. And if you have a more complex question, do not hesitate to post in the support forum. Help is provided in english and german language.

Samples/Howtos

If you want to download sample code, you can checkout this sub-project from SVN: http://svn.root1.de/svn/simon/trunk/samples/
It contains a ready to use Maven SIMON sample project, containing several samples. If you don't want to use Maven, you can directly navigate to http://svn.root1.de/svn/simon/trunk/samples/src/main/java/de/root1/simon/samples/

UML

Outdated licenses

History

Date Log
2007/12 started SIMON development
2008/01/18 presented SIMON 0.1 alpha on www.java-forum.org
2008/02/11 SIMON is able to make use of SimonRemote interface instead of extending a existing SimonRemote class
2008/02/15 added callback functionality now works without problems
2008/06/25 started working on a Java NIO implementation to overcome the one-thread-per-client issue with the blocking-io of Java IO
2008/07/01 First NIO version is ready to be tested
2008/07/25 release of SIMON 0.1 beta, based on Java NIO with non-blocking-io. SIMON now scales a lot better than with standard Java IO
2008/08/01 SIMON 0.2 RC released. Several bugs fixed.
2008/10/15 SIMON 0.2 stable released. In the meantime investigated into Apache MINA framework.
2008/10/26 SIMON 0.3 alpha released. First MINA powered SIMON version!
2009/01/12 SIMON 0.3 beta released. It's getting stable now ...
2009/05/07 SIMON 0.3 RC1&2 released. There's some light at the end of the tunnel ...
2009/06/03 SIMON "mavenized". New version number 1.0.0-RC1 , based on 0.3 RC2
2010/02/01 SIMON 1.0.0 RC2 released
2010/02/01 SIMON 1.0.0 stable released. First stable SIMON version based on MINA and created by MAVEN2
2011/01/02 SIMON 1.1.0 stable released.
2011/03/15 SIMON 1.1.1 released.
2011/07/01 SIMON 1.1.2 released.
2012/04/20 IANA assigns port to SIMON. See: http://dev.root1.de/news/27
2012/05/10 SIMON 1.1.3 released.
2013/08/23 SIMON 1.1.4 released.
2015/06/15 SIMON 1.2.0 released.
2015/06/30 SIMON 1.2.1 released.
2016/03/08 SIMON 1.3.0 released.

Supporter

SIMON is supported by:

YourKit Java Profiler
YourKit is kindly supporting open source projects with its full-featured Java Profiler.
YourKit, LLC is creator of innovative and intelligent tools for profiling
Java and .NET applications. Take a look at YourKit's leading software products:
YourKit Java Profiler and YourKit .NET Profiler.

2_rmi_vs_simon_schema.png (33.6 KB) admin, 07/02/2009 11:38 AM

1_rmi_vs_simon_schema.png (42.2 KB) admin, 07/02/2009 11:41 AM