Book Review

Book review: AspectJ in action – Second edition (Part 1 Understanding AOP and AspectJ)

Adrian Citu

Introduction and … conclusion

Since I’m a fan of AOP and especially of AspectJ, I participated to the MEAP (Manning Early Access Program) of the AspectJ in action – Second edition book. The review that I will done will be of the MEAP edition, so maybe the final version will be slightly different. So, my conclusion about this book is that it is the bible of AspectJ; it gives a very clear introduction to AOP and a tremendous view of the AspectJ functionalities.

Chapter 1:  Discovering AOP

The chapter explain what is AOP and how it can be integrated into the today IT systems. Then the author presents the basic ingredients of an AOP language(join point, pointcut, advice and aspect) and how an AOP language can help to improve the modularity of a complex system.

Chapter 2:  Introducing AspectJ

The chapter is a very gentle introduction to the AspectJ5 framework containing the classic “Hello world” application.For every basic block of an AOP language enumerated in the first chapter, the equivalent AspectJ5 structure is presented using some simple examples. Beside the traditional AspectJ syntax, the new syntax using the annotations is presented (this new language syntax is called @AspectJ) and a paragraph is dedicated to the integration of AspectJ with the Spring framework.

Chapter 3:  Understanding the Join Point Model

This chapter takes us in the heart of the AspectJ framework by presenting the join point model. The joint points are the parts of a Java class (and or) object that can be intercepted by the framework. The joint points exposed by AspectJ are: methods, constructors, field access (read and write access), exception processing, static initialization of classes and objects and AspectJ advices. For every joint point type the author gives very detailed explanations with many examples . For some join point types, a small comparison is made with the Spring AOP framework.

Chapter 4:  Modifying Behavior with Dynamic Crosscutting

The goal of the dynamic crosscutting is to modify the execution behavior of the program. The construct that is offered by AspectJ for dynamic crosscutting is the advice.
This chapter deeply explains the notion of advice. An advice is a structure that contains the code to be executed when a join point is intercepted. The reflection support in AspectJ also is present.The reflection support is represented by a small number of interfaces that provides access to the join point’s static and dynamic information.

Chapter 5:  Modifying Structure with Static Crosscutting

The goal of static crosscutting is to modify the static structure of the Java elements (classes, interfaces). AspectJ offers the following features:

  • Member introduction. Introduction of new fields(final and non-final) and methods to any Java class. There is no need to have the source codes of the modified classes for using member introduction.
  • Type hierarchy modifications. With AspectJ you can modify the inheritance hierarchy of existing classes to declare a superclass and interfaces of an existing class. Of course the AspectJ cannot break the rules of the Java language; cannot declare multiple inheritance or cannot declare a class being the parent of an interface.
  • Compile-time errors and warnings. This is similar to the #error and #warning preprocessor directives from the C/C++ world. A typical use of this feature will be to enforce rules, such as prohibiting calls to certain unsupported methods or issuing a warning about such calls.
  • Softening checked exception. Exception softening allows treating checked exceptions thrown by specified pointcuts as unchecked ones and thus eliminated the need to deal wit it. Well, for me this constructs is a real danger and it should never be used. Even the author, raise a warning about overusing this feature because it can lead to masking off some checked exceptions that should be handle in the normal way.

Chapter 6:  Aspect: Putting it all together

As the name of the chapter it said, all the previous elements (joinpoints and advices) are put together into a same structure that is called “aspect”. The aspects have some similarities with the Java classes:

  • can be abstract
  • have data and members
  • have access specification
  • implement or extend other types
  • be nested inside other types

The main differences with aspects and Java classes:

  • aspects cannot be explicitly created (the AspectJ framework controls the aspect initialization)
  • aspects can inherit only from abstract aspects and not concrete aspects
  • aspects can have access to the private members of the classes (using the access specifier “privileged”)

So, as it was already said, the user cannot directly instantiate the aspects but it can instruct the framework how and when to instantiate the aspects. AspectJ offers 4 kinds of aspect associations:

  • singleton (default). A single instance of an aspect is created for the entire application.
  • per object. A new aspect instance will be created when executing a join point of a matching object for the first time.
  • per control-flow. A new instance will be associated with each control flow associated with a join point
  • per type Similar as the per object association with the difference that the aspect will be associated to the class instead of objects.

The last part of the chapter explains the aspects precedence or how to control the order on which advices sharing the same joint point are executed. For aspect precedence, the AspectJ framework introduced the “precedence” keyword.

Example : declare precedence : Aspect1, Aspect2; // Aspect1 have the precedence over the Aspect2

For the case of advices from the same aspect sharing the same joint point, the lexical order is applied (the advice declared first have the precedence over the second one, etc…).

Chapter 7:  Diving into the @AspectJ Syntax

The AspectJ 5 (the last version of AspectJ) introduced support for the Java5 language features. The introductions of annotations in Java5 permitted to the AspectJ team to offer an alternative syntax to the “classical” AspectJ syntax. The newly syntax called @AspectJ offer a choice to compiling source code with a plain Java compiler because all the crosscutting information is kept in annotations on Java elements:

  • aspects are normal Java classes annotated with @Aspect annotation.
  • advices are Java methods annotated with the following annotations @Around, @After, @AfterReturning, @AfterThrowing, @Before.
  • pointcuts are Java methods annotated with the @Pointcut annotation
  • modifications of type hierarchy is done by annotating Java fields with @DeclareParents annotation.
  • error and warning declarations are done annotating Java fields with @DeclareError and @DeclareWarning annotations.

Unfortunately, not all the AspectJ feature are available using the @AspectJ syntax:

  • the member introduction; a workaround for this limitation is to use modification of type hierarchy by declaring as parent an interface using the @DeclareParents annotation with the attribute “defaultImpl” containing a class that implements the interface.
  • softening exceptions.
  • privileged aspects.

Chapter 8:  AspectJ Weaving Models

The AspectJ framework offers two types of weaving:

  • build-time weaving; the classes and aspects are weaved during the build process using the ajc compiler. The ajc compiler can take as input source files, class files and jar files each of which may contains classes and aspects.
  • load-time weaving (LTW);the aspects are weave into the classes as the classes are loaded by the classloader. The LTW uses another Java5 feature which is Java Virtual Machine Tool Interface (JVMTI). JVMTI allows a JVMTI agent to imtercept the loading of a class. The load-time weaver is a JVMTI agent that use this functionality to weave the classes as the VM loads them. If the @AspectJ syntax is used then the LTW must be used. The load-time weaver needs some additional information to decide which aspects to weave; this information should be in a XML format into the file META-INF/aop.xml (alternatives to aop.xml are also META-INF/aop-ajc.xml or org/aspectj/aop.xml file).

Basically, the aop.xml file should contains the list of aspects to weave, the list of aspects to exclude from weaving, the list of the packages of the classes to be modified by the aspects and the list of packages of classes that should not be weaved.

Chapter 9:  Integration with Spring

This chapter presents more than the integration of AspectJ into Spring framework; the chapter presents the Spring AOP framework.

