java based technologies to support parallel and distributed applications l.
Skip this Video
Loading SlideShow in 5 Seconds..
Java-based Technologies to Support Parallel and Distributed Applications PowerPoint Presentation
Download Presentation
Java-based Technologies to Support Parallel and Distributed Applications

Loading in 2 Seconds...

play fullscreen
1 / 75

Java-based Technologies to Support Parallel and Distributed Applications - PowerPoint PPT Presentation

  • Uploaded on

Java-based Technologies to Support Parallel and Distributed Applications Prof Mark Baker ACET, University of Reading Tel: +44 118 378 8615 E-mail: Web: Outline The pros and cons of Java. Problems developing Java applications.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Java-based Technologies to Support Parallel and Distributed Applications' - issac

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
java based technologies to support parallel and distributed applications

Java-based Technologies to Support Parallel and Distributed Applications

Prof Mark Baker

ACET, University of Reading Tel: +44 118 378 8615 E-mail:


  • The pros and cons of Java.
  • Problems developing Java applications.
  • Java and the Grid:
    • WS, REST and Web 2.0.
  • Some Java application development.
    • GridRM,
    • Tycho,
    • MPJ Express.
  • Some lessons learnt!
  • Conclusions.

the pros and cons of java
The pros and cons of Java
  • Object Oriented:
    • Java is a modern object-oriented language:
      • There are many popular object-oriented languages available today:
        • Some like Smalltalk and Java are designed from the beginning to be object-oriented,
        • Others, like C++, are partially object-oriented, and partially procedural.
      • In Java, almost every variable is an object of some type or another - even strings.
      • In C++, you can still overwrite the contents of data structures and objects, causing the application to crash,
      • Java prohibits direct access to memory contents, leading to a more robust system.

the pros and cons of java4
The pros and cons of Java
  • Portable:
    • Most programming languages are compiled and converted to machine code that executed only on one type of machine - typically produces fast native code.
    • Interpreted code often does not need to be compiled - it is translated as it is run, which can be quite slow, but often portable across different OSs and processor architectures.
    • Java uses both techniques - it is compiled into a platform-neutral machine code (bytecode) then an interpreter:
      • Either a Java Virtual Machine (JVM), a JIT (Just-In-Time) compiler, or an adaptive optimising engine such as HotSpot.
    • A couple of advantages:
      • The source code is protected from view and modification - only the bytecode needs to be made available to users.
      • Security mechanisms can scan bytecode for signs of modification or harmful code,
      • Means that Java code can be compiled once, and run on any machine and OS combination that supports a JVM - wonderful delegation of responsibility!

the pros and cons of java5
The pros and cons of Java
  • Multi-threaded
    • Some languages, like C/C++ have support for threads - Pthreads (POSIX 1003.1c standard), which is a separate library that you need to include and use - an after thought!
    • Many language do not have thread support, so you need to potentially create multiple-processes…
    • Java has support for multiple threads of execution built right into the language:
      • Thread support was designed into the language from the out start, simple, and commonly used in applications and applets.

the pros and cons of java6
The pros and cons of Java
  • Concurrency Control:
    • Java 1.5 has comprehensive support for general-purpose concurrent programming,
    • The support is partitioned into three packages:
      • java.util.concurrent - this provides various classes to support common concurrent programming paradigms, e.g., support for various queuing policies such as bounded buffers, sets and maps, thread pools etc,
      • java.util.concurrent.atomic - this provides support for lock-free thread-safe programming on simple variables such as atomic integers, atomic booleans, etc,
      • java.util.concurrent.locks - this provides a framework for various locking algorithms that augment the Java language mechanisms, e.g., read -write locks and condition variables.

the pros and cons of java7
The pros and cons of Java
  • Garbage collection:
    • Languages like C/C++ force programmers to allocate/deallocate memory for data and objects manually:
      • Adds complexity, but also causes another problem - memory leaks.
    • When Java applications create objects, the JVM allocates memory space for their storage:
      • When the object is no longer needed (no reference to the object exists), the memory space can be reclaimed for later use.
      • In Java, the programmer is free from such worries, as the JVM will perform automatic garbage collection of objects.

the pros and cons of java8
The pros and cons of Java
  • Memory Management:
    • There are no destructors in Java,
    • There is no "scope" of a variable per se, to indicate when the object’s lifetime is ended – the lifetime of an object is determined instead by the garbage collector,
    • finalize() method is called by the garbage collector and is supposed to be responsible only for releasing "resources”:
      • Such as open files, sockets, ports, URLs.
    • All objects in C++ will be (or rather, should be) destroyed, but not all objects in Java are garbage collected,
    • Java garbage collector can be changed, but no explicit control over object collection!

