some notion in terracotta

Shared Roots

A shared root is a class data member that is transparently mirrored across all like-configured DSO applications running against the same DSO server. The term root refers to the fact that the field may represent the top of an arbitrarily large object graph. For instance, a java.util.ArrayList is a collection of java.lang.Objects, each of which may also be composed of further sub-objects. A root can also be a simple primitive such as an int or boolean.

Distributed Locks

A distributed lock is a form of a distributed semaphore, protecting areas of code that modify members of a shared root graph from simultaneous access and providing the hook DSO uses to synchronize data values across to the server for subsequent broadcast to other connected clients. In the distributed programming paradigm, a lock is analogous to a distributed synchronized method.

There are two categories of locks, named and automatic.

Named Locks

A named locks is meant to be used with code not specifically written for multi-thread safety. A method can be associated with a particular name, meaning that all similarly named methods use the same lock. In other words, if two methods share the same lock name and one method invokes the other, only a single actual lock will be taken out for the duration of the outer invocation.

Automatic Locks

An auto lock is meant for the case were the code is written with multiple threads in mind, using the synchronized keyword to demarcate protected areas. A synchronized block or method denotes a section of control flow that will be serialized with respect to thread access. Only a single thread can enter the block at a time.

Project Cajo

• Contents
• • What's Cajo?
  • Working on Cajo
  • The Cajo Community
  • Challenges and Surprises
  • Resources

As the community manager of java.net, I am always trying to get better data about what projects on java.net are really active. One of my interns recently implemented a great report that shows the top 50 most active projects on java.net for a given month. "Most active" means with the largest number of actions (writes of some sort) that we can detect to the code or mailing lists within each project. (We also included forums, but that measure is broken at the moment.)

I notified the owners of the top 50 projects for February, and one of them, John Catherino, project owner of the Cajo project, asked why I don't make the data public. I said, "Yes, obviously we should and we are working on how to do that, but also I want to interview the owners of some of these most active projects," and would he like to be my first victim? He said yes.

A quick look at Cajo proves not to be so very quick because it is so interesting: a small, free library that simplifies the use of Remote Method Invocations; is easy to use; is in use all over the world; and is a "uniquely 'drop-in' distributed computing framework." And how could I not click on a link to a blog entry titled "World Wide Virtual Machine"?

What's Cajo?

Q: How would you describe your project, in a nutshell?

A: The Cajo project allows people to distribute their applications across multiple Java Virtual Machines, without source impact. This makes it exceptionally valuable to scale large, existing applications. It also allows graphical user interfaces to be transparently remoted, automatically, through both WebStart and via applets.

Q: Who is using Cajo and what are they doing with it?

A: As the Cajo project is quite fundamental in its purpose--i.e. distributing objects between Java Virtual Machines transparently--it is being used by groups of all sizes; university students, companies small and large, and even national governments. Its primary applications are scaling applications, distributing user interfaces, and remote control.

Q: Can you give me an example?

A: mBooster. From their page:

mBooster is the world-leading optimization suite for J2ME applications for professional J2ME game and application developers. mBooster automatically reduces the size and increases the performance of your midlet JAR files.

And you can find the acknowledgment of Cajo as one of the building blocks on their license page.

Q: What does it mean to have an official TCP and UDP port assignment, and an official multicast address, assigned by the Internet Assigned Numbers Authority (IANA)?

A: It means that TCP and UDP port 1198, and UDP address 224.0.23.162, are registered to the Cajo project for worldwide operation, on the internet. To me it is an astonishing recognition of our project's maturity, usefulness, and popularity. We are now part of the internet infrastructure.

Working on Cajo

Q: What made you decide to start this project?

A: I have been developing network distributed applications for many years; in that time I have seen too many people struggle, and decry all of the complexity. Worse yet, some would just give up on their great ideas. For a long time I tried to individually help people, but there was a limit to how much I could accomplish this way. I felt the Java Runtime Environment offered such tremendous capability, I knew there had to be a way to make Java object distribution over the network truly transparent. This would be a revolutionary simplification. Then in late 1998, when Sun JSE 1.2 introduced reflection, and powerful enhancements to RMI, I knew I had the foundation I needed. The Cajo project was ready to be born.

Q: Is working on Cajo part of your day job?

A: Not exactly. I currently work in distributed grid-based software development, yet building this project has allowed me to bring a lot of insight to the table. Perhaps one day, the company may base a project on Cajo; if a customer had a requirement for an open source implementation, for example.

Q: A popular open source project is a lot of work; what keeps you going?

A: When development gets very busy, it is usually because one or more individuals, project development teams, or companies are newly and actively adopting Cajo. I get such tremendous feedback and satisfaction from helping people achieve (and quite often, wildly exceed) their goals. That makes it worth all the work to me. The most common response: "I can't believe it's this easy!"

Q: What would you like to see added to the java.net project section?

A: More project tracking statistics, visible to everyone: page hits, downloads, both community and site ranking. It is this type of information that enables surprisingly emergent development to occur.

The Cajo Community

Q: Your project home page has some handy links and stats on the right side, like 168 members, and the percentage breakdown by continent. How many of them are developers who contribute to Cajo?

A: I guess it depends on what is considered contribution. A little over 10 percent suggest actual code improvements. However, well over half are significantly improving the site, through questions and comments. Personally, I consider every post to any Cajo project forum a contribution. There are even some who have made very significant contribution, and aren't even members.

Q: Why did you create a cajo.Contributor role?

A: Currently any java.net role other than Observer, is granted repository commit privileges. This implies a significant amount of responsibility, given the large user base of the Cajo project. The cajo.Contributor role allows members to post to the "Documents & files" section of the site. I grant this role to anyone with a plan to extend or add to the project. I find it so useful, I would recommend it as a an official java.net role.

Q: How do you manage community member contributions?

A: I use two approaches. In the more common case: developers make suggestions for new features, and we discuss them in the project forum. Then I go create a proposed implementation for ratification. Once the version is agreed upon, it is incorporated into the codebase. In the less common case: members want to make a significant code contribution to the project, in an area outside of my expertise. Then they are welcomed to create an add-in release, and are free to develop and document it as they wish on the project site. The Cajo extension for JEE is an example of this second case.

Q: Why did you chose the GNU LGPL?

A: For two fundamental reasons. First, I wanted the ability for the Cajo library to be used between both open and proprietary applications. To me this requirement seemed to allow all but the GNU GPL. Second I wanted to prohibit distribution of proprietary versions this library. In light of the first requirement: to me this requirement seemed to exclude all but the GNU LGPL. While the selection has caused several conversations with both developers and companies, so far I have never had anyone who felt unable to live up to the terms.

Challenges and Surprises

Q: What has been your most difficult challenge?

A: Documentation. Most developers, and I am no exception, do not like to work on it. However, an open source project without detailed documentation will most likely be ignored. The Cajo project source code is nearly half Javadoc! Then I had to generate all of the web pages. Most challenging is creating good examples. This is something on which I continue to work. Sometimes I even get great examples from developers.

Q: What has been your biggest surprise?

A: To be honest, at the start I worried people would flame what I thought was the best code of my career. Even worse, I worried nobody would care. On the whole, open source software developers are a really very accepting and enthusiastic community. That was very happily surprising. Yet I'd have to say, recently discovering that some people had created Wikipedia articles about the Cajo project, in both English and German, for the first time, I went from pleasantly surprised to completely overwhelmed with appreciation.

Editor's note: We'd like to thank John for discussing the Cajo project in this interview. You can look for more interviews with prominent java.net project leaders in the coming weeks and months.

Resources

