Yuanfang Cai

Assistant Professor

Dept. of Computer Science

Drexel University

CS575: Software Design

 

Professor: Yuanfang Cai

E-mail: yfcai AT cs DOT drexel DOT edu

Office: University Crossings 104

Phone: 215-895-0298

 

Teaching Assistant: Sunny Wong (sunny.wong AT drexel DOT edu)

Online Office Hours:

     Place: BbVista

     Time: Tuesday 6pm-8pm and Wednesday 7:30pm-9:30pm

(Or by appointment)

 

Class Position Paper

Description

For this class you will be expected to work in a small team to develop a 4-page position paper on a topic related to the concepts and material that we cover in class. The paper must clearly define your topic and survey some of the related work that has been done in the area that you are investigating. Your position paper must put the related work that you are referencing into some sort of context and outline one or more interesting problems or trends related to your topic of choice. In other words, just don’t create a readers digest (tm) summary of the papers that you select.

You must secure at least 4 references related to your topic, two of which must come from refereed sources such as the ACM or IEEE. The other references may come from online sources such as IBM’s developer works, Microsoft’s MSDN site, or some other generally accepted reputable industry publication.

A good reference for how to write a position paper can be found online [here]. This website states: "A position paper presents an arguable opinion about an issue. The goal of a position paper is to convince the audience that your opinion is valid and worth listening to. Ideas that you are considering need to be carefully examined in choosing a topic, developing your argument, and organizing your paper. It is very important to ensure that you are addressing all sides of the issue and presenting it in a manner that is easy for your audience to understand. Your job is to take one side of the argument and persuade your audience that you have well-founded knowledge of the topic being presented. It is important to support your argument with evidence to ensure the validity of your claims, as well as to address the counterclaims to show that you are well informed about both sides."

Locating References

There are many ways to locate references, the best way might be to simply use Google to identify, and in most cases, obtain electronic versions of the papers that you will need for references. Other sources include using CiteSeer (http://citeseer.ist.psu.edu/cs), or the ACM/IEEE online portals available through the library references after you authenticate to DrexelOne.

STEP 1: Develop an Extended Abstract

The first thing you need to develop and submit is an extended abstract. Your abstract should define the problem that you are investigating, and provide your list of references. A sample extended abstract is below.

**** SAMPLE ****

Extended Abstract: On the Need for A Single Reliable Messaging Standard to Implement Service Oriented Architectures using Web Services

Service-Oriented Architectures (SOAs) are often instantiated as enterprise applications using a collection of interoperating Web Services. The message is a critical aspect associated with the successful implementation of SOAs using Web Services. The current state-of-practice of Web Service infrastructure implementations (e.g., .Net and J2EE) relies on existing communication-oriented protocols to transmit messages between the application and web service boundaries. There are several problems with this approach. First, the most popular protocol used for these purposes, HTTP/HTTPS, is stateless and does not offer guaranteed delivery. Other protocols based on message oriented middleware (MOM) can support reliable delivery requirements but implementing web services using MOM is more complex than HTTP/HTTPS since they introduce an asynchronous programming model where the developer needs to handle correlating related messages, and ensure that Quality of Service (QoS) requirements are satisfied manually. Unfortunately, the current Web services architecture places most of the onus for implementing the reliable delivery of messages securely, within the performance requirements of the application, on the application developer.

One of the principle benefits of using Web Service technologies to implement an SOA is that Web Service technologies are governed by community developed and public reviewed standards. These standards are implemented in products to ensure that applications implemented with Web Services can interoperate. Unfortunately, there are two mainstream standards to address the abovementioned problem which leads to overall confusion on how the future will unfold with respect to the reliable delivery of messages using Web Services. This paper examines the two competing standards, WS-ReliableMessaging (WS-RM), and WS-Reliability (WS-R) and argues for the need to consolidate these standards so that developers can move away from rolling their own reliability code for web service messaging and instead rely on the Web Service enabled application server containers to facilitate this important capability.

References

Stefan Tai, Thomas A. Mikalsen, Isabelle Rouvellou, "Using Message-Oriented Middleware for Reliable Web Services Messaging Web Services", E-Business, and the Semantic Web, Second International Workshop, WES 2003, Klagenfurt, Austria, June 16-17, 2003.

Linhua Li, Gang Zhou, Shilong Ma, "Reliability and Efficiency of Messaging Mechanism in Web Services", Proceedings of the Design, Analysis, and Simulation of Distributed Systems Symposium (DASD'04), 2004.

Davis, D., "WS-RM and WS-R: Can SOAP be reliably delivered from confusion?", IBM DeveloperWorks, http://www-128.ibm.com/developerworks/webservices/library/ws-rmpaper/

IBM, BEW, Microsoft, TIBCO Software, "The WS-ReliableMessaging Specification", http://www-128.ibm.com/developerworks/library/specification/ws-rm/

OASIS, "The WS-Reliability Specification", http://www.oasis-open.org/specs/index.php#wsrv1.1

 

STEP 2: Develop your Position Paper

The final two weeks of this class will be dedicated to holding an in-class workshop to discuss your position papers. I will follow the general IEEE guidelines for workshop papers by limiting your paper to a maximum of 4 pages in length (using a 10 point font). This is not a lot of space so you will be graded on the quality and focus of your paper. In a traditional IEEE workshop, papers, including position papers, are reviewed for quality prior to being accepted for discussion. Please don't ramble your way through 4 pages of text ---place some thought on the organization of your paper.

Teams

The position paper should be written with your project team members.

 

"The best way to predict the future is to invent it." ---Alan Kay.

"Fundamental is the building block of fun." --- A dancing girl.