the pros and cons of java9
The pros and cons of Java
  • Security:
    • Security is not built into most traditional programming languages,
    • Security is a big issue with Java:
      • At the API level, there are strong security restrictions on file and network access for applets, as well as support for digital signatures to verify the integrity of downloaded code.
      • At the bytecode level, checks are made for obvious hacks, such as stack manipulation or invalid bytecode.
      • The weakest link in the chain is the Java Virtual Machine on which it is run - a JVM with known security weaknesses can be prone to attack:
        • Worth noting that while there have been a few identified weaknesses in JVMs, they are rare, and usually fixed quickly.

the pros and cons of java10
The pros and cons of Java
  • Network and "Internet" aware”:
    • In languages like C/C++, the networking code must be re-written for different operating systems, and is usually more complex,
    • Java was designed to be "Internet" aware, and to support network programming:
      • The Java API provides network support, from sockets and IP addresses, to URLs and HTTP,
      • It is easy to write network applications in Java, and the code is portable between platforms,
      • The networking support of Java saves a lot of time, and effort,
      • Java support for exotic network programming, such as remote-method invocation (RMI), SOAP, CORBA and Jini.

the pros and cons of java11
The pros and cons of Java
  • Arrays in Java:
    • Although they look similar, arrays have a very different structure and behaviour in Java than they do in C/C++,
    • There is a read-only length member (size of array) and run-time checking throws an exception if you go out of bounds,
    • In Java a two-dimensional array is an array of one-dimensional arrays,
    • Although we might expect that elements of rows are stored contiguously, one cannot depend upon the rows themselves being stored contiguously:
      • In fact, there is no way to check whether rows have been stored contiguously after they have been allocated.
      • The possible non-contiguity of rows implies that the effectiveness of block-oriented algorithms may be dependent on the particular implementation of the JVM as well as the current state of the memory manager.

the pros and cons of java12
The pros and cons of Java
  • The Floating-point Issue:
    • The fact that Java programs produce bitwise identical floating-point results in every JVM seems to be not only unrealisable in practice, but also inhibits efficient floating-point processing on some platforms.
    • For example, it precludes the efficient use of floating-point hardware on Intel processors which utilise extended precision in registers.

the pros and cons of java13
The pros and cons of Java
  • Exceptions:
    • Java exception handling is superior to those in C/C++:
      • No exception handling classes in C.
    • The C++ approach of calling a function at run-time when the wrong exception is thrown, where as in Java exception specifications are checked and enforced at compile-time.
    • Also, overridden methods must conform to the exception specification of the base-class version of that method: they can throw the specified exceptions or exceptions derived from those.

the pros and cons of java14
The pros and cons of Java
  • Accessing OS Resources:
    • Java can be too restrictive in some cases, you are prevented from doing important tasks such as directly accessing hardware,
    • Java solves this with native methods (JNI) that allow you to call a function written in another language (currently only C and C++ are supported),
    • Thus, you can always solve a platform-specific problem (in a relatively non-portable fashion, but then that code is isolated),
    • Applets cannot call native methods, only applications.

the pros and cons of java15
The pros and cons of Java
  • Documentation
    • Java has built-in support for comment-based documentation:
      • The source code file can also contain its own documentation, which is stripped out and reformatted into HTML via a separate program (javadoc):
      • Create API docs…
        • This is a boon for documentation maintenance and use.

some advantages of java
Some Advantages of Java
  • Java development tools:
    • e.g. Eclipse platform, and a large number of open source, free software that has been made available by the community of programmers.
    • If nothing else, this software can be a starting place to develop new ideas and more sophisticated applications.
  • Programmer productivity:
    • At least two times greater with Java.
    • A lot can be done in a short amount of time with Java because it has such an extensive library of functions already built into the language, integrated development environments, and a wide selection of supporting tools.

java summary
Java Summary
  • Generally, Java is more robust, via:
    • Object handles initialised to null (a keyword),
    • Handles are always checked and exceptions are thrown for failures,
    • All array accesses are checked for bounds violations,
    • Automatic garbage collection prevents memory leaks,
    • Clean, relatively fool-proof exception handling,
    • Simple language support for multi-threading,
    • Java Security, Tooling…

