Copyright 2004 by Codemesh, Inc. All Rights Reserved 1 Welcome Jini and JavaSpaces in an SOA World by Alexander Krapf East Hartford November 16, 2004

No Slide Title*
*
16 years of C++ development experience
7 years of Java development experience
2 years of .NET experience
4 years of involvement with Jini/JavaSpaces
Yaddah, yaddah, I wish we could do more work with Jini/JavaSpaces but our main business is language integration. The C++ and .NET integration tools just happen to work really well with dynamic, interface-based Java technologies like Jini and JavaSpaces.
Our technology is extremely useful in situations where you have Java APIs that you would like to use throughout your enterprise, but you also have C++, .NET or COM-based applications that need to be able to cooperate with the Java APIs.
Our solutions allow you to take the Java APIs as input for a code generator that generates C++ or .NET/COM proxy bindings for the Java types.
It works really well for customers like Cingular, Fujitsu, VNU Publitec, Northrop Grumman, Lockheed Martin, Fiserv CBS,etc.
Copyright 2004 by Codemesh, Inc. All Rights Reserved
*
Q & A
How it stacks up with Web Services
Q & A
*
What is Jini?
Unfortunately there is a lot of incorrect perception out there. Let’s try to clear that up.
*
Jeannie
OK, it’s pretty lame, but at the risk of dating myself, I did grow up with this series and I really liked it. Nowadays though, Jini is much higher on my mind than Jeannie.
*
Jini is Java-only
Jini is not ready for primetime
Jini is not supported by Sun
Maybe you can come up with some others, but I think these are the main ones that float about in blogs and analysts reports.
*
Jini is Java-centric
(just ask Orbitz)
small (yet fiercely dedicated) team, small
marketing budget, half-hearted relaunch
Jini was originally launched as a device technology. Plug a Jini-enabled device into the network, and it announces itself to every interested party in a reliable and resilient fashion. Right. As if Microsoft would ever put the necessary drivers on Windows boxes. That plan was DOA at conception. What most people missed was that it was a beautiful SOA. The reason most people missed it is that most people didn’t care about SOA at the time.
Jini is not Java-only, but it is highly Java-centric. It leverages more of Java’s key strengths than any other Java technology. As such, it is of course best used from Java, but not to the exclusion of other languages.
Jini has been ready for prime-time since Jini 2.0, which added security, something that is a true prerequisite for any mobile code technology.
Jini could use more support from Sun. It is by no means unsupported, but there are several misperceptions that need to be cleared up before the technology can gain wide-spread acceptance. Also, the starter kit is still too hard to use. People will try to get a service running and spend a week on it.
*
If Jini is one, then what IS an SOA?
A system for linking resources on demand. In an SOA, resources are made available to other participants in the network as independent services that are accessed in a standardized way. This provides for more flexible loose coupling of resources than in traditional systems architectures.
Webopedia
whatis.com
An application architecture in which all functions, or services, are defined using a description language and have invokable interfaces that are called to perform business processes. Each interaction is independent of each and every other interaction and the interconnect protocols of the communicating devices (i.e., the infrastructure components that determine the communication system do not affect the interfaces). Because interfaces are platform-independent, a client from any device using any operating system in any language can use the service.
Though built on similar principles, SOA is not the same as Web services, which indicates a collection of technologies, such as SOAP and XML. SOA is more than a set of technologies and runs independent of any specific technologies.
Too many people regard SOA to be synonymous with WebServices. Here are two definitions from the web. Notice particularly the latter definition which makes clear that web services in and of itself is not an SOA.
*
Language
Independent
The colored boxes represent what we could glean from the definitions of SOA. Unfortunately, there is a boatload of characteristics that we really need/want in an industrial-strength architecture.
Traditional distributed architectures have often suffered from a lack of reliability/resilience in the presence of underlying hardware failures. Furthermore, they often required complex deployment schemes that scale badly. Security is mostly an afterthought in all architectures.
Easy-to-use comes with lots of asterisks because almost by necessity, an architecture that supports all these features will have some complexities and require an understanding of client/server principles. TINSTAAFL.
*
Characteristic
Jini
Device Independence
Statelessness
Resilient
yes, more than any other architecture I’m aware of!
Reliable
yes, more than any other architecture I’m aware of!
Secure
Dynamic
Easy to use
at least for a distributed object technology!
Jini solves most of the really hard problems straight out of the box and for all other problems there are external solutions that can be put on top of it.
Some of the characteristics are only available via add-ons, for example our core expertise of language independence. XML-based SOAs are definitely more language portable than Jini, but via Codemesh’s commercial technology, C++ and .NET integration are no problem.
One common misperception is that a full J2SE or at least J2ME environment is required on a Jini-enabled device. This is wrong. The Surrogate specification allows a different system to serve as a “surrogate” for the device and serve proxies in its stead. Another approach is used by Psinaptics Inc. which ships a full Lookup service as an embeddable C application in 4kB plus the size of the served Java proxy.
*
the embodied consequence of Jim Waldo
et als “A Note on Distributed Computing”
a specification of several core Services
providing discovery, transactions, and persistence
comes packaged in a starter kit, not a reference
implementation!
normal mode of operation!
In “A note on distributed computing,” Waldo made two core points:
a service client needs to know the service interface to make use of it.
There is no general use case for dynamically discovered services of
unknown type.
knowledge of the distribution boundaries.
This flies directly in the face of technologies like DCOM or .NET remoting that attempt to hide the distributed characteristics from the developer.
A reliable, resilient distributes application has to be designed with the explicit understanding that devices and networks will fail.
Jini does not have a reference implementation. The Jini technology starter kit (TSK) is shipped in binary and source and modifications are permitted under the hard-to-understand SCSL. One source of eternal confusion involves the Compatibility Tests that services must pass. Most people just don’t worry about them, but Sun cares about them. They do have a good point because in a distributed application, one misbehaving service could wreak havoc. For example by flooding the lookup services with bogus service registrations.
*
every other Service
Service life-cycle management
With all SOAs there is the question of bootstrapping. How do you discover the “entry point”? In Jini, there is the discovery and join protocol that allows a client to discover services via multicast or unicast protocols. Multicast is great for LAN-based deployments, unicast for WAN or internet-based discovery. It’s also pretty easy to create alternate discovery mechanisms, for example via JNDI or UDDI.
The first service you discover is a lookup service which you then query for the service you’re really interested in.
All services are leased from the Jini framework. If a network connection fails or a client dies, the Jini runtime will eventually revoke the lease because the client failed to renew it. This solves one of the toughest problems in distributed networks: distributed life cycle management. Leases are also tightly integrated into the transaction mechanism of Jini, we’ll discuss this later in the context of JavaSpaces.
*
to be extended!
A Jini service is simply an interface. Typically, the methods should throw at least RemoteException if they call a remote service, but this is not strictly required as we will see a little later. There are very useful services that never make remote calls.
Notice that there is no Service interface that needs to be extended. This is unusual for distributed architectures, which often force you to extend a base class or interface.
*
or even nothing! Proxy could just be a
dynamically loaded interface implementation!
Join
Download
One of the interesting things about SOAs is that we’re talking about Services and not about Servers. This is one of the big differences between J2EE and Jini. Jini has just one traditional server that need to be present:
a codebase server, typically a simple http server for serving jar files
All other infrastructure pieces are Jini services.
This example illustrates how a service implementation publishes a service proxy by registering with a lookup service. The lookup service actually downloads the service proxy, of course always with a lease involved. If the service implementation does not keep its lease alive, the lookup service will throw away the downloaded proxy.
Clients ask the lookup service for a service implementation for a given interface. If a lookup service has a matching proxy, it will upload it to the client. This means that the client actually ends up with code, not just with an address to call!
The proxy does not have to use any particular protocol to communicate with the service implementation. In fact, it does not have to communicate with the service implementation at all! The proxy could be a so-called smart-proxy that executes all service operations on the client. In that case, Jini would just have been used to dynamically deploy a piece of code to the client.
*
{
The dynamically deployed Hello
The simplest possible service implementation just prints to the console on the client system. Remember that the HelloImpl type was downloaded by the client and is executed on the client, not on the server! This means that the message appears on the client’s screen.
*
{
The (improved) dynamically deployed Hello
This time, we have some functionality that figures out whether we can/should show a GUI rather than just printing to the console. One of the questions we’ll face is how we’re going to get this to replace our old HelloImpl implementation on a client that has already downloaded an old client implementation.
*
{
totally protocol independent!
This is the first service implementation that actually talks to the service host. I intentionally used a generic sendMessage() function to indicate that the communications could be done in any protocol you wish to use.
*
Server
Server
Server
HelloImpl
Proxy
HelloImpl
Proxy
HelloImpl
Proxy
HelloImpl
Proxy
HelloImpl
Proxy
HelloImpl
Proxy
Hello
Hello
Hello
Lookup
Lookup
Lookup
Proxy
Lookup
Proxy
Lookup
Proxy
Lookup
Proxy
It’s really amazing how well a Jini framework scales. Let’s say you have 10 or 15 boxes standing around that you would like to use as a reliable computing platform. Invest some money in good network connections and a redundant switch and start deploying Jini services. Start multiple lookup services so that there is no single point of failure if one fails.
In this illustration, we have a Hello service deployed on three machines and a Lookup service on two. All of the services are available from any Lookup service because Lookup service instances are aware of each other and exchange information about registered services. No matter which Lookup service you use, you will have access to all three Hello service instances and thereby be able to scale well. Couple that with smart proxies that execute some functionality on the client, and you have a great framework for scalable services.
*
and Leases
Server
HelloImpl
Proxy
HelloImpl
Proxy
Hello
Lookup
Lookup
Proxy
Lookup
Proxy
System resilience is proportional to a system’s ability to detect error conditions and it’s ability to react to them. Having multiple instances of services is one part of resilience, but figuring out when a service dies or can’t be reached is another part. Jini accomplishes this latter part via Leases.
When a service registers itself with the lookup service, the lookup service grants a “lease” that basically defines how long it will keep track of the service proxy. If you wish the lookup service to keep track of it for longer, you will have to renew the lease before it expires (Jini provides helper classes for that purpose). This puts the burden of “keeping alive” the service on the service. If the lookup service doesn’t hear from the service in time, it will assume that the service has died, is unreachable, or has had other unfortunate incidents; consequently, it will evict the service and future clients will not be handed a service proxy that refers to a defunct service. The “liveliness” of the system depends on the leasing time. Clearly you don’t want to have the service renew the lease every millisecond, but also clearly a two-day lease does not really provide a dynamically reacting system. The proper lease interval depends on your application’s liveliness requirements.
The “Lease” is a core concept of Jini and enshrines the following principle: if something is remote (or can be remote), you have to assume that it will go away without notice. The only way to ensure that the system is aware of problems is to use the absence of something as a problem indicator.
*
standards-based security:
- authenticated endpoint
- validated content
The client starts out only having the Hello interface because that’s how it knows the kind of service it wants to use. A core principle of Jini is that it does not make sense to ask for something that you don’t know how to use. By definition, a Java interface establishes a calling contract between the caller and the callee, so it is the perfect medium for establishing the client/server contract.
Once a client has looked up a service, it gets a downloaded copy of the service proxy, including all required types. You need to carefully modularize your application to not deploy unnecessary types to the client. Only this way do you ensure that everything is dynamically updated via the service mechanism.
*
Client not necessarily talking
Jini Example Key Features
What we see here is example 1 and example 3. In the first case, the HelloImpl proxy is really what’s usually referred to as a “Smart Client.” In this case, it’s so smart that it doesn’t even have to talk to the server anymore at all! How is this useful? You can for example dynamically deploy business logic to your client application each time the client application is started.
In the second illustration, we have the client execute the application-specific sendMessage() method. The purpose of this illustration is to show that the protocol between client and server is totally up to the application developer. Many people assume that all client/server communications have to use RMI. Jini can use RMI and has some default implementations that use RMI, but you’re not tied to it.
*
configurable!
Download can be verified
are available out of the box
…and it’s still hard!
Since version 2.0, the Jini framework has incorporated security right into its core components. Make no mistakes: configuring for security is still a hard job! Remember the asterisks with Ease-of-use; they specially apply here.
*
Can we pick a particularly typed instance
of an implementation?
Codebase, codebase, codebase…
using it?
How is this different from RMI or DCOM?
The major difference to RMI and DCOM lies in the code mobility aspect. You’re not just connecting to a server and executing remote function calls on it, you’re downloading code to the client and executing it there. That code may choose to talk to the server/service, but it doesn’t have to. The importance of the “Lease” feature should also not be underestimated.
Can we pick a particularly typed implementation?
In the HelloService example, we have three different implementations that provide different flavors of a “Hello World” service. As long as we give the implementations different type names, they can all peacefully coexist in the system, even if they’re served from the same codebase. What we cannot do is look them up by their implementation type because that would violate the entire SOA idea: remember that the client only knows that it’s getting a service that implements the “Hello” interface. There is another feature though that can help us: Jini provides the ability to annotate Service instances with properties and those properties may be used to choose a particular service type over another one.
Can we”flush” the system?
Services have to explicitly register themselves with the Lookup Service. They can (and should) also unregister themselves when they’re not active anymore (they will automatically get flushed if their Lease expires). If a client has acquired an old instance of a service, it will keep it until the end of its session. If that instance is a client/server service and the “server” part has gone down as part of service deactivation, the client is going to get RemoteExceptions as a result. In a good, stateless design, the client can now simply lookup the service interface again and acquire a different (now newly typed) instance of the service.
Codebase, codebase, codebase…
Many Jini features rely on code download and security in particular is very fussy about correct configuration. Getting everything to work usually relies on having the codebase configured correctly. Unless you have lots of RMI experience, that can be tricky.
If that really works, why isn’t everyone using it?
Good question…
*
Web Services lacks code mobility features
Web Services is language independent
as long as there’s a full service stack for the language
Web Services is popular
it’s going to be easier to find Web Services experience than Jini experience
Web Services does not handle resilience,
reliability (in core spec)
First of all, it’s really not too smart to contrast different middleware technologies in a context-free environment. The question should always be: Jini vs. Web Services for doing what exactly?
Regardless of that, we can list some general technological differences. How those differences are to be judged depends on the project. For example, the lack of code mobility in Web Services might be deemed a good thing in a project that needs to ensure that no code ever gets deployed dynamically on a machine.
*
deployment, QoS/SLA of Services
Inter-Service communications
Workflow/scheduling
JavaSpaces
There are tons of Jini projects that are getting quite mature. RIO is one project that defines a service container framework allowing dynamical deployment of Jini service implementations based on constraints. A cool example is the Navy’s next generation destroyer that can move Jini services away from computers that are in harm’s way, for example an incoming missile.
What’s missing is a way for services to persist information in a distributed way and share it with the same reliability and resilience, which leads us to JavaSpaces.
*
*
It must be a JSpace, captain!
j
Even lamer than the first one, but hey, every presentation needs some lame humor.
*
*
but it may use one internally
JavaSpaces is a Jini Service
thereby inheriting all Jini advantages
JavaSpaces is … JavaSpaces
best defined through its use
JavaSpaces is really hard to define. The best way to define it is by looking at what you can do with it and what you should not do with it.
One of the biggest temptations to avoid with JavaSpaces is to use complex queries. You really don’t want to use if for problems where in database terminology you would need to do joins or complex where clauses. JavaSpaces works best if you can phrase the request something like:
“Give me a Foo, just about any Foo will do because I don’t really care
which one I get!”
*
read, write, take are the most common operations
no modification of entries in space (take out – modify - put back)
The traditional picture shows a lot of information if you just look closely enough:
you can talk to more than one space at a time
the most common operations are read, write, take (the other two are notify
and snapshot)
entries in the JavaSpace are never modified. In order to make a change,
you have to take the entry, modify it, and write it back. This means that
you never have concurrency issues on entries.
There was quite a bit of confusion at the session about the semantics of reads and takes. Just one more example: you have an object and you write it into the space. Now the space contains one entry. You take the object out of the space. Now the space contains zero entries. Anyone trying to read an entry from the space will block at this point until someone puts a matching entry back into the space. If there had been two copies of the object in the space, the read would succeed on the second entry even if the first entry had been taken.
All space operations are atomic (ACID properties are observed), so there is never a race condition between reads, writes, and takes.
*
almost all big projects deserving of an
SOA approach require workflow or
orchestration features
*
Entrys are leased from the space
Entry operations can be transacted
Entrys are queried by example
Yes, you can send messages with JMS or MQSeries, but do you get the behavior of the object too? You have to know what you’re dealing with at the other end with all other technologies (except some brand-new agent frameworks that look a lot like Jini/JavaSpaces).
*
you need to implement
types and Strings as entries
What is an Entry?
{
}
Unlike Jini services that don’t have to extend/implement any base type, user-defined entry types have to implement the Entry interface.
*
on all non-null template members
A random matching entry will be returned
Query by Example
{
found = space.read( template );
Something that many people don’t like is the requirement of declaring your entry type’s fields public.
*
but we could add a firstLetter field for matching purposes
Find me a Person who was born in 1960
but we could split up birthDay into bdDay, bdMonth, bdYear
Find me a Person who was born before 1960
tough one with JavaSpaces, but possible with some vendors
Query by Example (Limitations)
{
}
Something that many people don’t like is the requirement of declaring your entry type’s fields public.
The other thing to keep in mind is that in identifying matching entries, exact binary equality is used, not a call to the equals() method. The reason for that is that the objects don’t really exist as life objects in the JavaSpace. Internally, they are kept in an optimized, serialized form that lends itself to efficient binary comparisons (hashcode test for example), but not to OO equality comparisons.
One of the hardest things to do with JavaSpaces is matching based on interval criteria, like greater than, less than, before, after. You really need to go out of your way to make that work, and that’s where a database becomes more appropriate.
*
Validator
Request
Response
request
write
take
write
take
write
take
This was presented by Sun as a thought piece at the last Jini Community Meeting in Boston.
An important characteristic of JavaSpaces is that in the standard usage pattern all communications are directed to the JavaSpace. This means that there is never a user initiated connection to the AppServer, the Validator (just another service) or any other client, except for the Web Server. If the Web Server is corrupted, the biggest damage it can do is to write fake Requests into the JavaSpace that could then be detected and discarded by the Validator(s).
How is that better than a traditional firewall? It scales better across number of applications or services. With a traditional firewall, you have to configure for every single service that you wish to make reachable. And then a machine behind the firewall is directly or indirectly reachable from the outside. With this approach, no machine behind the firewall is ever directly reachable.
*
public String priority = null;
public String jobid = null;
public String owner = null;
public Boolean done = null;
public int[] inputs = null;
public int[] outputs = null;
A concrete task
There are undoubtedly better designs for a compute server, but this shows the basic design. You have a base type called Task that maintains information about which job it belongs to, who owns it, what it’s priority is, and whether it’s completed. In a real industrial strength design, you would probably want to do some refactoring to maintain results separately from tasks and have error information stored in the results. The Task class has an execute() method which does not perform any operations. Concrete computation tasks are subclasses of Task and reimplement the execute() method.
How is this different from distributing computation jobs via messaging or clustered application servers? We will see shortly when we discuss the server side implementation of this example.
*
mt1.inputs = new int[] { 10, 20, 30 };
ModelingTask mt2 = new ModelingTask( “NORMAL”, “job1”, “alex” );
mt2.inputs = new int[] { 20, 40, 60, 80 };
space.write( mt1, null, Lease.FOREVER );
space.write( mt2, null, Lease.FOREVER );
Client-side: Posting the problem
On the client side, we simply write the entry into the JavaSpace we discover via a lookup service. In an industrial strength design, we would do this inside a transaction to rule out loss of the task due to device failures.
Notice that we grant an eternal lease for the object. Again, in an industrial strength design, we might not want to do that. By choosing a finite limit, we can effectively have the task instances removed automatically from the space if the job takes too long. In that way we can easily avoid filling up the space if processors can’t keep up with the load (there are other schemes for that too).
If we wrapped all write operations in a transaction, we could also have all tasks of a job be removed automatically if one of the tasks can’t be written successfully. It should be noted that anything that happens inside a transaction has no visibility outside of the transaction. For example, no Task that is written from within the transaction can be read or taken from outside the transaction until the transaction is committed.
*
template.done = Boolean.TRUE;
while ( true ) {
results.add( e );
Client-side: Retrieving the solution
Retrieving the results is equally easy. First we create a template that basically says that we’re interested in any Task instance that belong to our job that are marked as done. Then we keep retrieving them with a maximum wait time to avoid locking up the client if the processors can’t keep up.
There are many other things that we would want to do here in a real-life solution, for example not continue looking for more results after we successfully retrieved all, but this is just for illustration and could easily be achieved by counting the objects in the results list.
*
template.done = Boolean.FALSE;
while ( true ) {
try {
if( t != null ) {
Server-side: Processing the problem
Here’s where it gets really interesting: As you can see, the service implementation simply takes Task instances out of the space, processes them and writes the result back into the space, all within a transaction. If anything fails in this sequence, the unprocessed task will revert to the space and eventually be processed by a different processor.
The key point here is that not only is the processor not aware of the concrete task it processes, but it did not have to have that concrete task deployed! The concrete task class is downloaded via the JavaSpaces infrastructure. This is hugely different from distributing work via JMS or J2EE, where you need to have the implementation available on the server.
Combine this code mobility with the automatic failure handling and you get an incredibly resilient and reliable infrastructure that’s still relatively easy to use.
*
Improved TSK experience
it can still take you a long time to really get going…
Space Iterators
it is still hard to iterate over ALL entries matching a template
Batch operations
Nothing much to add here.
*
they get closer to being an SOA
Have one big advantage: language independence!
(as long as a full protocol stack is available)
Codemesh JunC++ion and JuggerNET
I’m not a big web services fan. The original web services specification was easy to understand and implementing a SOAP entry point is pretty easy. That made Web Services a great technology for gluing applications together. Once the standards groups started tackling all the other requirements of an SOA, web services started going the way of CORBA: it’s getting harder and harder to use and you need more and more infrastructure to take advantage of the features.
In SOAP messaging, you just need a simple XML parser, you could even just do some simple pattern matching if you know what to expect and don’t care about security. Slap all the extensions on top (reliable messaging, security, etc.) and you need the WebSphere runtime with a bunch of extensions, altogether clocking in at 60+ MB. I don’t call that exactly lightweight and device neutral…
Web services clearly have the edge in language independence though, at least theoretically. XML stacks are available in most languages now and popular security packages also exist in many languages. How the different packages interact in practice though is anyone’s guess.
*
for arbitrary Java types
easy usability from C++ and .NET
Plug Jini/JavaSpaces into Excel or Word via
generated .NET/COM bindings
Write computationally expensive clients in C++
Here’s where our expertise comes into play. We have tools that expose Java to other programming environments, particularly C++ and .NET.
You take your compiled Java and drag&drop it on our tools and you end up with C++ or .NET proxy classes for your Java classes.
*
JVM in the native process
Developer writes C++ or .NET code,
under the hood Java is executed
Codebase downloads, interface invocations,
and security are transparent
200%, typically < 25%
Architecturally, we do not require external infrastructure beyond a JRE. A JVM is launched in the C++ or .NET process and where the native programmer used proxy classes, every method call or field access is translated into the corresponding action on the Java type.
While we can generate proxy types for any Java types, this is a great match for Jini/JavaSpaces because all the codebase downloads and remote calls are totally transparent to the user and developer.
Performance is typically very comparable to a pure Java application. The JRE cannot optimize as much as in a pure Java process because there are many calls from outside the JVM, so the JIT is somewhat hampered. The more work is done in Java, the less this matters. Also, the more application performance is dominated by network/database/IO operations, the less this matters. Often the overhead can be close to 0, in worst cases, it can be a factor of two.
*
Task task = (Task)e;
Write C# code like this:
A little C# snippet that retrieves a Task from the space. Notice that the only difference to a corresponding Java implementation is the “Impl.” .NET does not permit static members in interfaces, so our tool generated an implementation class that contains the static members of the Java interface.
Our .NET product obviously only targets Windows developers, but our C++ product generates portable C++ code that currently works on Windows, Solaris, Linux, MacOS X, and IRIX. Ports to HP-UX and AIX are under way.
*
Java Server
Client Process
Server Process
Here’s the picture at runtime. You have two processes: the service implementation and the service client. In this case, the service client is a .NET application. Inside the .NET process, the JuggerNET runtime launched a JVM which eventually ends up with the downloaded service proxies.
The developer deals with these proxies through generated .NET proxy types and is totally unaware of what happened under the hood. As far as the service implementation is concerned, it is communicating with a Java client. As far as the .NET developer is concerned, there is some funky stuff going on under the hood, but he is dealing exclusively with .NET types.
*
C
JNI
DLL
C#
PInvoke
assembly
API
This looks fairly complicated, but it is actually pretty easy. The .NET developer wants to use some Java types. The easiest way to use them is via generated .NET types that just happen to look almost exactly like the Java types we’re interested in. These .NET types delegate all invocations to a managed runtime library, which in turn delegates to an unmanaged runtime library, which uses JNI to talk to the JVM.
It’s all in one process and consequently the most easy and reliable way to solve this integration problem. In terms of performance, it’s usually also the best solution, unless the problem involves a lot of bulk data with lots of setup across the language boundary. In that case a custom protocol between the two sides would be advantageous.
*
ISBN 0-201-30955-6
ISBN 0-201-726173
by Jan Newmarch, Apress, ISBN 1-893-115801
“A note on distributed computing”,
http://research.sun.com/techrep/1994/smli_tr-94-29.pdf
Jini.org
http://jini.org
http://pandonia.canberra.edu.au/java/jini/tutorial/Jini.xml
http://www.dancres.org/blitz/index.html
Some literature about native programming if you feel masochistic enough to want to educate yourself in this area.
*
by Sheng Liang, Addison-Wesley, ISBN 0-201-32577-2
Essential JNI
by Adam Nathan, SAMS, ISBN 0-672-32170-X
JNI Documentation
http://staff.develop.com/halloway
Some literature about native programming if you feel masochistic enough to want to educate yourself in this area.
*
for more questions!

Documents

Copyright 2004 by Codemesh, Inc. All Rights Reserved 1 Welcome Jini and JavaSpaces in an SOA World by Alexander Krapf East Hartford November 16, 2004