Alastair Calderwood

Dhiren,

Petstore does seem confusing... I think that what Petstore calls the Web Controller is actually the BD, and the EJB Controller is the facade. The point of this BD is that it simplifies access to services on a different tier, i.e. allows the web tier to access the session facade and POJOs on the business tier.

Another point... the diagrams showing VLH are (over?)simplified as they only show what happens in that particular pattern, not the patterns it relies on such as BD, or the relationships between them. So when you see "Client" in the Petstore Catalogue diagram, IMO it just means any incoming call from the client's direction, which could be from a BD or a JSP or anything.

I think Petstore relies on a framework (WAF) where modules are treated as a black box, and it only describes a few design patterns where the WAF has been extended in an application-specific way. For SCEA I want to show the design patterns in detail and then factor them into modules at the end - but either approach works. I just don't think Petstore is always the best place for detailed examples of using patterns.

Alastair

Dhiren,

VLH can either be a POJO or referenced by a SFSB. The helper could either be the VLH or locate a VLH-SFSB via Business Delegate, as Deepak said. The bottom line is that if you are likely to click on what you want in the results you get (i.e. view=results) it will probably be a POJO, but if you need to refine the search further it will be a SFSB. I suppose for FBN both of these have arguments for and against.

The difference between the two is in the Blueprints, see

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html

Java Object Strategy

The ValueListHandler can be implemented as an arbitrary Java object. In this case, the ValueListHandler can be used by any client that needs the listing functionality. For applications that do not use enterprise beans, this strategy is useful. For example, simpler applications may be built using servlets, JavaServer Pages (JSP) pages, Business Delegates, and DAOs. In this scenario, the Business Delegates can use a ValueListHandler implemented as a Java object to obtain list of values.

Stateful Session Bean Strategy

When an application uses enterprise beans in the business tier, it may be preferable to implement a session bean that uses the ValueListHandler. In this case, the session bean simply fronts an instance of a ValueListHandler. Thus, the session bean may be implemented as a stateful session bean to hold on to the list handler as its state, and thus may simply act as a facade (see "Session Facade" on page 291) or as a proxy.

Dan,

Thanks, I agree that we don't need a thread to clear seats. However this type of seat is not freed *only* by a user action because a session timeout would also require seats to be freed. In fact session timeout can be handled by the SessionListener, just like closing the browser.
Alastair

Prakash hello

It might help to say that a SLSB method is similar to a Java static method in that you just provide an input and get an output, but don't ever store class attributes. (The analogy ends here though, as SLSBs have less overhead whereas static methods are not very efficient). It is suitable for simple input-output processing where data doesn't need to be saved, whereas a SFSB method is used where the data might be needed by other methods or classes later, after the method you are calling has returned.

Hope this helps.

Alastair

As you migh think, Games' data are hardly managed by databases

Actually there is an exception to this rule. Advanced chess games use databases to look up board positions and see how they were played in the past.

Alastair

Josep,

I saw an example where they accessed the DAO from a SFSB; so:
SFSB->DAO
Does not this also solve the caching?
The sfsb acts like a sort of shopping cart

Is there a problem in that SFSBs can't be pooled whereas SLSBs can? The overhead of creating a SFSB for each search might slow it down if the server has reached its capacity, so it seems less scalable but that might be countered by caching results in the SFSB.

Alastair

Now I have to choose between optimistic and pessimistic locking. Optimistic is more efficient, but there is the risk that someone can go to pay for a seat thinking that they have it and then find that it has already been taken. Even worse it might be the last seat on the flight, so the flight wouldn't be available.

So it seems that a seat has to be locked as soon as it is chosen (pessimistic). I wanted to use a TO for seat but locks will have to be persisted because if the server crashed, session state would need to be restored. That means I'll need to create a SeatEJB only for holding the lock, but that is very resource-intensive and seems to be overkill.

Anyone any ideas?

Alastair

Why only calculate the additional payment for the segment?

