The Simple Messaging Framework

The Simple Messaging Framework provides an elegant way to create robust and flexible Web services. It is based on the document-style Web services paradigm that uses the full power of XML Schema. This approach enables you to expose arbitrarily complex business objects and services with ease.

Let us look at a simple example to understand the benefits of the Simple Messaging Framework. Imagine that you were tasked to write a Web service that enabled your colleagues as well as customers to schedule meetings among themselves. Your company already has a calendar application that allows users to schedule meetings. All you need to do is to expose its MeetingService API as a Web service. This API is shown below.

package org.calendarapp.meetingservice;
public interface MeetingService {
    public String createMeeting(Meeting meeting);
    public Meeting getMeeting(String meetingId);
    public void addAttendee(String meetingId, Attendee attendee);
    public void removeAttendee(String meetingId, String username);
    public void deleteMeeting(String meetingId);
}

The Meeting class used in this API is shown below. Notice that this class contains a map of attendees. This map associates usernames to Attendee objects.

package org.calendarapp.businessobjects;
public class Meeting implements Serializable {
    private String meetingId;
    private String subject;
    private String location;
    private Date startTime;
    private Date endTime;
    private String organizer;
    private String body;
    private Map attendees;
    ...
}

Now suppose you use tools such as Java2Wsdl and WsdlToJava (provided by several SOAP toolkits) to generate your Web service. Such tools generally use one of two approaches to transmit maps:

• Transmit the map as a single SOAP array, each element consisting of a key and a value.
• Transmit the map as two SOAP arrays, one containing the keys and the other containing the values.

Realistically speaking, both approaches usually have some problems. Sometimes the solution is not interoperable with other toolkits. In other situations, the toolkit may force you to abandon maps, ignore them completely or even convert them to Java arrays! Now, as you know, the Java array is not a very flexible data structure. You waste a lot of time iterating through it, searching for objects. So what do you do? May be you can translate the object returned by the toolkit into a very similar one that uses maps. However that's more work for you, it is not very elegant and, since the translation must be done at run time, not very inefficient. The problem gets worse as the data structures become increasingly complex and the volume of data starts increasing. Is there a better way?

To understand the second problem, assume that you have successfully exposed the MeetingService API as a Web service. Further assume that you have created a meeting on the server using the createMeeting() call. However now you want to update the meeting to add ten attendees and and remove two. What are your options? The easiest one, of course, is to make ten addAttendee() calls and two removeAttendee() calls. However, since making a connection to a Web service is expensive, making 12 connections to accomplish this would be very inefficient! Your other option is to extend (or modify) the MeetingService API to add two new calls, say, addAttendees() and removeAttendees(). Even then, you would have to make two separate calls to get the job done. And, by the way, the IT department just informed you that you are not allowed to make any modifications to the MeetingService API. What do you do now?

Now that you know what the Simple Messaging Framework has to offer, you have several options to explore it further. Here are a few suggestions.

• Understand the framework's Architecture.
• Go through a step-by-step Tutorial to implement the MeetingService API introduced in this document.
• Build and run the demo programs supplied with the framework (Meeting Service Demo, Library Management Demo).