Prior to Spring 2.0 version the only Spring AOP offered “schema-style” AOP support that consists into writing crosscutting information in the XML form (for more details about “schema style” aop support please see this: http://static.springframework.org/spring/docs/1.2.x/reference/aop.html). The “schema style” support is suitable for projects that use version of Spring prior to Spring 2.0 or your project don’t use Java5.
Since Spring 2.0, the Spinng AOP is capable to understand the @AspectJ syntax.
The Spring AOP is a proxy-based framework, Spring creates proxy classes for each bean that matches the criterias specified in pointcuts. The proxy classes will intercept the calls to the original object. Under the hood, Spring uses dynamic proxies mechanism for intercepting calls to a method of an interface or it uses the CGLIB-proxies if the method to intercept is not part of an interface.

Some drawbacks of the Spring AOP linked to the proxy-based nature:

  • method execution-only join points;the proxies can intercept only methods.
  • cannot intercept/advise final methods; since Java prevents overriding final methods, the dynamically created proxies cannot advise final methods.
  • bean-only crosscutting; the  proxy creation requires that Spring bean factory create the objects that needs to be advised, so Spring AOP works only on Spring beans.

Due to the proxy-based mechanism it is not possible to use the full AspectJ power; the following pointcuts are not available: call(),
initialization(), preinitialization(), staticinitialization(), get(), set(), handler(), adviceexecution(), withincode(), cflow(), cflowbelow(),
if(), @this(), @withincode().

On the other side, Spring AOP (since version 2.5)introduce a new pointcut for selecting Spring beans. The pointcut is bean(<name-pattern>) and the name-pattern follows the AspectJ matching rules for a name pattern with ‘*’ being the only allowed wildcard.

Book review: Foundations of Security (Part 2 Secure Programming Techniques)

Adrian Citu

Chapter 5: Worms and other malware

This chapter present some “famous” worms that had major impact on the security industry.  Every worm presented in the chapter had used one of the security holes that will be presented in the following chapters: Morris worm (buffer overflow of the finger daemon server), the Code Red worm ( buffer overflow of the II Server), the Nimda Worm (buffer overflow of the II Server and infection using the web browser), the Blaster worm (buffer overflow of the DCOM), the SQL Slammer (buffer overflow of the SQL Server).  The authors also presents definitions of another types of malware like rootkits, botnets, spywares, keyloggers, adware, trojan horses, clickbots.

Chapter 6: Buffer Overflows

This chapter threats the buffer overflow vulnerabilities; a very small example (written en C) is presented and explained then the possible solutions to this problem are enumerated and explained :

The end of the chapter presents another types of memory corruption vulnerabilities:

Chapter 7: (Web)Client-State Manipulation

The goal of this chapter is to present how a malicious user can pass to a web server modified requests. The example used as example is a pizza ordering web site which accepts GET requests containing sensitive information as the price of pizzas or the number of bought pizzas.  The attack scenario consists in modifying the values of the parameters sent to the server (ex: by 10000 pizzas at the price of 0 $).  The possible solutions to this kind of attack would be :

  • sensitive information stays on the server. Don’t send sensitive information to the client, send only an id (session id) identifying the client sensitive informations. Another technique is to send to the client a signature of the session in order to prevent the tampering of the session if by a (malicious) client.
  • do not use HTTP GET but use HTTP POST. The HTTP POST use can be combined with the use of cookies and or use of JavaScript.

The main idea of this chapter is  web application should never trust the clients and should always validate the clients input.

Chapter 8: SQL Injection

Using the same example as in the previous chapter (the pizza ordering web site) the authors explains the anatomy of a SQL injections attack and then they propose various solutions to this kind of attacks. The proposed solutions are:

Chapter 9: Password Security

This chapter goal is to present some of the techniques used by a password management system in order to reduce the impact of an attack. The authors will prove some of these techniques by implementing a mini-password manager that can be plugged-in into the toy web server (presented in Chapter2 :Secure Systems Design) for authenticate the users . The mini-password manager implementation starts by a straw man proposal, the users and passwords are stored into a property file. The following state is to replace the passwords by hashed versions. In order to mitigate the dictionary attacks a “salt” is added at every password. At the end of the chapter, the authors briefly presents additional security techniques :

  • password filtering (if a user choose a password that is in the dictionary or identified as easy to guess then must require to the user to choose another one).
  • limited logging attempts (the user have a limited number of login attempts before the account is locked or disabled)
  • aging passwords (the users are forced to change the passwords after a certain time)
  • one time passwords

Chapter 10: Cross-domain Security in Web Applications

This chapter starts by explaining some concepts linked to the web application security; same policy origin, Http Request Authentication, lifetime of the cached cookies and the the HTTP Authentication credentials. Then, some attack patterns are presented in detail:

The last part of the chapter presents the solutions for preventing each of the attack patterns.

The proposed solutions for the XSRF are:

  • inspecting the Http referrer headers (not a complete solution since the Http headers can be modified on the fly )
  • validation of the Http user forms via a user-provided secret (every Html form contains an additional field representing the user password; not very user friendly)
  • validation of the Http forms using an Action Token (in order to distinguish “genuine” instances of forms from ones that were forged by a third party, a token is included as a hidden field in the form. The main difficulty is to find a generation schema in order to be impossible for a third party site to generate valid tokens)

Solutions for preventing the XSSI are:

  • use an Acton Token (s in the case of XSRF)
  • restrictions to form submission only using Http POST

Solutions for preventing XSS are :

  • HTML escaping (any string that is possibly derived from untrusted data and is inserted into an HTML document must be HTML-escaped).
  • HTML tag attributes (form fields attributes, URL attributes, JavaScript-valued attributes) must be quoted.
  • use of HTTP-only cookies (cookies that will no be exposed to client-side scripting)
  • bind Session cookies to IP address

Chapter 11: Exercises to part 2

As for the first part, this chapter contains questions and exercises in order to “walking the walk not just talking the talk”.

Book review: Foundations of Security (Part 1 Security Design Principles)

Adrian Citu

Lately, I was interested on “security applications” (view Security certifications for programmers) so I will do the review of the Foundations of Security: What Every Programmer Needs to Know.

Chapter 1:  Security goals

The first chapter make a brief description of the security domains. For the author the IT security can be split on the following domains:

  • Physical security (mechanisms that limit the physical access to the IT material: locked doors, card readers, biometric lockers, etc… )
  • Technological security
    • Application security (the domain that this book covers)
    • OS security
    • Network security
  • Policies and Procedures (each employee may need to be educated to never give out her password, the systems are so that the system administrators have the ability to reset passwords)

The chapter also introduce and explains the seven key concepts in the security field :

  1. Authentication (is the act of verifying someone identity)
  2. Authorization (is the act of checking whether a user has permission to conduct some action)
  3. Confidentiality (is the act of keeping the content of a transient communication or data accessible only to authorized entities)
  4. Message/Data integrity
  5. Accountability (the goal of the accountability is to ensure that you are able to determine who is the attacker in the case that something goes wrong)
  6. Availability (an available system is one that can respond to it’s users in a reasonable timeframe)
  7. Non-repudiation (is the act of ensuring the undeniability of a transaction by any of the parties involved)

Chapter 2: Secure Systems Design

The chapter contains some general advices in order to design secure systems. The fist advice is that it must understand the threats that can impact your project/organization. The author enumerate some of the possible security threads that can occur if the security is not part of the product design: web site defacement, computer infiltration (using buffer overflow, command injection, etc), phishing, pharming (dns cache poisoning), click fraud, denial-of-service.
In order to present various security design problems, the authors presents the code of a simple web server (you can find teh code here); the web server  is written in Java language and a complete code walk through is made in the chapter.

I must admit that was very hard to extract the essence (the main ideas ) of this chapter, for me the style is very unclear and I simply think that a part of this chapter would had a better place into the next chapter (Secure Design Principles).

Chapter 3: Secure Design Principles

In this chapter the authors enumerate and explain various principles in order to create a secure system. The following principles are explained:

  • the principle of least privilege (a computer or a user should have the minimum amount of privileges for accomplish a task)
  • defense in depth (the defense of a system must reside on multiple security layers not a single layer)
  • diversity in defense (use multiple heterogeneous systems that do the same thing, ex: use different operating systems in you infrastructure)
  • secure the weakest link (the system is only strong as the weakest link)
  • fail-safe stance or failing securely (design a system in such way that even if one or more components fail, the system can still ensure some level of security).  In order to explain this principle, the authors will use the web server from the previous chapter.
  • secure by default (when designing a system, by default should be optimized for security wherever possible)
  • simplicity (keep the software as simple as possible to preserve the software security)
  • usability (in order to be usable, a software product should let the users to accomplish the tasks that the software is mean in most securely way). It is true that the usability and the security are sometimes 2 antagonist properties.

Chapter 4: Exercises for Part 1

The chapter contains some exercises linked to the previous chapters. Some of the exercises are just questions about things explained in the previous chapters, others are programming exercises (mount an attack to the web server or implement a  basic HTTP authentication).

Book review:RESTful Web Services (chapters 1-5)

Adrian Citu2 Comments

While I reading a book, I like to make a summary of every chapter, it force me to find and highlight the main ideas.  This post is about RESTful Web Services book.

Chapter 1: The Programmable Web and Its Inhabitants

This chapter is a global introduction to web services. The author introduce 3 types of web services architectures using the following criteria:

  • how the web service clients send to the server the action that should be done. This kind of information is called “method information”
  • how the web service clients send to the server on which data the server must work to compute an answer.This kind of information is called “scoping information”.

Using these two criteria, the web services can be of three types:

  • Remote Procedure Call (RPC) web services. In this case the “method information” and the “scoping information” are stored into a SOAP envelope and the HTTP envelope is used only to transport the SOAP request/response.
  • Resource Oriented (RESTful) web services. In this case the “method information” goes into the HTTP method. If the client wants to retrieve some information the GET HTTP method is used, the DELETE HTTP method is used if it wants to delete some infornation, etc.. The “scoping information” goes into the URI path.
  • Hybrid web services. Some parts of hybrid web services are RESTful (in most cases, the parts that implies the retrieving of the information from the server) and some other parts are RPC style.

Chapter 2: Writing Web Service Clients

The goal of this chapter is to write web service clients in different programming languages against the del.icio.us web service.
So, any basic web service client must follow the next steps for fulfill his mission:

  • create the HTTP request containing the request for the server.
  • parse the response of the server.

For every step of the work flow, the author presents code samples for the following languages (Ruby, Python, Java, PHP, C# and JavaScript).

For the first step of the work flow (the creation of the HTTP request) a detailed explanation of external libraries that are used by the web service client is made. For the Ruby language, the rest-open-uri is used; for the Python the httplib2 (http://bitworkin.org/projects/httplib2/) is used; for the Java the Jakarta HttpLib (http://jakarta.apache.org/commons/httpclient/) is used; for C# the standard System.Web.HTTPWebRequest is used; for PHP the libcurl is used.

For the parsing part (the second step of the work flow) the different kinds of parsers are explained: DOM parsers, SAX parsers and “pull” parsers.

Chapter 3: What Makes RESTful Services Different?

In this chapter the author creates a client for a real REST web service. The REST service used is the S3 Amazon web service. S3 is based on two concepts: S3 “buckets” and S3 “objects”.An object is a named piece of data with some accompanying metadata. A bucket is a named container for objects.
To prove that S3 is a RESTful web service here are the resources and their method:

  • the bucket list(/); use GET
  • a bucket(/{bucket}); – use GET to list he bucket objects
  • use POST to create the bucket
  • use DELETE to delete the bucket
  • an object(/{bucket}/{object}); – use GET to list the object metadata and value
  • use HEAD to get the object’s metadata
  • use PUT to set the object’s values and   metadata
  • use DELETE to remove the object from the bucket

Chapter 4: The Resource-Oriented Architecture

For the author the ROA (Ressource Oriented Architecture) is an architecture that follow the RESTful criterias applied the world wide web. So, ROA is REST for WWW.
The ROA contains four concepts:

  • resources
  • resources names (URIs)
  • resource representations
  • the links between resources

and four properties:

  • addressability
  • statelessness
  • connectedness
  • a uniform interface

The heart of ROA are the resources, a client will create, read, update and delete resources.A resource can be anything, with the condition to be addressable by Web, so any ROA resource must have at least one URI. The relation between resources and URIs is one to many, a resource can be addressable by many URIs but a URI addresses only one resource. The statelessness is quite easy to assure because the HTTP protocol is stateless by default and every state needed should be handled by the application not by the REST service.
The resources can be presented in multiple forms, “simple” information (i asked a photo from a service or a text file) or “complex” information that can contains HTTP forms and, or HTTP links.

As in the case of a programming API, the way of working with the resources should be universally accepted. On a resource it is possible to execute 4 actions, CRUD (Create Read Update Delete). ROA uses the HTTP basic methods as an interface for the actions to execute on the resources:

  • HTTP GET is used to retrieve a representation of a resource
  • Create a new resource: HTTP PUT to a new URI and HTTP POST to an existing URI
  • Modify an existing resource: HTTP PUT to a existing URI
  • Delete an existing resource: HTTP DELETE

Chapter 5: Designing Read-Only Resource-Oriented Services

The procedure of creating a read-only resource-oriented service contains the following steps:

  • Analyze the data set to be exposed s read-only resource
  • Split the data set into resources

For each resource:

  • Name the resources with URIs
  • Design the representation served to the client
  • Link the resource with other resources using hyper links and forms
  • Consider the typical course of events
  • Consider the error conditions: what to send to the client when the things goes wrong.

To show how all this criterias can be applied the author takes as example a service that serves informations about maps. The main difference between this service and the real world web application is that this service main clients will be other web services not only a human user.

The data set of the service will be maps, points of the maps, points having specific properties (name, description, place type).Basically the service will expose 2 kinds of resources: predefined data set (the USA country, the Paris city, any point an a map by the coordinates) and algorithmically-generated resources(towns in France with population less than 10 000, pizza restaurants near Mount Rushmore).
Now that we have the resources that we want to expose,it must find a way of naming the resources in order to be accessible by the clients. As we already said, the ROA use the WWW to make available the resources (see the review of the previous chapter) so the names will be based on URIs.
The organize the resource as URIs the following rules are used:

  1. To encode an hierarchy the path variables will be used. ex: /parent/child
  2. To encode resource that are not hierarchical the punctuation characters are used. ex: /parent/child1;child2
  3. For the algorithmically-generated resources the query variable are used. ex: /search?query=country=france&population=1000

The sources are represented as XHTML documents that can be very easy interpreted by a browser in order to be used by a human and also by another web service. When a client is asking for a resource, the service sends an XHTML document containing more than the URI of the resource; the response can contains another URIs (places that are around the resource) or another type of informations like the description of the resource. In the case of algorithmically-generated resources, a HTML form is used to send to the service the parameters needed to compute the resource.

To inform the client about the state of the resource that he asked the standard HTTP headers are used. A 200 (“OK”) code response code means the resource was found, codes like 500 (“Internal Server Error”) will inform the client that the server have a problem, 404 (“Not Found”) code will inform the client that a place does not exist and a 400 code. The main idea is that it is possible to ‘play’ with the variety of HTTP response codes to send to a client a “business tailored” responses.

Book Review: My Job Went to India (52 Ways to Save Your Job)

Adrian Citu

As it is said in the description of the book, this book is not about India, it’s about you.The main idea of this book is that you should see your carrier as a product. So, as with any product your carrier should have a life cycle:

  • choose your market
  • invest into your product (career)
  • execute
  • market your product

Well, I limit my review only to the advices that i find very useful.

  • Go to the niche technologies where the offshore companies don’t go.
  • Learn about the business domain of your company.
  • Invest into a “dying” technology because this technology will be replaced with a new one and it will need some peoples for the replacement.
  • Learn a new programming language totally different from the one you already know or practice. For example if you know Java, try to learn Lisp.
  • Don’t close yourself into a technology, operating system or position, try to be a generalist. If you are a manager try to program a little bit, if you are a Windows developer try the Linux tools, if you are a Java guy just try some .Net
  • Be a specialist, know the technology on which you are working inside out.
  • Don’t focus your career on a vendor specific product (don’t put your eggs in someone else’s basket)
  • Be the worst guy from the team 🙂 because you will have plenty of things to learn.
  • A good professional is passionate about his job. If you are not passionate it will be visible on the results f your work.
  • Be curious about your work environment. Try to learn new things about your IDE or your company business domain.
  • Understand the basics of the business.
  • The best way of learning something is by teaching to someone else (be a mentor).
  • Learn from the work of other developers, take a look to the sources of the open source projects (imitate, assimilate, innovate).
  • Automate your repetitively tasks.
  • Be proactive and try to “read the mind” of customers, managers. Get ideas from this persons to imprve your project.
  • Do the boring tasks perfectly. In this way the boring tasks will became less boring or even fun.
  • Learn to love maintenance work. You can transform this boring stuff into a fun task by doing it perfectly and by adding small enhancements.
  • There is no way to objectively measure the quality of a knowledge worker and there is no way to measure the quality of that work so, it is important what peoples think about you. Perception is the reality.
  • Communication, especially thought writing is the bottleneck thought all the ideas must pass. You are what you can explain.
  • Try to find the next bleeding edge technology. Even it’s a gambling game to find this technology, if you don’t play you will definettly loose.