Can't you just calculate the total cost of the itinerary again and then calculate difference. You won't need an alternative flow this way...

It sounds like its just normal practice in e-commerce. The reason is that in most airlines, prices change all the time and so you only pay again for the segment you are changing.

It doesn't seem to matter for FBN because prices are fixed but they might decide to change that in future. They would want your system to handle that without re-developing the booking system.

Thanks Deepak. It seems to make more sense to use ServiceActivator (SA) to unlock seats, but I can still see a problem with users who choose a seat but never log in, then just end their session by closing the browser or whatever. These seats would be locked until the next daemon thread was scheduled. Ideally I'd like to use SA to free these seats quickly after the session ends by activating a freeSeat() service.

What do you think?

There is a potential problem booking seats in the prepare itinerary use case. If a customer chooses a seat and takes a long time to pay for it, someone else might quickly choose it and pay for it. As other people have said, it makes sense to lock the seat as soon as it is chosen and keep it locked for a given period, so that it is only available for that session. I agree but my problem is how?

Does it make sense to use Service Activator pattern for this? So, a servlet on the web tier (or in the Swing application) creates a Request message object as soon as the customer chooses a seat and sends it to the ServiceActivator listener on the server, which then activates a lockSeat() method in some order processing session bean. If this method can lock the seat (i.e. that seat is not locked or booked already) it does so and sends the client an acknowledgement. If the client doesn't get this message after a certain time, it just assumes the seat is locked.

Using JMS like this risks showing seats as locked just because of delays in sending messages, but there is also the requirement for fast response times which counts in its favour.

Any opinions?

Sorry, I read the Sun design paper properly and now I understand what you mean. If you use CM authentication, you have to use CM self-registration, but this is platform-specific.

I think self-registration is still needed as it's a requirement for a web-based application, but that means that registration and authentication have to be coded, as you said.

I thought of these solutions:

1. write EJBs as above
2. use a J2EE pattern, e.g. Intercepting Filter which is for decorating processes with services like security - see

http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html

3. specify container-managed auth/self-reg as architect, and leave it up to the developers to sort out the platform-specific problems - it wouldn't make you very popular in the real world but it's only an exam...

Any ideas?

Thanks. Yes, container-managed authentication would be form-based. But I don't quite understand why you would need an admin to configure the username. You could write an EJB to handle user self-registration, and a JSP where the user could choose the username, provided it didn't already exist. Registration (unlike authentication) would not be container-managed, but does that mean that you need an admin?

If a user books through the travel agent, the agent's client app. could instruct another EJB to generate a user-name and password and (optionally) send these to the user's email address. The travel agent wouldn't need these to log on, but the user might need them if they later wanted to change the itinerary from the website.

What do you think?

Alastair

Hi,

You could use container-managed authentication, so long as you stated in assumptions that FBN is going to use the same application server for a while (quite reasonable, but it might be seen as reducing maintainability).

If you want to do it yourself, one way is to put customer authentication for the web-based application in the business tier with a UserSignOnEJB, which checks in a user credentials database, as in PetStore. The travel agent's thick client would use a StaffSignOnEJB checking a staff database and then grant access to any customer's account. It makes sense to have different components for user and agent as apart from their different roles,factors like timeout period need to be different for each

Just some thoughts, I haven't started this part yet.

Alastair

Hi Francis,

I just saw this -it's really good, I'm going to print it out. Thanks for telling us!

Any chance of one for J2EE design patterns (only joking!)

Alastair

There is a little trick - you multiply by 10^n where n is the number of decimal points you want, add 0.5, take integer, and divide result by 10^n. E.g. try this,

public class Rounder {
public static void main(String[] args) {
double n = 6; //no. of decimal places
double x = 123.12345678901234; //no. to be rounded
double y = (int)(x*Math.pow(10,n)+0.5)/Math.pow(10,n);
System.out.println(y); //result
}
}

Hope this helps,
Alastair