• Cajo project
• Some sites using Cajo:
  • Individual: coderspiel: Out of hibernation
  • Commercial: Innaworks mBooster
  • Education: Magicka Interactive Ltd. Adminix
  • Professional: Srihitha Technologies Project 28
  • Academia: Laborator 6

Marla Parker is the Community Manager of java.net.

How we pass parameter in RMI

To begin introducing who we pass parameter in RMI JAVA , let's review how parameter are passed in a single JVM.
In single JVM a primitive data type is passed by value.The mechainics of passing an object as a parameter is more complex. Often the reference of the object is passed to the method.In the method ,code use the copy of reference to access the object.

Now we look at the differences in RMI.

Primitive Parameters
for primitive parameters,the mechanics is much more the same.RMI will make a copy of the data, and send it to the remote method.

Object Parameters
The mechanics of RMI is quite different from that in a single JVM . RMI send the object itself rather than the reference of the object. It is the same case if the return value is a object.
RMI use a technology called Object serialization to transform a object into a linear format that can then be sent over network.
And there is one thing we should pay attention to .If the object is complex, like graph-like structure, it will use a lot of cpu time and network bandwidth.

Remote object Parameters

When passing an exported remote object as a parameter or return value in a remote method call, the stub for that remote object is passed instead. Remote objects that are not exported will not be replaced with a stub instance. A remote object passed as a parameter can only implement remote interfaces.

Steps in the Development Process

Developing a simple JavaServer Faces application usually requires these tasks:

Mapping the FacesServlet instance.
Creating the pages using the UI component and core tags.
Defining page navigation in the application configuration resource file.
Developing the backing beans.
Adding managed bean declarations to the application configuration resource file.

Model-View-Controller (MVC)

The MVC architecture is a widely used architectural approach for interactive applications that distributes functionality among application objects so as to minimize the degree of coupling between the objects. To achieve this, it divides applications into three layers: model, view, and controller. Each layer handles specific tasks and has responsibilities to the other layers:

• The model represents business data, along with business logic or operations that govern access and modification of this business data. The model notifies views when it changes and lets the view query the model about its state. It also lets the controller access application functionality encapsulated by the model.
• The view renders the contents of a model. It gets data from the model and specifies how that data should be presented. It updates data presentation when the model changes. A view also forwards user input to a controller.
• The controller defines application behavior. It dispatches user requests and selects views for presentation. It interprets user inputs and maps them into actions to be performed by the model. In a web application, user inputs are HTTP GET and POST requests. A controller selects the next view to display based on the user interactions and the outcome of the model operations.

What Is a Servlet?

A servlet is a Java programming language class that is used to extend the capabilities of servers
that host applications access via a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers. For such applications, Java Servlet technology defines HTTP-specific servlet classes.

Servlet Life Cycle

The life cycle of a servlet is controlled by the container in which the servlet has been deployed. When a request is mapped to a servlet, the container performs the following steps.

If an instance of the servlet does not exist, the web container
Loads the servlet class.
Creates an instance of the servlet class.
Initializes the servlet instance by calling the init method. Initialization is covered in Initializing a Servlet.
Invokes the service method, passing request and response objects. Service methods are discussed in Writing Service Methods.

If the container needs to remove the servlet, it finalizes the servlet by calling the servlet's destroy method. Finalization is discussed in Finalizing a Servlet.

Java web application

Figure 2-1 Java Web Application Request Handling

Servlets are best suited for service-oriented applications (web service endpoints are implemented as servlets) and the control functions of a presentation-oriented application, such as dispatching requests and handling nontextual data.

JSP pages are more appropriate for generating text-based markup such as HTML, Scalable Vector Graphics (SVG), Wireless Markup Language (WML), and XML.

DD web application deployment descriptor

The process for creating, deploying, and executing a web application can be summarized as follows:

Develop the web component code.
Develop the web application deployment descriptor.
Compile the web application components and helper classes referenced by the components.
Optionally package the application into a deployable unit.
Deploy the application into a web container.
Access a URL that references the web application.