problems developing java applications
Problems Developing Java Applications
  • Memory - both amount used by an applications and speed that memory is recovered:
    • Some evidence that Java applications are becoming increasingly bloated - never been particularly small though!
    • Default JVM has 64 Mbytes, increase the amount of memory allocated using -Xmx command-line switch..
    • Obviously, applications could have multiple threads, or you could be using multiple JVMs.
    • Issues with how quickly GC recovers memory - can cause java.lang.OutOfMemoryError: Java heap space:
      • Commonly seen problem in message systems (i.e. NaradaBroker) and when storing in-memory data-structures (MDS4).

problems developing java applications19
Problems Developing Java Applications
  • Accessing system resources and legacy applications:
    • Java Native Interface created for the purpose of interacting with resources that cannot accessed normally via the JVM:
      • Interacting with OS resources - such as /Proc!, sending signals…
      • User applications, or libraries (MPI).
    • Use of JNI breaks Java programming model:
      • Non object oriented,
      • No GC - memory leaks possible,
      • Relatively complicated interface - easy to make mistakes,
      • OK for C and C++ - need to have a good think about wrapping Fortran as you call it from C/C++!,
      • Lose portability.

problems developing java applications20
Problems Developing Java Applications
  • Relative performance of a Java-based applications depends on a number of factors:
    • Coding efficiency,
    • Version of the JVM,
    • Operating System,
    • Memory available,
    • Others…

The authors conclude, "On Intel Pentium hardware, especially with Linux, the performance gap is small enough to be of little or no concern to programmers."

problems developing java applications21
Problems Developing Java Applications
  • Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks:
    • This should not be surprising as Java is a compiled language (albeit JIT compiled).
  • Nevertheless, the idea that "java is slow" is widely believed.
  • Several possible reasons:
    • Early Java (circa 1995 was slow):
      • Did not have Java JIT compiler, and hence bytecode was interpreted (like Python).
      • Situation changed with the emergence of JIT compilers from Microsoft, Symantec, and in Sun's java 1.2.
    • Java can be slow still:
      • For example, programs written with the thread-safe Vector class are necessarily slower, than those written with the equivalent thread-unsafe ArrayList class.

problems developing java applications22
Problems Developing Java Applications
    • Java program start-up is slow - as a it starts, it unzips the Java libraries and compiles parts of itself, so an interactive program can be sluggish for the first couple seconds of use.
    • There is a similar "garbage collection is slow" myth that persists despite evidence to the contrary.
  • Together these suggest that it is possible that no amount of data will alter peoples' beliefs, and that in actuality these "speed beliefs" probably have little to do with java, garbage collection, or the otherwise stated subject:
    • The answer probably lies somewhere in sociology or psychology.
    • Programmers, despite their professed appreciation of logical thought, are not immune to a kind of mythology, though these particular "myths" are arbitrary and relatively harmless.

java and the grid
Java and the Grid
  • Almost all the core Grid software is now Java-based!
    • Especially now that it is based on Web Services’ technologies…
  • Could ask why this is the case…?
    • Can probably be explained by the fact that Java is a good language for rapid prototyping, it is free, runs anywhere, extensive tooling, libraries,…
  • Core of Globus/Unicore/gLite/OMII/Crown… etc all Java-based.
    • Well defined APIs, so clients can be written in more or less any language.
    • Interacting with legacy applications is more problematic.

the grid s architecture
The Grid’s Architecture
  • Moved to Service Oriented Architecture (SOA) Web Services-based Grid infrastructure back in early 2003 - Open Grid Service Architecture (OGSA):
    • Huge effort to standardise everything Grid-related!
    • Out popped OGSI, quickly dropped,
    • Then WSRF (Jan 2004+),
    • More recently WS-Resource Transfer (Oct 2006)!
  • Also there is a great debate about services and state!
  • Funnily enough, Globus 2.4, is still very popular and a key part of many Grid projects.
  • Far too many changes, standards and specifications, and all very confusing and complicated…
  • Mutterings in the Grid community for several years now, due to fact that no one really knows what standards and specs to use:
    • And if the one chosen will actually still being used in the future.

web services standards and specifications

Web Services Standards and Specifications

Some Standards - list from Geoffrey Fox circa 2004

a list of web services i
A List of Web Services I
  • a) Core Service Architecture
    • XSD: XML Schema (W3C Recommendation) V1.0 February 1998, V1.1 February 2004
    • WSDL 1.1: Web Services Description Language Version 1.1, (W3C note) March 2001
    • WSDL 2.0: Web Services Description Language Version 2.0, (W3C under development) March 2004
    • SOAP 1.1: (W3C Note) V1.1 Note May 2000
    • SOAP 1.2: (W3C Recommendation) June 24 2003
  • b) Service Discovery
    • UDDI:(Broadly Supported OASIS Standard) V3 August 2003
    • WS-Discovery: Web services Dynamic Discovery (Microsoft, BEA, Intel …) February 2004
    • WS-IL:Web Services Inspection Language, (IBM, Microsoft) November 2001

