Where did the LDAP server come from? How is the system guaranteed to have a 99.99% up time?

[Behrang Saeedzadeh]

Hi fellas,

1- LDAP

I am reading the SCEA for Java EE Study Guide to prepare myself for the OCMJEA Part II exam. In the given scenario in Chapter 9, there's no mention of the company (JustBuildIt) using an LDAP server in their current systems at all, yet in the Component Diagram for the solution there are LDAP DAO and LDAP Server components in the diagram. Actually there's no mention of the system needing to be sending and receiving emails as well, but there's an Email DAO and Email Server in the diagram too.

How come is this an accepted solution? There's not even anything accompanying the solution explaining why the author has decided to use LDAP and email to build this system.

Now while these assumptions make sense in a general point of view, but they are still out of context assumptions.

2- Up time

A requirement for the solution is to have a %99.99 up time yet there's no reason why the given solution is able to be up %99.99 of the time. Also there's no reason why the solution can handle %95 of transactions in less than 5 seconds and the rest in 20 seconds or less while this is a requirement.

Any ideas and suggestions regarding these issues? Can our solutions really be this vague?

Thanks in advance,
Behi

[Rishi Shehrawat]

Authentication & authorization is an implied requirement that needs to be addressed. Although you can assume that is already avalaible & state it as an assumption. If you are addressing authentication & authorization requirements then LDAP is the preferred store for keeping user related information.

Email server is used to sending emails to winning bids. See the sequence diagram in figure 9-8.

Uptime is being addressed in deployment diagram by ensuring that there is no single point of failure.

I am not very sure how solution provided is helping in meeting performance NFR.

[Behrang Saeedzadeh]

Authentication & authorization is an implied requirement that needs to be addressed. Although you can assume that is already avalaible & state it as an assumption. If you are addressing authentication & authorization requirements then LDAP is the preferred store for keeping user related information.

Yes, but this assumes that it makes sense to use LDAP for this scenario. What if JustBuildIt is already using a non-LDAP system for AA? Just throwing in LDAP without any reasoning whatsoever doesn't necessarily make sense. But can we simply assume that LDAP makes sense in our solution, just like the authors have done for the JustBuildIt example?

Email server is used to sending emails to winning bids. See the sequence diagram in figure 9-8.

Right, but again it is assuming that the bidders should be notified by email. What if JustBuildIt wants to notify the winners using SMS instead? Note that my question is not about whether using email makes sense or not, but that it is something introduced to the system without no justification by the author. The question is, can we make assumptions like this without justifying it whatsoever?

Uptime is being addressed in deployment diagram by ensuring that there is no single point of failure.

My question was that the author has not given any justification whatsoever that using one hot standby Web/App server and one hot standby database server is going to guarantee %99.99 up time. It might be enough for that, yet it might only guarantee %99.95 up time. Also what if the only load balancer of the system fails?

I am not very sure how solution provided is helping in meeting performance NFR.

Okay, but considering that the authors of the book know what the exam is about, and as they suggest that the solution that they have provided is complete enough, does it mean that I can submit a solution that has only as much detail as the example given in the book? Or should I justify why my solution handles the necessary up time, SLA, etc.?

[Jeanne Boyarsky]

You can assume the company is using LDAP already - just document it in your assumptions.

If you haven't yet read our FAQ page on the book, take a look. There are a number of things where we suspect the solution as is has errors.

[Sharma Ashutosh]

Right, but again it is assuming that the bidders should be notified by email. What if JustBuildIt wants to notify the winners using SMS instead? Note that my question is not about whether using email makes sense or not, but that it is something introduced to the system without no justification by the author. The question is, can we make assumptions like this without justifying it whatsoever?

Ideally there should be a Customer preferences page- where he/she can input his/her choices like alert me via email, text message etc...
By default alerting by email is better as receiving email doesn't cost a dime to anybody in the world but receiving SMS can cost something - depends on where you are and from who is your mobile subscriber.

My question was that the author has not given any justification whatsoever that using one hot standby Web/App server and one hot standby database server is going to guarantee %99.99 up time. It might be enough for that, yet it might only guarantee %99.95 up time. Also what if the only load balancer of the system fails?

You can provide a pair of load balancer - active, hot standby to address SPOF issue.

Okay, but considering that the authors of the book know what the exam is about, and as they suggest that the solution that they have provided is complete enough, does it mean that I can submit a solution that has only as much detail as the example given in the book? Or should I justify why my solution handles the necessary up time, SLA, etc.?

