Win a copy of Spring Boot in Practice this week in the Spring forum!

Dan Huskins

+ Follow
since Dec 29, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dan Huskins


By action i just meant the user clicking a button or link. Seems like each 'click' would represent a new web container thread; each thread would require a new SLSB.

In Cade's book (p174), he shows the stateless session bean SearchProcessor in a sequence diagram getting created through a ServiceLocator. However, he only shows it getting created one time, rather than each time the customer creates an action.

Any thoughts on this?
Thanks Albert.

My brain has been transfixed upon this caching problem for some reason... it's difficult to move past.
I want to implement a caching mechanism on the business tier, perhaps with a Value List Handler.

Couple of questions:

1) I've got my class diagram, more or less, at the 'specification level' (Fowler's UML Distilled). I'm doing my best to keep it technology independent. But, leaving out certain information, such as what type of caching i'm implementing seems to add confusion to the diagram rather than make it simpler to read. How are people handling this? Are you specifying stateless and stateful components, facades, caching, etc in the class diagram? Or is it more 'conceptual'?

2) The J2EE blueprints docs on VLH do not seem to handle multiple threads accessing the cache simultaneously, which would be the case for a common cache. I can think of several good solutions, but i'm not sure of the detail in which i need to address this.

Any help is appreciated. Thanks.
Can anybody shed some light on any differences between Value Objects and Transfer Objects?

These terms sometimes appear to be used interchangably; sometimes not.
Another Jude question: Is it possible to show general descriptions between objects in a sequence diagram rather than specific method names?

I'm trying to keep my sequence diagrams somewhat generic instead of naming all the objects and methods in the conversation.

Also, anyone see any problems with this approach?
Perhaps this will help. At my company, it breaks down like this:

IBM HTTP Server (repackaged Apache) serves only static content (no JSPs)-- content that is perhaps broken out from an EAR file. The HTTP server can be configured (httpd.conf) to provide plug-ins directly to WebSphere Web Containers based on URL. These plug-ins connect between started tasks-- they are not forwards or html redirects. A pool of Servlet threads waits inside the Web Container for these requests that get initiated across tasks.

Web Container-- comprises a JRE (and some native programs) which can serve both dynamic and static content (static content that is perhaps left in the EAR file). I guess you could subsume the term 'Web Server' under this container executable (as opposed to an HTTP Server); although in 6 years i've never heard anyone make this distinction-- it's usually HTTP Server v. Web Container.

EJB Container, etc are separate physical instances of other executable programs (tiers).

Keep in mind that we run everything on one monster computer here that handles 10s of millions of transactions a day. load-balancing etc is handled by multiple processes on the same machine... not multiple machines.
I don't think it will harm you to go through the SCEA or any other certification process. You can always leave it off your resume if you start to get the feeling from employers that it comes across as too overreaching.

From a practical standpoint, SCEA is really more of an enrichment process for people who have been working in software for several years. With enough preparation, though, you can easily pass it without any experience. However, I think many of the concepts are more useful to people who have a lot of work knowledge that they need to consolidate.

I would recommend spending your efforts learning a new, and more lucrative technology that would help you get your foot in the door at a company (and be popular among your coworkers). As a bargaining chip, this would be more powerful for you. Coming from a guy who interviews people all the time, the SCEA without comparable experience (6-10 yrs) is likely to be glossed over.
Has anyone played around with the entity relationship-approach to modelling the BOM or parts of it for Part II? If you're not familiar with it, you define the relationships (1-1, 1-*, etc) between EJBs in the schema.

I used it in a project recently, and it proved to be pretty powerful. It seems like it might be a good way to model the objects dealing with a customer/account.

I like the idea of having 'reserved' seats and 'purchased' seats. For external users, 'reserved' seats are locked for the duration of a the user's HttpSession. When the SessionListener notifies the Web tier of an invalidated session, unpurchased 'reserved' seats are freed. For internal users (Travel Agents), 'reserved' seats last until the agent explicitly removes them, finishes the transation, or closes the application. This can be implemented in a variety of ways (SFSB, an object that holds reserved seats, etc), and do not require a thread to remove them because each action that removes reserved seats requires some sort of GUI action on the client (including closing the app).
Each of those seems viable. It seems that we may be exposing a weakness in J2EE with handling self-registration-- stuck between coupling the solution with a vendor and customizing the solution with code.

Although I haven't really analyzed it yet, I'm thinking that a combination of standard filter strategy (intercepting filter) and a signon EJB might work. The I.F. approach would give you the ability to delimit the sections of the site which require login from those that don't-- and also accept different post types, which would allow users to bookmark sections of the site or email them.

I'll think through it, and post my thoughts later. Let me know where you get with it.

Thanks. But, this is what i'm a little unclear on. I think you mean container-managed authentication is the web-tier authentication-- HTTP Basic, Form, HTTPS Mutual, and HTTP Digest-- being configured within the <auth-method> of the deployment descriptor. If you use <auth-method>FORM</auth-method>, you must use these form variables:

<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">

And the corresponding username would still have to be configured by an admin. I suppose you could use a generic username for all external users, but wouldn't you still have to either write a specific EJB to handle new registering users or use some sort of proprietary self-registration system?

Sun's documentation draws a distinction between administrator setup and self-registration for adding users to a system for authentication. The former requires an admin to enter all of the details for each user, whereas the later allows a user to register himself. Sun says this about self-registration, which could correlate to external user's registering in Part II: "...self-registration mechanisms provided by J2EE platforms are platform-specific." Sun doesn't go into any detail about how to implement self-registration, but warns about putting SR into the application code.

If this is true, it seems like we're stuck between using a platform-specific self-registration system and writing code to process a form post and implementing security on our own. Any thoughts?
For what it's worth, I have a friend who is a pilot for Delta. From what I understand, Flight Numbers (associated with a Flight) are assigned by an outside entity for all commercial flight. A Flight Number normally correlates with a particular departure and destination city at a particular time of day. So, for instance, flight 337 may depart at 9:05am on Mon, Wed, and Thu of any given week for an Airline. Consequently, a flight number can be executed with multiple types of equipment.

So if an itinerary contains a layover, it would contain multiple flight numbers, and it would be associated with a particular date and time.

From what i can tell, a real-world flight system is beyond the scope of this project; it's probably best to define it one way or the other and stick to it.
Can someone give me an idea as to how intricate our EJBs, DAOs, and various business-related objects need to be for the assignment?

I have read quite a bit about the J2EE patterns and approaches, and I believe I understand how to solve most of the requirements at a conceptual level using these approaches. However, the more I scrutinize the Business Domain Model, the more slippery it becomes.

For example, I have perused real flight systems, such as Delta and American Airlines, and found that flight numbers correlate only with a time of day (not a particular date) and only on certain days of the week, and can be associated with different types of equipment which in turn have different flight times and arrival times. This fact alone, not to mention others, creates a rather complicated set of data when you attempt to map, say, an entity bean to real data representing times, distances, etc. It creates an intricate and complicated interaction of EJBs, etc that doesn't create the sort of simple mapping i was hoping for (such as a Flight has just a destination and an arrival on a particular date and time).

Is this level of detail required?