a list of web services ii
A List of Web Services II
  • c) Security
    • SAML:Security Assertion Markup Language (OASIS) V1.1 May 2004
    • XACML: eXtensible Access Control Markup Language (OASIS) V1.0 February 2003
    • WS-Security: Web Services Security: SOAP Message Security (OASIS) Standard March 2004
    • WS-SecurityPolicy: Web Services Security Policy (IBM, Microsoft, RSA, Verisign) Draft December 2002
    • WS-Trust:Web Services Trust Language (BEA, IBM, Microsoft, RSA, Verisign …) May 2004
    • WS-SecureConversation: Web Services Secure Conversation Language (BEA, IBM, Microsoft, RSA, Verisign …) May 2004
    • WS-Federation:Web Services Federation Language (BEA, IBM, Microsoft, RSA, Verisign) July 2003

a list of web services iii
A List of Web Services III
  • d) Messaging
    • WS-Addressing: Web Services Addressing (BEA, IBM, Microsoft) March 2004
    • WS-MessageDelivery: Web Services Message Delivery (W3C Submission by Oracle, Sun ..) April 2004
    • WS-Routing: Web Services Routing Protocol (Microsoft) October 2001
    • WS-RM: Web Services Reliable Messaging (BEA, IBM, Microsoft, Tibco) v0.992 March 2004
    • WS-Reliability: Web Services Reliable Messaging (OASIS Web Services Reliable Messaging TC) March 2004
    • SOAP MOTM: SOAP Message Transmission Optimization Mechanism (W3C) June 2004
  • e) Notification
    • WS-Eventing: Web Services Eventing (BEA, Microsoft, TIBCO) January 2004
    • WS-Notification: Framework for Web Services Notification with WS-Topics, WS-BaseNotification, andWS-BrokeredNotification (OASIS) OASIS Web Services Notification TC Set up March 2004
    • JMS:Java Message Service V1.1 March 2002

a list of web services iv
A List of Web Services IV
  • f) Coordination and Workflow, Transactions and Contextualization
    • WS-CAF:Web Services Composite Application Framework including WS-CTX, WS-CFandWS-TXM below (OASIS Web Services Composite Application Framework TC) July 2003
    • WS-CTX:Web Services Context (OASIS Web Services Composite Application Framework TC) V1.0 July 2003
    • WS-CF: Web Services Coordination Framework (OASIS Web Services Composite Application Framework TC) V1.0 July 2003
    • WS-TXM: Web Services Transaction Management (OASIS Web Services Composite Application Framework TC) V1.0 July 2003
    • WS-Coordination: Web Services Coordination (BEA, IBM, Microsoft) September 2003
    • WS-AtomicTransaction: Web Services Atomic Transaction (BEA, IBM, Microsoft) September 2003
    • WS-BusinessActivity: Web Services Business Activity Framework (BEA, IBM, Microsoft) January 2004
    • BTP: Business Transaction Protocol (OASIS) May 2002 with V1.0.9.1 May 2004
    • BPEL: Business Process Execution Language for Web Services (OASIS) V1.1 May 2003
    • WS-Choreography: (W3C) V1.0 Working Draft April 2004
    • WSCI: (W3C) Web Service Choreography Interface V1.0 (W3C Note from BEA, Intalio, SAP, Sun, Yahoo)
    • WSCL:Web Services Conversation Language (W3C Note) HP March 2002

a list of web services v
A List of Web Services V
  • h) Metadata and State
    • RDF:Resource Description Framework (W3C) Set of recommendations expanded from original February 1999 standard
    • DAML+OIL: combining DAML (Darpa Agent Markup Language) and OIL (Ontology Inference Layer) (W3C) Note December 2001
    • OWLWeb Ontology Language (W3C) Recommendation February 2004
    • WS-DistributedManagement: Web Services Distributed Management Framework with MUWS and MOWS below (OASIS)
    • WSDM-MUWS: Web Services Distributed Management: Management Using Web Services (OASIS) V0.5 Committee Draft April 2004
    • WSDM-MOWS: Web Services Distributed Management: Management of Web Services (OASIS) V0.5 Committee Draft April 2004
    • WS-MetadataExchange: Web Services Metadata Exchange (BEA,IBM, Microsoft, SAP) March 2004
    • WS-RF:Web Services Resource Framework including WS-ResourceProperties, WS-ResourceLifetime, WS-RenewableReferences, WS-ServiceGroup, and WS-BaseFaults(OASIS) Oasis TC set up April 2004 and V1.1 Framework March 2004
    • ASAP: Asynchronous Service Access Protocol (OASIS) with V1.0 working draft G June 2004
    • WS-GAF:Web Service Grid Application Framework (Arjuna, Newcastle University) August 2003

