Find JSRs
Submit this Search


Ad Banner
 
 
 
 


Star Spec Lead Profiles

 
 
The Java Community Process (JCP) program applauds the community's Star Spec Leads. These leaders earned this honor through their efficient, prompt, and transparent communication with their Expert Group, the Program Management Office (PMO), and the Executive Committee (EC). They used community web pages, observer aliases, and other tools to communicate with their expert group, the JCP program community, and the public. They kept their Java Specification Requests (JSRs) on schedule by making sure their team stayed focused and felt appreciated. The JCP program congratulates and honors these Star Spec Leads.

Nasir Khan
At BEA Systems, Nasir Khan is the architect of the Weblogic SIP Server, based on the Internet standard called Session Initiation Protocol (SIP). He has contributed to several projects in Java Standard Edition (SE) and Java Enterprise Edition (EE), which focus on building the container architecture. Most recently, he built a SIP Servlet container.

Curiosity Morphs into Intense Interest
Around 1998, Nasir's interest in Java technology was sparked when his brother-in-law, also an engineer, demonstrated the power of Java workshop in writing code in the new language. Nasir then began playing around with Java technology out of curiosity, building applets for fun. Two years later, he joined the Java Community Process (JCP) program and moved from being a member to joining an Expert Group and becoming a Spec Lead. He has also gotten more serious about his Java projects, which have ranged in sophistication from GUIs to network programming and touched on many technologies in between, including highly complex, distributed Java servers. Today he has an intense interest in distributed systems, concurrency, Inversion of Control (IoC) containers, Aspects, and dynamic scriptable environments.

Nasir currently is the Spec Lead for Java Specification Request (JSR) 289, SIP Servlet v1.1, and a member of the Expert Group for JSR 309, Media Server Control API, which is led by BEA. He has had to be creative to keep the JSR 289 work moving forward in an efficient, productive manner, and he appreciates being honored by the Star Spec Lead program. "It feels very good when the hard work you put in is acknowledged," he says.

Several Channels of Communication
He makes use of several channels to communicate with his Expert Groups, both of which are fairly large, with more than thirty members. The email list is the primary vehicle for Expert Group communication. The group also uses a Wiki and Google Groups page, and shared files are uploaded to the website jcp.org website. Nasir says that group conference calls and face-to-face meetings (three in the past year) are also held occasionally to "accelerate the process" of discussion and decision-making.

The Expert Group keeps highly interested community members and other individuals, called "observers," informed through another email alias. "Before the advent of the new jcp.org there really wasn't a simple way to address questions and concerns from the public, particularly when the spec was in EDR or a later phase. So we resorted to a public mailing list and have a very heavy community involvement in that forum," says Nasir. Community discussions of JSR 289 take place at http://groups.google.com/group/sipservlets. Such transparency is vital for the good of the technology. The Expert Group members have access to all of the group proceedings, and now that the specification is at the Early Draft Review (EDR) stage, a lot of the pertinent discussions happen in the public forums.

Nasir makes sure the Program Management Office (PMO) stays in the loop for any Expert Group changes or schedule updates by copying pmo@jcp.org on all important Expert Group announcements. He know that being proactive in this area smooths the way for everyone. If an issue is brought up by the PMO or Executive Committee, he says, "I try to address any concerns at the earliest possible opportunity, including any administrative action within the group," such as what is necessary when an Expert moves on to a new job, and the company wants to replace their representative.

Because member representatives, observers, and developers wait eagerly for innovations that can impact the market, JSR schedules are important. However, schedules can be accommodated as long as everyone stays informed. Nasir says, "So far we have been able steer this big group in a coherent manner towards a mutually agreed specification while keeping our schedule largely on track. Although there have been some minor adjustments to the JSR 289 schedule, we have been upfront about updating the schedules both on the JSR main page and the community update page."

New Conventions for a Daunting Task
When work on JSR 289 began, the Expert Group faced the daunting task of managing more than 100 new requirements, which in some cases involved major architectural decisions. Nasir organized a methodical approach to manage the complexity, establishing new conventions to help the Expert Group maintain focus through the maze of requirements. First, each requirement was assigned a number and called a "Proposed Requirement" or PREQ for short. Next, they held debates on each requirement to decide which would be included as features in the specification. If a requirement was agreed to be a feature, it was renamed "Finalized Requirement" or FREQ, assigned a new number as an aid in tracking progress, and detailed in a brief document.

A typical FREQ document included sections such as "Author(s)," "Version History," "Abstract," "Description," "API Changes," "Security Implications," "Backward Compatibility Implications," "Test Cases," and so forth. Nasir says, "Having a uniform format for the FREQ document helped us to methodically answer various problems and not miss out on any aspect." Emails pertaining to a FREQ document would carry the FREQxxx number in its subject line to tag the conversation threads easily. Each FREQ document became the central place to record discussions and decisions for later reference on the topic it represented. Ultimately, the big payoff was that the FREQ documents became a source for the actual specification document and Javadoc APIs.

Outside of Work
Nasir has a master's degree in Management and Systems from Indian Institute of Technology (IIT-D) and a bachelor's degree in Electrical Engineering from Indian Institute of Technology (IIT-R). He calls India, Canada, and the US home. He enjoys photography, reading, and, of course, traveling.

Go to the Star Spec Lead Program page for more information.
 
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .