"Complete description" of the Book

[Hemant Agarwal]

Hi,
I want to know the complete description of your book. What it is all about?
What design pattern it describes? What design it is talking about?
Any other things?
What is the benifit of reading it?
Why one should purchase it?

Thanks


[ January 17, 2006: Message edited by: Ilja Preuss ]
[ January 18, 2006: Message edited by: Hemant Agarwal ]

[Cliff Berg]

Hi Hemant,

The book tries to bridge the gulf between the application developer community, and the securiy and software assurance communities. These latter two communities have provided concepts and frameworks for how to build reliable and secure systems, but this information has not been written in a way that can easily be incorporated by the mainstream software developer community. My book tries to remedy that. The book is not a coding book: it is a book about design, so if you are not inclined toward design then it is not for you. If you are inclined toward design, you will probably like it. It is filled with design concepts: principles, patterns, and discussion of key concepts in security and software reliability, and how they relate to business applications in a practical way. The book also examines the impact on current development methodologies, such as extreme programming, and how assurance concepts can be factored into the development methodology. Those who should read the book include those who are interested to know, for example, what kinds of error handling they should design into their application, what kinds of manageability feaures, what kinds of security risks they should think about, and so on. I hope that this answers your question. - Cliff

[Mike Farnham]

So the point of the book is to not only for design to solve the problem, but to solve the problem in a secure, quality manner.

I know in our development group we have had a few quality control problems that were exacerbated by either exceptions not being reported or masking other exceptions.

We are striving to reduce these type of problems. We have made a recent concerted effort on idenitifying what exceptions are serious errors versus those that are not. An example would be, in one case the application must report an error, in the less serious case the application can continue to deliver information to the end-user despite some missing pieces.

Look forward to learning more about the book.

Cheers,
Mike

[Cliff Berg]

Mike, that is an astute description of the problem. Exception handling is critical for an application that must stay up all the time. The difficulty with today's applications compared to "yesterday's" is that today's applications rely on many distinct parts to function: an app server, a DNS server, a SAN, databases, an Internet gateway, complex routers, HTTP servers, LDAP servers, security policy servers - all separate components that are on different maintenance schedules and all with configurations that must be maintained. Even if each piece is highly reliable, the chance that something will go wrong on a given day is quite high. Therefore, applications need to be resilient to failure, and treat failure as a normal event - not an exceptional event. That means that failures related to coniguration, lost connections, failure to get a connection, missing files, database connection failures, all must be treated as normal things that happen from time to time, even if they are detectable only by a RuntimeException. That means that applications must perform intelligent logging - not just dump everything in a haphazard manner, and must carefully consider everything that might go wrong - not just give up or write to the log if a RuntimeException occurs. It means that applications must think about recovery, and how they can keep going when an aspect of their processing fails, or perhaps when to try again for that aspect that has failed. The effort to do this is not small, but it is necessary for a high-assurance system.

- Cliff

[Mohamed Farouk]

Hello Cliff
Thanks for your replies,
Just when we are forgetting to think about plumbing and infrastructure, security code and handling there exceptions the things your talking about security reliablity to be built inside application is quite conflicting.

I work on J2EE and the logic was to build applications only based on logic and leave everything else to the vendors who build servers to guareentee
scalability, security , reliability and availability.

Now are you saying we should start to think of these as a part of application design and logic as well. Is it not something which will lead us to go to the past of handling everything including runtime exceptions as we used to do in mainframe world?

Regards
Farouk

[Pradeep bhatt]

Cliff,

I havent understood what "Software assurance community" is.

[paul wheaton]

"The fastest, most reliable component of any system is that which isn't there."

[Cliff Berg]

Mohamed, your point is well taken. Programmers should not have to think about infrastructure, reliability, or security.

Unfortunately, they do have to, given the state of today's technology.

For a small departmental application, the consequence is minimal. For an application on which a large business depends, that is accessible to the Internet, the risk is high, and assurance matters. Much more effort is required to reach that assurance.

It is also the case that even if one has the most secure infrastructure, any application module can subvert that infrastructure. That is why programmers must think about security. There have been some very widely publicized security failures recently in which a small change made by a single application developer compromised the security of the entire application. The same is true with regard to reliability. That is why one must build applications in such a way that logic errors cannot do alot of damage. These are architectural considerations that are precisely what my book covers.

- Cliff

[Mike Farnham]

Hi Cliff,
Thanks for your observations. I noticed you mentioned logging.

We just had a long discussion about logging particulary in terms of multiple webapps accessing a common service. For our applications, we have a function that returns the CurrentTerm (term meaning semester we are an educational organization). We decided to have a "Term Service" that will return a Term. This service can be used by multiple appliations. However, we have discovered that portlets/servlets, when using log4j for logging each require their own log4j.properties file. Since our design was to have the Term Service log all of its own exceptions, we have it instantiate the logger within itself.

When the web applications access the Term Service, the first one in wins, meaning, whichever web applications is the current context, that is where the Term Service will log its messages. After some discussion, we figured we could have each log4j.properties file point to a common TermServices.log file. This would centralize all of the messages from the TermService into a single log file. However, we now have messages in a file with no context.

Using log4j within the WebApp definition there doesn't seem to be a way to have messages logged from the TermService in each log for each web application. We wanted the TermService to handle and log all exceptions and return 'null' when it failed. So, the application could log the fact it didn't get a Term, but it is to be ignorant of why it couldn't get a Term.

We like to use the Order a Pizza analogy. If you order a pizza, and it isn't delivered, you really don't care if the driver was in an accident, or the delivery vehicle had a flat tire. You either get a pizza or you don't.

Anyhow, sorry to delve into "code".

I guess the question would be "How does your book address application level logging?"

Thanks for listening,
Mike

[Evguenia Krylova]

Hello Cliff,
My team is setting up a new server and starting a new project. We'd like to put in place comprehensive testing. I see that you address the security risks developers should consider. Do you address the role of testing strategies for security issues in your book?
Thank you,
Ev