As Jeanne mentioned, please go thru the FAQ. The book is for reference purpose-there are shortcomings and flaws in what they have done. One should use the book as a reference and extract from the book what he/she feels is good or reasonable. All architects may not be thinking alike-they might be having a lot of difference of opinion. What i will suggest-whatever you are doing-don't keep it with you-mention in the SuD. Then think about it from as many prospective as possible, discuss with peers and then reach to a conclusion but always mention your pros and cons about why a decision has been made and it's impacts.

[Michael Ernest]

It might help here to examine what 99.5% actually means and work out the implications that follow. Wikipedia's page on High Availability, for example, breaks 99.95% down to 4.38 hours/year, or 21.56 minutes/month, or 5.04 minutes/week of planned downtime. Depending on your system assumptions, then, you can allow for one, maybe two reboots a week on average, or one crack-the-box repair cycle a year, or something in between.

A cluster intends to resolve a loss of system availability in less time than it takes for a network request to time out, i.e., so a remote client doesn't feel the pain. That's 30 seconds, a number largely determined by network tolerance for losing a switch or router and finding a new path. A cluster, for a 99.95% availability requirement, seems like overkill to me.

Even so, HA systems only account for planned downtime, not guarantees against component loss. You could comfortably manage this requirement with redundant network cards and storage to factor out the mean time to repair/replace these components should they fail. You can count machine failure as a catastrophic loss and provide manual fail over to another server. It's quite reasonable to assume that the time from identification of failure to restoring availability shouldn't take more than a couple hours. And if you're planning for that event to occur once a year or more, you got bigger problems a clustered solution is only going to mask.

Keep in mind there's no such thing as guaranteed uptime. A service level like 99.95% is a tolerance for loss of availability. At some point, the cost of a true guarantee exceeds the value of the business processing that would take place. That's where the tolerance for failure goes way up. If you treat this NFR like a guarantee, you're bound to overengineer things.

[Behrang Saeedzadeh]

You can provide a pair of load balancer - active, hot standby to address SPOF issue.

Thanks for the reply, but please read my question before you post an answer. I didn't ask how we can solve that problem. I said that the given solution is wrong because the load balancer is a single point of failure and as such the given architecture is not providing %99.99 up time. Otherwise it's obvious that a second hot standby load balancer can solve that problem.

[Behrang Saeedzadeh]

Michael,

Thanks for the reply. But my point is that the architect of the given scenario has not explained why he thinks his solution provides %99.99 up time. And even though that he has provided hot standby machines for the DB and the App Server clusters, he has not provided a hot standby for the load balancer. And as such it can not be advertised as a system that provides %99.99 up time.

[Michael Ernest]

Behrang Saeedzadeh wrote:2- Up time
Also there's no reason why the solution can handle %95 of transactions in less than 5 seconds and the rest in 20 seconds or less while this is a requirement.

Any ideas and suggestions regarding these issues? Can our solutions really be this vague?

I misread the posts when I answered re: 99.5% availability, but the logic still applies. Once you dig a bit deeper into the details that this requirement implies, chances are you'll see not why the requirement is justifiable, but what kind of solution is necessary to meet it.

As another example, if you are told that 95% of your transactions must complete in 5 seconds or less, you're being handed a fairly broad hint, which is to ask yourself: what programming task can you reasonably accomplish, 95% of the time, in less than 5 seconds. One way to break this down is to consider the costs of running your program, in particular I/O. If you have to stay under 5 seconds virtually all of the time, what kinds of deployment models are ruled out?

[Michael Ernest]

Behrang Saeedzadeh wrote:
Thanks for the reply. But my point is that the architect of the given scenario has not explained why he thinks his solution provides %99.99 up time. And even though that he has provided hot standby machines for the DB and the App Server clusters, he has not provided a hot standby for the load balancer. And as such it can not be advertised as a system that provides %99.99 up time.

Ok, well, you didn't hear this from me, but: the authors don't really know what they're talking about when it comes to these performance constraints. Or, if they do, they're hiding that fact pretty darn well. From my POV, they are doing what programmers often do when it comes to hardware-oriented NFRs. They using numbers that, by a broad definition, simply rule out certain options. For example, if someone says no txn can take more than 20 seconds, for most people it's just an obfuscated way of saying you can't have a router between the data source and the business logic processor, because a lapse of service at the router could cost you up to 30 seconds.

Real requirements and real architectures are more complex than that, and the solutions are typically both more detailed and come with more assumptions or caveats. But they have to find some way to turn this all into an exercise you can write up in a reasonable amount of space. So, eventually, there's going to be some amount of artifice in the mix. Where the authors seem to draw their own line is by imposing a notion of standard performance values they believe should be a sufficient hint to a proper candidate. And they're not system people, obviously, or they wouldn't be able to keep themselves from getting more detailed on this aspect of their solution.

[Jeanne Boyarsky]

Well said Michael! I think it's also important to note that this isn't a real system. It's a best effort in design type thing.