Reference no: EM131594815

Project Description

Suppose you are a linguistic working at an e-books distributor. Your management has interest in finding out if commonly used words used in a book make the books more popular, therefore more books would be sold if the number of commonly used words in the book is higher.

For this project you are required to write a client/server program and perform popularity checking. The client will take the input (the document to be examined), and deliver the input to the server program. The server will take the input from the client, perform the three operations from the input, and deliver the results back to the client. The client will then display the results.

The three operations performed by the server program will be the following:

Word Count: Counting the total number of words in a document.
Word Rank: A ranking of all words appeared in a document.
Word Repeatability: Counting all words for the number of time they are used in a document.

An example of word rank is shown as follows. This is a list of top 10 commonly-used English words. The word rank provided by your server program may not be the same as this as it will depend on the input.

Rank Word

1      the

2      of

3      to

4      and

5      a

6      in

7      is

8      it

9      you

10  that

You will use the test document below to test the three operations of your program.

"Message-oriented choreography

The Paper Trail concept is that the state of a multi agent multi-process system can be looked at, sometimes rather effectively, as a function of the documents which have been transmitted.

The process-oriented attitude to a bank-customer relationship may be "In parallel, the customer writes checks, merchants pay in checks, credit card transactions happen, all month. Then, the charges, interest are assessed and a bank statement sent from the bank to the customer". The document-, or message-oriented one is more like "Every month a bank balance lists valid transaction dated that month. A cleared incoming check in a valid transaction. A cleared outgoing check is a valid transaction. A validated credit card ebit is a valid transaction. A check is cleared if it is incoming and there is a matching transfer from the payee bank", and so on. This builds the relationships up in a bottom-up, web like way. The process-oriented attitude suggests the bank be written as a procedure in a top-down way using for example WSCI and BPL. The document-oriented attitude suggests the use of business rules systems triggered by the receipt of new information -- new documents, in this case new web services messages.

(Web service messages are of course documents just like documents sent in email. Messages are particular in that they have a particular time of transmission, and their document content does not change. They do of course generally have identifiers, and even though they can only be accessed by sender and explicit receivers, they can still be regarded as part of the web by those parties.)

Whether the design process is a top-down process-oriented one or a bottom-up documentoriented one, the design will have to be translated into a set of agents and their responses to incoming messages. This manipulation can of course be done automatically.

A concern in all this frantic design is it evolution with time. A BPEL script sets out to be a description of a business process at a high level. The critical values which decide on conditional execution, or which correlate a particular process with a given transaction, are expressed as parts of the structure of the XML messages. This may lead to what has been called "DTD fragility". What happens which you change the DTD? The design of the message types with XML schema is the sort of thing which is difficult to get everyone in a company to agree on, and tents to change with time. There are many arbitrary choices made as to how the knowledge in the message is serialized as XML. Moving to RDF may, by removing a layer of arbitrary design, reduce that fragility and allow web service choreography to evolve with time within and outside a company."

Implementation based on web services

With this option, your job is to create a web-services application to program your client/server application. Prior to working on the project, make sure you clearly understand chapter 1 terminology, it will allow a much easier implementation of this project. Web Service is made up of the basic core services, HTTP/JMS/SNMP, XML, SOAP, and WSDL. There is also UDDI which is used for service location, although not necessary of this project. This project will be an implementation of these basic services listed above. Please refer to figure 4.1 to understand the process of message movement, section 4.4 for the communication models. For the understanding of WSDL please refer to chapter 5, figure 5.1 for an overview.

There are three component exercises that will help with your understandings of XML, SOAP and WSDL, as seen in Assignments 1 - 3.

Additional information

Error Handling:

There should be necessary error handlings in your implementation.

Development kits:

If you choose option 1, then there is no need for graphical interface, and both client and server should be tested under command-line mode. If you choose option 2, the GUI can also be optional depending on the IDE you use. If you choose to do so, you should use an IDEs such as Visual Studio, Netbeans, Eclipse, Java SDK or Java EE, or other toolkits that you are familiar with. Your coding may not require these development kits but sometimes they are helpful for coding and cohesion of the project.

Deliverables of the Project

1. A report that shows your design, your implementation, and your test cases. At a minimum, you should use the given text as a test case. You need to clearly show all important design decisions you make, key algorithms and data structures you used (if any), and the platform (e.g., software, hardware) based on which the system is implemented. You also need to show screenshots of the execution of your system.

In your port, you should explicitly report your test results (Word Count, Word Rank, and Word Repeatability) based on the test document provided above.

In addition you should have a list of references for any external reference materials you used (e.g., publications, websites, etc), and follow the APA format for all citations and references.

2. A working prototype of the system. You can use any programming language or IDE you feel comfortable with as long as you clearly report these details in the project report. Submit the source code along with instructions how to execute your system.

Note that the input (test document) and the output (results of the three operations) can be written in any of the following formats: XML file, plain text file, or system I/O. The system can be tested on a live web server, or on a simulated environment such as a local host.

3. Source code of both the client and the server.

4. Submit your project in a ZIP file to BlackBoard under the assignment, with clearly defined parts. Each deliverable must be clearly labeled, including your name and course title.

5. The "Certification of Authorship" form.