a list of web services vi
A List of Web Services VI
  • g) General Service Characteristics
    • WS-Policy: Web Services Policy Framework (BEA, IBM, Microsoft, SAP) May 2003
    • WS-PolicyAssertions:Web Services Policy Assertions Language (BEA, IBM, Microsoft, SAP) May 2003
    • WS-Agreement: Web Services Agreement Specification (GGF under development) May2004
  • i) User Interfaces
    • WSRP: Web Services for Remote Portlets (OASIS) OASIS Standard August 2003
    • JSR168: JSR-000168 Portlet Specification for Java binding (Java Community Process) October 2003

  • Should we be using standards IF they:
    • Are new and just emerging,
    • Are changing frequently, for example UDDI!
    • Enhance interoperability, but potentially cripple performance,
    • Are not widely adopted,
    • Are not easy to understand and complicated to implement.
  • What are the alternatives?
    • REST,
    • Web 2.0…

representation state transfer rest
Representation State Transfer (REST)
  • REST is a style of software architecture for distributed systems such as the Web.
  • The term originated in a 2000 doctoral dissertation written by Roy Fielding, one of the principal authors of the HTTP protocol specification.
  • The term is also often used to describe any simple interface that transmits domain-specific data over HTTP without an additional messaging (e.g. SOAP) or session tracking (e.g. cookies).
  • The idea behind REST is to take what we all take for granted in the Web (i.e. HTTP and URIs) and use it with other payloads (other than HTML, images, etc.) and other HTTP Methods more than the usual GET and POST.
  • REST defines identifiable resources (URIs), and methods for accessing and manipulating the state of those resources (HTTP Methods).

  • It uses well documented, established, and used technologies and methodologies.
  • It is already here today; been around for while!
  • Resource centric rather than method centric.
  • Given a URI, anyone already knows how to access it.
  • NOT another protocol on top of another protocol on top of another protocol on top of...
  • Response payload can be of any format.
  • Uses the inherent HTTP security model, certain methods to certain URIs can easily be restricted by firewall configuration, unlike other XML over HTTP messaging formats.
  • REST makes sense, use what we already have; it is the next logical extension of the Web… isn’t it!!

what s web2 0
What’s Web2.0?
  • “Web 2.0, a phrase coined by O'Reilly Media in 2004, refers to a supposed second-generation of Internet-based services such as social networking sites, Wikis, communication tools, and folksonomies that let people collaborate and share information online in previously unavailable ways.” - Wikipedia

hard to define know it when you see it



Apps You


Some Apps You Don’t know

Major Retailers

Hard to Define, Know it When you See it…
  • Web API’s
  • “Folksonomies” / Content tagging
  • “AJAX”
  • RSS
  • Flickr
  • Google Maps
  • Blogging & Content Syndication
  • Linkedin, Friendster
  • Amazon API’s
  • Google Adsense API
  • Yahoo API
  • Ebay API

further thoughts
Further Thoughts
  • What is special about the REST model? and Web 2.0?
    • Nothing special from what I can see, but both are gaining popularity!
  • Why?
    • REST architecture is simple and its technologies are mature and stable:
      • HTTP(S) and ASCII!
    • Web 2.0 is some mashup of web-based patterns and technologies:
      • Accessible to users and relatively simple to create Web-based applications.
  • In the end users will vote with their feet and use whatever technologies help them develop applications quickly and effectively.

oh and btw i
Oh and BTW! (I)

oh and btw ii
Oh and BTW! (II)

some java application development

Some Java Application Development

Incidental REST Development!

java based application development
Java-based Application Development
  • Over the last decade my group have been developing Java-based middleware for parallel and distributed applications.
  • We have gained a lot of experience and knowledge about the development of Java-based applications.
  • The next part of the talk will outline some the projects that my group have been developing and some interesting observations about the pitfalls that can be made developing Java applications.

