Skip to content

Middleware

Sections
Personal tools
You are here: Home » Inf3320 » Programming exercises
Blog
No blog entries are published.
 

Programming exercises

Document Actions
The middleware course programming exercises

Introduction

There are three programming exercises for the middleware course. The first two are mandatory, while the last one is optional. Individual solutions for each exercise should be submitted within the corresponding deadlines. For each exercise, the submission should include well-annotated code, and a detailed document on how you build up the environment, your design of the problem scenario (if applicable), implementation method and test result. The file can be in either English or Norwegian.

These exercises can be solved using different middleware platforms, such as Microsoft .NET, J2EE(Java RMI or EJB), OMG CORBA, OOPP, among others. You are also free to choose the implementation language and developing environment. For example, with CORBA, you can choose a language from Java, C++, Python, etc, and an environment from IONA Obix, Borland Visibroker, or others.

Although you can make use of a database (e.g. MySQL) in some of the exercises, it is not required. In case of need, a simulation with a file system is quite acceptable.

Exercise discriptions

1  Basic experience with object-oriented middleware (deadline for submission: 18.02.2005)

The first exercise concerns a simple dummy banking system, which includes a client and a remote server. This exercise is mandatory.

On the server side, an interface with a method create should be made available. This method takes one argument, a text string containing a user name (account name). It returns an object reference (or an interface reference), which provides access to a set of methods that can be used to manipulate an account of the user. These methods includes:

credit   Insert a given amount into the account
debit   Remove a given amount from the account
status   List current amount on the account

So two types of interfaces should be made available on the server, one for creating accounts, the other for manipulating accounts. You should also find a way to bootstrap the application, that is, how does the client get access to the interface providing the create method (For example, use RMI registry if you are using Java RMI, or JNDI naming service if you choose to use EJB).

On the other side, the client should first get access to the interface with the create method, then use this to create an account object, and finally operate on the new account (perform the credit, debit and status operations).

The client and server may be implemented using either same or different programming languages.
 

2  Ad hoc aspects of middleware (deadline for submission: 25.03.2005)

The second exercise deals with two ad hoc aspects, or patterns within the context of middleware.  Both parts in this exercise are mandatory.

2.1  Transfer of object

This is a pattern in the middleware platform often used when application clients need to exchange data with the server. The reasons for using it can be:

  • The client usually requires values for more than one attribute or dependent object from a server. Thus, the client may invoke multiple remote calls to obtain the required data. The number of calls made by the client to the server impacts network performance, since chatter applications -- those with increased traffic between client and server tiers -- often degrade network performance. The Transfer-Of-Object pattern is used to reduce the number of remote calls and to avoid the associated overhead.
  • In other occasions, the client user may want to do a number of operations upon the data of the server in a given period when she might be disconnected from the network (and the server).

The requirement of this practice is to construct and transfer an object (on the server side) to the client, and later back to the server. Specifically, suppose the banking system in exercise 1 also keeps track of the personal information of all of its customers. So that when a customer wants to update her information, the server will be responsible to transfer an object containing name, personal number, address, phone numbers (at work, at home, and mobile), etc., to the client side. Then the customer will update those information and transfer them back using the same pattern.

For more illustration on the Transfer-Of-Object pattern, refer to the helper materials below.

2.2  Transactions

Transaction is an important pattern within the middleware platforms. Transactions provide an "all-or-nothing" property to work that is conducted within its scope, also ensuring that shared resources are protected from multiple users. In case of failure, the transaction system will recover the system and guarantee the consistency of system state.

In this practice, you are required to implement a transaction application by using corresponding transaction service of the middleware platform you have chosen. Suppose a bank transfer scenario, where a customer of the banking system wants to transfer 6000 krone from her CurrentAccount to her SavingsAccount. This will typically occur in the following steps:

(1). Read the amount of money in the CurrentAccount to determine that there are enough funds to transfer;
(2). Debit 6000 krone from the CurrentAccount;
(3). Credit 6000 krone to the SavingsAccount.

The transaction system will guarantee that either all of these operations will be successfully committed, or none of them. In case of failure for any reason, the transaction will automatically rollback the system to the original consistent state.

Please note that you are not supposed to implement the transaction system yourself, but make use of the transaction service provided by the middleware platform. However, the minimum requirement is that a user-managed transaction should be provided, that is, use "begin/commit/abort" to demarcate programmatically the boundary of transactions in your program. For example, in the EJB model, bean-managed transactions (using the UserTransaction interface) meet the requirement, while the declarative container-managed transactions do not.

For more illustration on transaction processing, refer to the helper materials below.
 

3  Experiment on reflective middleware or AOP (deadline for submission: 29.04.2005)

The third exercise is optional. If you are interested, you can choose to fulfill one of the following experiments:

(1) Reflective middleware

A reflective system is one which offers a meta-interface providing open access to the internal structures and operations. These internal structures and operations should provide a complete and causally connected self representation of the computational process.

Choose one of the currently available reflective middleware platforms, such as: OOPP ( Python ), OpenORB ( Python ), OpenCOM ( C++ ) and QuA ( Java/Smalltalk ), etc., design and implement an experiment based on the platform and show the reflective feature. Use the links provided in the helper materials.

(2) Aspect-Oriented Programming (AOP)

Aspect-Oriented Programming (AOP) is a technique to design and code crosscutting business concerns. AOP is an additional technique, rather than a replacement for Object-Oriented Programming (OOP). While OOP addresses common concerns, that is, attributes and behaviors common among related entities are captured on top of a class hierarchy, AOP deals with unrelated items, trying to modularize their common attributes and behaviors in a software layer that spreads across classes regardless of domain, thus increasing modularity of software.

Choose a middleware platform that provides AOP support (such as JBoss version 4), and use examples to show the concepts of interception (to add further processing to certain locations in a system) and introduction (to add further behavior to an object).

Helper Materials

Created by wang
Last modified 2005-01-17 09:05
« November 2007 »
Su Mo Tu We Th Fr Sa
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
 
 
Powered by Plone

This site conforms to the following standards: