Discussions

News: A High Performance Options Exchange Gateway built on JavaSpaces

  1. A few weeks ago we visited an existing client of ours to talk about some new ideas for replacing a functioning options exchange gateway with something new. The existing system worked fine, it was written in C# and ran on .NET, sitting on an 8 CPU box running one of MicrosoftÂ’s platforms.

    So why change it? A number of reasons were stated but above all was that they wanted something both scalable to extend to other exchanges and at the same time easier to maintain as the markets, data and business change over the coming months.

    This could have been done in a number of ways, C++, C#, J2EE etc., we thought a grid solution build on JavaSpaces might be a good option and thought up a plan. Using GigaSpaces' JavaSpace implementtion and C24's Integration Objects (now free) this is what happened...

    http://www.c24.biz/download/Options-Exchange-on-JavaSpaces.pdf

    Threaded Messages (32)

  2. no posts yet, so I'll say it[ Go to top ]

    thanks for writing up the article and describing the approach. it was well written and provided food for thought.
  3. no posts yet, so I'll say it[ Go to top ]

    Thanks Peter, I guess the masses are pondering their responses. If no one's interested it's not very inspiring to write up any of the other clients though. :-(

    I just felt it was time for a change from the usual AO, AOP, EJB, DI and Java vs. .NET stuff.

    -John-
  4. RE: no posts yet, so I'll say it[ Go to top ]

    I for one would love to read about more cases, since I think about performance and scalability obsessively. that's probably why I contribute to jmeter. probably should get a life. I've been exploring and researching distributed systems for the last several years. It sounds like GigaSpaces shares some similarities with JxTA. It's nice to see all the research in distributed indexes and distributed memory by Berkeley, MIT, and other universities has produced some solid products.
  5. RE: no posts yet, so I'll say it[ Go to top ]

    I think about performance and scalability obsessively
    I've always wondered who reads the Viagra spam!
    probably should get a life
    You said it! :-)

    JxTA complements Jini nicely, it's rather like comparing RMI and SOAP, they can solve the same problems but there are clearly places where one is a better fit than the other. If we had to communicate outside of the server environment of the clients we'd probably use JxTA.

    -John-
  6. HyperSpace jump from EJB...![ Go to top ]

    Looks like an excellent way of building a ESB (Enterprise Service Bus).

    Very nice articule John. Most of real distributed problems are nicely handled by this architecture, i'd wish i have read before about Spaces.

    thanks a lot!

    Fernando Racca
  7. HyperSpace jump from EJB...![ Go to top ]

    You are absolutely right, this could be a real ESB solution, wrap the services as JavaSpace workers and then expose them through JXTA. It is a far purer solution than the typical J2EE effort. Jini still uses RMI and naming services but it's done in a much more flexible way, there is no single point of failure unlike a simple rmiregistry or J2EE JNDI. Even the JavaSpaces themselves are services in Jini, it's almost like Smalltalk, a very pure implementation! Another thing is that you're not restricted to the container contracts and component restrictions. We can wrap a C++ routine in JavaSpaces or talk to .NET without having to write complex J2EE CAs or use crap WebServices. Macromedia used Jini to cluster their J2EE containers, there's no reason why an entire server can't be a Jini services. This was where I was going with James Strachan the other day over a few beers, put the JMS destination into a JavaSpace and you've got something amazingly powerful, it's great stuff to play with.

    -John-
  8. HyperSpace jump from EJB...![ Go to top ]

    You mention your work with jstrachan, would this not have been possible with the activespaces project? Or is JMS really the limitation?

    Also, you are dealing with alrge numbers of messages, could this system be adapted to replicate http session data too? Could machines join in a cluster and publish the changes to the cluster in an efficient manner? Would it be more efficient than the standard multicast solution that most app server vendors employ?

    Soryy if this stuff is obvious, but I haven't had much time to read up on this stuff yet ;). One last question, how successful was Jini for clustering the MM application server? I remember Rikard Oberg mentioning that he researched Jini originally for JBoss but decided against it at the time.
  9. HyperSpace jump from EJB...![ Go to top ]

    You mention your work with jstrachan, would this not have been possible with the activespaces project? Or is JMS really the limitation?
    If you read James's original posting you'll see that it was me who inspired James into ActiveSpaces, both of us together and a few beers of course.

    There is nothing limiting JMS from being integrated with JavaSpaces, especially something like James's ActiveMQ but we were looking for direction, there's no point in working on ActiveSpaces if no one needs it or it doesn't solve any problems.

    JMS and JavaSpaces are similar, in fact you can implement most of the JMS features with JavaSpaces, it only gets a little difficult when you get to the message selectors. JavaSpaces are designed to distribute and find services not data. It would be equally difficult to use JMS to select messages based on the services they implement. Both do similar jobs and overlap in a few places but they are designed for different purposes and should be used accordingly.
    could this system be adapted to replicate http session data too?
    Yes, as I said in a posting above Macromedia did just this. I'll let the Jini vendors answer this on in more detail.
    One last question, how successful was Jini for clustering the MM application server?
    I can't comment on the success of MM, it's obviously not had the success of BEA but I'm sure it wasn't their clustering choices that let them down. It would be interesting to know why JBoss people decided not to go for Jini, perhaps there just wasn't enough AO in it. :-)

    -John-
  10. session replication[ Go to top ]

    Also, you are dealing with alrge numbers of messages, could this system be adapted to replicate http session data too? Could machines join in a cluster and publish the changes to the cluster in an efficient manner? Would it be more efficient than the standard multicast solution that most app server vendors employ?
    Multicast is ideal for replication of data, but you don't want to replicate sessions to all machines in a cluster .. that is very non-scalable. Also, I don't think "most" app server vendors employ that; I know of only one that does (or at least used to do) it that way.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  11. HyperSpace jump from EJB...![ Go to top ]

    could this system be adapted to replicate http session data too?

    GigaSpaces provides Built in HTTP Session sharing using our Distributed Caching API.
    See:
    a href="Using" rel="nofollow">http://www.gigaspaces.com/docs/doc/the_cache_api.htm">Using the cache from a web application</a>
    and our <GigaSpaces root>\examples\session-space demo.

    Shay
  12. Back to earth ..[ Go to top ]

    .. there is no single point of failure unlike [..] J2EE JNDI.
    There is no single point of failure (SPOF) in JNDI .. it's an API that is typically implemented in a replicated manner for clustered J2EE systems. I know that WebSphere and WebLogic for example don't suffer from SPOFs with JNDI. I'd assume even the open source stuff (JBoss, Geronimo, etc.) doesn't suffer from JNDI SPOFs. Do you know of any contemporary servers that do? ;-)
    Another thing is that you're not restricted to the container contracts and component restrictions. We can wrap a C++ routine in JavaSpaces or talk to .NET without having to write complex J2EE CAs or use crap WebServices.
    You can do the same in J2EE; the J2EE contracts just tell you how to write components that will deploy to _any_ certified container, even one that has been "locked down" for security or hosting reasons .. it's a "guaranteed portability" issue, not a technical one.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  13. Back to earth ..[ Go to top ]

    Cameron old chap,
        I know it wouldn't take you long to post something here. I have absolutely no doubt that Coherence could have done an equally good job, it's a great product. I tried to make it clear that this was just one of many possible solutions, it used largely off the shelf products and took just a few days to complete. If I had sat down with Rob (your Rob) and used Coherence I'm sure I'd have been writing about the wonderful Coherence/C24 solution we implemented. As it happened it was GigaSpaces, they were great to work with and provided a great product and solution.

    I wish you and the GigaSpaces guys got on better, because you're both such a great bunch of guys to work with. Not saying that you don't get on but you have such different technologies there is really no reason why you couldn't work together on such projects. I think part of the problem is GigaSpaces attempt to provide solutions outside of what JavaSpaces were really designed for, i.e. JMS, database caching etc. Their caching solution is good but it does compete in a space that doesn't make friends with companies like Tangosol.

    Anyway, as they say, there are no friends in business! Have have to disagree though.

    "Peace",

    -John-
  14. Gigaspaces sounds cool. I went to gigaspaces' web site but couldn't find a price; not a good sign. What open source Javaspaces implementations have people used successfully for high-volume systems (even if they don't do everything Gigaspaces does)?
  15. Gigaspaces sounds cool. I went to gigaspaces' web site but couldn't find a price; not a good sign. What open source Javaspaces implementations have people used successfully for high-volume systems (even if they don't do everything Gigaspaces does)?
    Can you sketch out what you'd consider to be a high-volume system?

    I've seen several different kinds which come with their own forms of strain. Some are lots of small objects written and taken rapidly whilst others are large numbers of writes followed by trickling of takes and updates and then there are those that write large objects at relatively low rates.

    So you end up with some systems where concurrency, throughput etc are important and others that need to support "graceful degradation" via swapping etc to manage large data requirements.
  16. Chris -- We are happy to provide pricing information to anyone who contacts us (and do so every day).

    For various reasons, enterprise software companies (not just solution providers) rarely publish their prices on the web.

    Open source solutions work well when the underlying technology is mature, widely used in the industry and there are many COMMERCIAL organizations that can support them. In my experience, rarely will enterprises opt for open source versions of innovative technologies.

    Regards,
    Geva Perry
    GigaSpaces
  17. For various reasons, enterprise software companies (not just solution providers) rarely publish their prices on the web.
    That doesn't sound right .. even Oracle and IBM publish list prices. Heck, our pricing has been available online since our 1.0 release .. see http://www.tangosol.com/coherence.jsp.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  18. GigaSpaces isn't free although I believe they are for academic usage (don't quote me on that though!!!). It comes down to the usual option of a good free version (Blitz) or a good "non-free" version (GigaSpaces). To the nieve the obvious choice is Blitz but sadly the real world doesn't just run on freeware. GigaSpaces' customers pay for it for the support, they have people in several countries and a large head office that can provide round the clock support and people on site within hours. Dan (Mr. Blitz) has a great product, it is undoubtedly the best open source version and definitely one of the best all round JavaSpaces implementations that exists. Although it's open source and free it is still funded by some nice people at Paremus who charge real money for their products.

    Companies that don't quote prices on their web sites are normally selling solutions rather than off the shelf products, it's very difficult to price something that might be used for searching for DNA matches in a cancer charity at one end and a high performance exchange gateway at the other end. Two very different clients using different features and having different support requirements. Chris, if you want to know the price, send GigaSpaces and email and tell them what you want to do with it and I'm sure they'll give you a price. You can of course download it now and use an unrestricted eval for your prototype.

    To answer your question Blitz is the best open source option.

    -John-
  19. Dan (Mr. Blitz) has a great product, it is undoubtedly the best open source version and definitely one of the best all round JavaSpaces implementations that exists. Although it's open source and free it is still funded by some nice people at Paremus who charge real money for their products.
    Thanks for the support John, just wanted to clarify my relationship with Paremus a bit. Blitz is largely developed on my own time however, I am consulting to Paremus, helping them develop some JINI/JavaSpaces based product offerings. They pay me for that work and, in addition, very kindly allow me to spend some of my work time developing Blitz. Paremus also has access to big iron and various resources which they make available to me for no charge.

    I am very grateful for their support and undoubtedly certain aspects of Blitz have benefited greatly as a result. However, Blitz has also benefited from the support of a number of others including Nigel Warren, Phil Bishop (at Inca X - he did most of the development of Blitz's installer and the Dashboard GUI) and a number of others in the JINI/JavaSpaces community (who've contributed ideas, configuration examples, documentation tweaks, tests and bug reports).

    Dan.
  20. HyperSpace jump from EJB...![ Go to top ]

    Jini still uses RMI and naming services but it's done in a much more flexible way, there is no single point of failure unlike a simple rmiregistry or J2EE JNDI.
    I'm skeptical of the suggestion that Jini is more reliable. Isn't the JavaSpace host a single point of system failure? A Jini registry lacks replication. A JXTA registry is replicated.
  21. JavaSpace and SPOFs[ Go to top ]

    I'm skeptical of the suggestion that Jini is more reliable. Isn't the JavaSpace host a single point of system failure? A Jini registry lacks replication. A JXTA registry is replicated.
    JavaSpaces, like JNDI, is just an API .. it can be implemented as a SPOF, or it can be implemented on top of a HA clustered datastore (e.g. Coherence.) I don't know what capabilities the commercial spaces products offer, but I believe that they both claim to eliminate SPOFs.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  22. HyperSpace jump from EJB...![ Go to top ]

    I'm skeptical of the suggestion that Jini is more reliable. Isn't the JavaSpace host a single point of system failure? A Jini registry lacks replication. A JXTA registry is replicated.
    As Cameron rightly points out, JavaSpaces is only an API as is the JINI "registry" and thus they are amenable to all the usual clustering/replication techniques.

    However, at least in the case of lookup/registry you get replication for free without any effort and you don't need a clustered registry implementation to do it. Typically, most deployments run more than one instance of the JINI registry and, courtesy of the standard API's, replication of lookup information is handled by default with no intervention required on the part of the service developer. You want more replication, just deploy another registry instance. There is no requirement for a single centralized registry unless you really want it!

    Whilst we're clearing up stuff - I'd also like to tackle the JINI is dependent on RMI issue. JINI's API definitions feature RemoteExceptions but no other part of RMI is exposed. Thus any transport that can provide transport and throw RemoteExceptions appropriately is sufficient - it needn't be RMI.

    The example implementation shipped as part of the JINI development kit *is* RMI-based but it didn't *need* to be. Note also that SUN do not currently view their example implementation as a *reference* implementation (they get quite upset when people refer to it that way :).

    Hope the above is useful,

    Dan.
  23. more cases[ Go to top ]

    I for one would love to read about more cases, since I think about performance and scalability obsessively.
    A few months back, during the Jini community meeting, several nice cases were presented. you should still be able to find the slides at
    http://www.jini.org/meetings/seventh/J7Program_T.html

    however, I find John's article more clearly explained (of cos, full text article gives more details than slides).
    It's nice to see all the research in distributed indexes and distributed memory by Berkeley, MIT, and other universities has produced some solid products.
    do you have any specific examples of where in what products these research have been applied?
  24. I have no proof :)[ Go to top ]

    I have absolutely no proof the people at Gigaspaces, Oracle, Sun, or JxTA take time to read the latest peer review journals on distributed processing. I naively assume they are actively reading and keeping up with research. I can't find the good references right now, since I have them bookmarked at home. ACMQueue usually has tons of articles in this domain.

    http://www.cs.berkeley.edu/Research/Projects/
    http://www-2.cs.cmu.edu/~scandal/research-groups.html
    http://www.cs.umd.edu/~keleher/bib/dsmbiblio/dsmbiblio.html
    http://www.globus.org/

    I would find it hard to believe that people working with distributed and parallel systems do not keep up with the latest research and peer review journals. Systems like beowolf, globus, and Oracle's distributed tables all build on research in this field. I suppose someone could magically build a grid without having read a single paper on topic.
  25. done it 3 years ago[ Go to top ]

    We done the same thing 3 years old. The management didn't want to use JavaSpace so we use RMI instead (although we have an implementation using JavaSpace working). As far as I remembered the Feed handler was the hardest to write. A lot of exchanges throttles the feed, so you need to dynamically changes the feed rate depending on the conditions of the feed.

    eddie
  26. done it 3 years ago[ Go to top ]

    I've seen similar architectures using JavaSpaces, it's re-assuring to know we're attacking the similar problems with the same solution. It's amazing how often we've seen good solutions thrown away because people don't understand JavaSpaces. They then go off and write them in C++, CORBA or J2EE etc. only to come back a few years later because they've hit the scalability wall.

    I presume your RMI solution was very based on your JavaSpace architecture, it's a rather sneaky way of implementing the same thing by almost writing the JavaSpaces yourself through RMI. :-)

    -John-
  27. Nice paper[ Go to top ]

    Even though I don't currently have requirements for which this solution would be appropriate, I do appreciate being able to read (and thus learn) from those that have real world experiences. Thank you John for writing this paper. It was a very interesting read.
  28. Nice paper[ Go to top ]

    Thank you, you're welcome! Part of my goal was not just to show what we're up to but to try to educate a little at the same time.
    I'm glad you enjoyed it.

    -John-
  29. Of block writes and takes[ Go to top ]

    There's a reference in the paper to the use of block operations which are not part of the JavaSpaces standard but implemented by GigaSpaces. Whilst they currently aren't standardized there is work underway to revise the spec such that it does provide these capabilities (although they may not be exactly the same as those offered by GigaSpaces).

    It will likely be specified as an optional extension (along with an iterator function for reading all Entry's that match a collection of templates).

    You can find the current spec for block operations here:

    http://archives.java.sun.com/cgi-bin/wa?A2=ind0406&L=javaspaces-users&F=&S=&P=25794

    Dan.
  30. Of block writes and takes[ Go to top ]

    Thanks for your comments Dan, as you say we did you some optimisations that are not part of the Jini spec but I don't think we went too far off the line.

    If anything I think Blitz is closer to an open source reference than Sun's, at least it's easy to get running. Sun's OutRigger is a pain in the back side to say the leaset and if I were Sun I don't think I'd want to "own" it eather. They need to do some serious work to make it useable to the average Java programmer.

    -John-
  31. Of block writes and takes[ Go to top ]

    Dan,
    Gigaspaces came with the block operations (we call it batch operations) 2 years ago since we have identified the requirement after working with prospects and customers around the world. We are happy the JavaSpaces community understood this important requirement and agreed to add these capabilities into the spec. We will soon adjust our API to be aligned with the official block operations API.
    Since we see ourselves the leading company with JavaSpaces implementation and build all our Grid Server on top of JavaSpaces to include JMS API , JDBC API , Map API , JCA API we have added few additional capabilities into our JavaSpaces layer. These includes: Full FIFO support to allow FIFO based take operations , Notifications for Take, update and Lease expiration and Transient and persistent entries. These and more will be revealed as part of GigaSpaces 4.0.
    A 4.0 beta will be available for download soon. Please contact me to have access to this beta.

     
    Best Regards,
            Shay
    ----------------------------------------------------
    Shay Hassidim
    Product Manager, GigaSpaces Technologies
    Email: shay at gigaspaces dot com
    Website: www.gigaspaces.com
  32. Paper is off line[ Go to top ]

    I'm afraid the white paper is off line for a day or so at the request of our client. It will be back up, slightly re-worded, hopefully before the end of the week.

    Sorry about that!!

    -John-
  33. Paper is back on-line[ Go to top ]

    Sorry for anyone that tried to read it over the last few days, it's back up again.

    -John-