some history
Started off with GridRM ( a wide-area Java-based resource monitoring system:

A scalable infrastructure for gathering native information from computer-based resources,

Agents, gateways, linked in a hierarchical configuration,

Started designing it pre-2000,

No standards in monitoring arena (apart from SNMP), so issue was what to use for our infrastructure?

Choose HTTP and XML as this seemed to provide us with a core, that we could adapt at the end points.

Some History!

Local Layer

Hierarchy of gateways:

Each manages a site:

Interacts with agents,

Deals with policies and security.

Embedded database:

Stores resource and historical data.


Use what is there!

Global Layer

A system to bind together gateways:

Producer/consumer paradigm,


Messaging Layer,

Default security.

GridRM Architecture

further history
Further History
  • Earlier versions of GridRM was relatively hardwired, we wanted to create a more flexible and maintainable solution.
  • Needed software to bind together GridRM gateways and provide a messaging infrastructure…
    • Looked at obvious solutions: MDS, G-RMA, NaradaBrokering…
  • In 2003 we came up with Tycho, a GMA-based infrastructure that would provide a meta-registry and a message system that could bind together our GridRM gateways:
    • GMA was a GGF informational recommendation,
    • Unfortunately in 2003 still no Grid standards - transition from GT2 to GT3 at the time!
    • Consequently, we continued to use HTTP and XML.

tycho architecture
Tycho consists of the following components:

Mediators that allow producers and consumers to discover each other and establish remote communications,

Consumers that typically subscribe to receive information or events from producers,

Producers that gather and publish information for consumers.

There is an asynchronous messaging API.

In Tycho, producers and/or consumers (clients) can publish their existence in a Virtual Registry (VR).

Tycho Architecture

tycho design
Tycho Design
  • Tycho is a based on a publish, subscribe and bind paradigm.
  • Design Philosophy:
    • We believed that the system should have an architecture similar to the Internet, where every node provides reliable core services, and the complexity is kept, as far as possible, to the edges:
      • The core services can be kept to the minimum, and endpoints can provide higher-level and more sophisticated services, that may fail, but will not cause the overall system to crash.
    • We have kept Tycho’s core small, simple and efficient, so that it has a minimal memory foot-print, is easy to install, and is capable of providing robust and reliable services.
    • More sophisticated services can then be built on this core and are provided via libraries and tools to applications.
  • Allows Tycho to be flexible and extensible so that it will be possible to incorporate additional features and functionality.

tycho messaging tests

Tycho Messaging Tests

Performance Tests of Tycho against NaradaBrokering

performance tests messaging

The NaradaBrokering framework is a distributed messaging infrastructure, developed by the Community Grids Lab at Indiana University.

NaradaBrokering is an asynchronous messaging infrastructure with a publish and subscribe based architecture.

NaradaBrokering is Sun JMS compliant. This messaging standard allows application components to exchange unified messages in an asynchronous system.

Performance Tests (Messaging)

summary tycho vs nb
Summary - Tycho vs NB
  • Latency and throughput:
    • When looking at end-to-end performance, on a LAN for messages less than 2 Kbytes, Tycho and NaradaBrokering have comparable performance,
    • Tycho achieves 95% bandwidth, whereas NB only 65.3%,
    • Tyco’s performance is inhibited by the fact that it creates a new socket for each message sent:
      • NB reuses sockets instances once they have been created.
  • Scalability Summary:
    • The scalability tests have shown Tycho and NaradaBrokering producers and consumers to be stable under heavy load:
      • Performance is weaker when there is a large ratio of consumers to producers.
    • Heap Size:
      • The heap size for NB becomes a limiting factor in when a broker is receiving messages faster than it can send them, as the internal message buffer fills until the heap is consumed and system fails,
      • Tycho tests were performed without modifying the heap size, throttling used as there is limited buffering.

tycho registry tests

Tycho Registry Tests

Performance Tests against Globus’s MDS4 and gLite’s R-GMA


The Globus Toolkit’s Monitoring and Discovery Service (MDS version 4) is a Web Services Resource Framework (WSRF) based implementation of a wide-area information and registry service.

MDS4 provides a framework that can be used to collect, index and expose data about the state of grid resources and services.

Typical uses for MDS4 include making resource data available for decision making in job submission services or notifying an administrator when storage space is running low on a cluster.



A Java-based implementation of the Grid Monitoring Architecture (GMA) for publishing network monitoring information over the wide-area and as an information service.

R-GMA uses a relational model to search, using an SQL-like API, and describe the monitoring information it collects.

based on a consumer/producer paradigm with client data being stored in a directory service, which presents it as a virtual database.

R-GMA uses the term tuples for sets of data being published or consumed.


tycho compared to r gma and mds4
Tycho compared to R-GMA and MDS4
  • For the tests we created a set of randomly generated strings to act as attributes for records to be inserted into the registries.
  • A single record, with no mark up, had an average size of 114 bytes.
  • Two tests were used to assess the performance of the registries:
    • [S1] simulates a client searching the registry for records matching some known attributes:
      • Systematic queries are generated using a function to select a record name at random from the test data to guarantee the query will only match one record.
    • [S2] measures the worst-case scenario of the client requesting all of the records from within the registry.

tycho compared to r gma and mds455
Tycho compared to R-GMA and MDS4

Query Response Time Versus the Number of Records for a Query When Selecting a Single Random Record From the Registry (S1)

Query Response Time Versus the Number of Records for a Query that Selects All the Records From the Registry (S2)

tycho compared to r gma and mds456
Tycho compared to R-GMA and MDS4
  • When testing the effect of the number of records on response time, we see that when selecting a single record from 100,000:
    • Tycho 32 seconds faster than R-GMA,
    • MDS4 runs out of heap space for larger records sizes.
  • We also ran tests where there were multiple clients accessing the registries:
    • Again Tycho's VR had a lower response latency than R-GMA and MDS4:
    • With 100 clients Tycho was 94 seconds faster than R-GMA and 65 seconds faster than MDS4.
  • The results highlight that one of the strengths of our implementation is its performance under load:
    • Tycho's performance is linear with regard to both increasing numbers of clients and response sizes.

some conclusions
Some Conclusions
  • We designed Tycho to have a relatively small, simple and efficient core, so that it has a minimal memory footprint, is easy to install, and is capable of providing robust and reliable services.
  • More sophisticated services can then be built on this core and be provided via libraries and tools to applications:
    • This provides us with a flexible and extensible framework where it is possible to incorporate additional feature and functionality, which are created as producers or consumers, which do not affect the core.
  • Performance:
    • Tycho performance is comparable to that of NaradaBrokering, a more mature system:
      • Certain features of NaradaBrokering are superior to those of Tycho, but its memory utilisation and indirect communications are limiting features.
    • Compared to MDS4 and R-GMA, Tycho shows superior performance and scalability to both these systems:
      • In addition, we would argue that both MDS4 and R-GMA have problems with memory utilisation and without significant extra effort limited scalability.

some conclusions58
Some Conclusions
  • Tycho’s functionality has all been incorporated within a single Java JAR and requires only Java 1.5 JDK for building and running applications:
    • Use embedded Jetty applications server,
    • Hypersonic DB.
  • Tycho is now used in:
    • Swarm system - Bit Torrent like system.
    • GridRM,
    • Slogger (Semantic Log Analyser)
    • VOTechBroker.
    • FP6 SORMA project - GridRM and messaging layer.
    • Others:
      • Events/Transactions, Computational Steering.

java messaging
Java Messaging
  • The Paradox:
    • The fastest implementation is via JNI – using the likes of mpiJava:
      • This introduces various issues:
        • Compatibility with underlying MPI,
        • Breaks programming model,
        • Compromises portability!
    • Using 100% pure Java ensures portability:
      • But it might not provide the most efficient solution, especially in the presence of commodity high-performance hardware.
    • It is important to address these contradictory requirements of portability and high performance, in the design of Java messaging systems.

mpj express
MPJ Express
  • To address this, MPJE (MPJ Express) has been developed – project started early 2004.
  • Originally wanted a system that could be used for programming clusters of SMP nodes - Pt2Pt and shared memory.
  • MPJE is an implementation of a MPI-like API for Java:
    • The higher-level concepts, such as communicators (inter and intra), virtual topologies, and derived datatypes have been implemented in pure Java.
    • MPJE uses a unique buffering API (mpjbuf) that allows explicit memory management at the application level.
    • Both Java and JNI communication devices can use this buffering layer, by making use of direct byte buffers for the actual storage.
    • Currently, two communication devices have been implemented:
      • niodev based on Java NIO (New I/O),
      • mxdev based on Myrinet eXpress (MX).
  • MPJE includes a runtime system that permits boot-strapping of processes across remote nodes.

mpj express architecture
The high and base levels rely on the mpjdev and the xdev level for actual communications and interaction with the underlying networking hardware.

Two implementations of the mpjdev are envisaged:

JNI wrappers to native MPI implementations,

Use of a lower level device, called xdev, to provide access to Java sockets or specialised communication libraries.

MPJ Express - Architecture

mpje performance
MPJE - Performance


mpje performance63
MPJE - Performance


mpje performance64
MPJE - Performance
  • Bandwidth:
    • The one-byte latency of MPJE is 164 microseconds, approximately 20% slower than MPICH:
      • Difference due to:
        • Complexity introduced by the thread-safety algorithm, which requires synchronized.
        • MPJE uses an intermediate buffering layer:
          • Implies additional copying,
          • A faster alternative on proprietary networks like Myrinet.
          • Direct byte buffers reside outside the JVM’s heap, possible to get pointers to these buffers from C - avoid copying between JVM/JNI.
  • Throughput:
    • mpiJava achieves 84%.
      • Difference due to additional data copying in JNI.
    • MPICH and MPJE achieve 89% and 87% respectively.
    • mpjdev achieves 90% bandwidth which shows that the main overhead for MPJE is packing/unpacking data onto buffers
    • The drop at 128 Kbytes is due to the change of communication protocol from eager send to rendezvous.

mpj express meets gadget
MPJ Express Meets Gadget
  • To help establish the practicality of real scientific computing using MPJE, the parallel cosmological simulation code, Gadget-2, was ported from C to Java.
  • Gadget-2 is a massively parallel structure formation code developed by Volker Springel at the Max Planck Institute of Astrophysics.
  • Versions of Gadget-2 has been used in various research papers in astrophysics literature, including the noteworthy “Millennium Simulation” – the largest ever model of the Universe.

A 3-dimensional visualization of the Millennium Simulation.

The movie shows a journey through the simulated universe.

On the way, we visit a rich cluster of galaxies and fly around it.

During the two minutes of the movie, we travel a distance for which light would need more than 2.4 billion years.


j gadget
J- Gadget
  • Gadget-2 was manually translated to Java.
  • The data structures were deliberately kept similar so that a cross-reference to the original source code could be made for debugging purposes.
  • Gadget-2 uses the GNU Scientific Library (GSL), a parallel version of Fastest Fourier Transforms in the West (FFTW), and a MPI library.
  • We used the Barnes-Hut tree algorithm for calculating gravitational forces and for communication, we used MPJE.
  • The main simulation loop involves calculating gravitational forces for each particle in the simulation and updating their accelerations;
    • This is the most compute intensive task in the simulation.

Java Gadget can achieve around 70% of performance of the C version.

This is acceptable performance given that Java has many extra safety features including array bounds checking.

Comparison is between a production quality C code against a Java code that could be optimized further.

The performance of Java Gadget-2 reinforces our belief that Java is a viable option for HPC.


  • MPJ Express is a MPI-like Java messaging system.
  • MPJE is a pure Java system, which has an architecture that can also use fast proprietary networks too.
  • The latency and bandwidth of MPJE is not far off that for native C.
  • The performance of Java Gadget-2 reinforces our belief that Java is a viable option for HPC. With careful programming, it is possible to achieve performance in the same general ballpark as C code.
  • MPJE is also being used in other projects, including:
    • MoSeS (Modelling and Simulation for e-Social Science) at Leeds.
    • CartaBlanca (Sandia) that is simulating non-linear physics on unstructured grids.

james gosling says
James Gosling Says…

some lessons learnt
Some Lessons Learnt!
  • In general:
    • Packages should be simple to install, configure and use:
      • Limit external dependences - attempt to embed “extras”,
      • Possible to install in “user space” - avoid need to be root!
    • Use a sensible extensible architecture:
      • Believe in the internet-type architecture:
        • Stable core, with complexity at the edges.
    • HTTP(S) and XML works!
  • Java Development:
    • Necessary to management ones own memory:
      • Cannot guarantee behaviour of GC!
    • Embedded application server, such as Jetty has far superior performance to Tomcat.
    • In-memory storage of data structure is not really always sensible - Java databases, such as Hypersonic overall are as fast to use for storing (persistently) this data.
    • Thread safety, especially with Java 1.5+.
    • Efficient thread use and throttling algorithms for messaging.

overall conclusions
Overall Conclusions
  • Discussed Pros and Cons of Java - not all cream!
  • Made a few comments about WS and REST!
    • What’s the best development route?
    • We have taken the REST-like route, which has enabled us to concentrate on functionality, rather than refactoring!
  • Looked at some Java-based middleware:
    • Tycho is a combined wide area-messaging framework with a built-in distributed registry (VR):
    • MPJ Express, a thread-safe MPI-like bindings for Java:

  • Even though sceptics may still feel that Java is less than ideal, the community of middleware and application developers is increasingly using Java and its related technologies to produce quality software.
  • Java has an extensive number of features, libraries and tools that provide a rich development environment.
  • This uptake is no doubt assisted by the fact that Java is often the first language learnt by students in educational and other institutions.
  • Downloads:
    • Tycho -
    • MPJE -
    • GridRM -

thank you for listening

Thank you for listening


rest toolkits
REST toolkits
  • Restlet -,
  • REST-art -,
  • Cognitive Web -
  • Also Axis2 and XFire provide support for REST Web Services.