Different Forms of Software Reuse

Software reuse has always been one of the goals of software development since the beginning. If there is something already there and working perfectly fine, why do we want to reinvent the wheel? People tried many different techniques in the past. Here are what I think the different forms of software reuse.

Let's first visit reuse within a single application or project.

Copy and Paste. This is the most primitive form of reuse. Some may not agree that it is a form a reuse. Some even think it is anti-reuse. You see a code snippet that is exactly what your are looking for. Why do I have to reinvent the wheel again? You copy the code and paste it to the new place. Everybody knows that it is bad, but some do that still. The main problem is the maintenance. If we want to change the code snippet, we have to change it in many places. Once a code snippet is copied, the original and copied version evolve independently.

Refactoring. You massage the code using various techniques such as Object-Oriented design (OOD), Aspect Oriented Programming (AOP), or just simply create utility packages. The result is that the code and logic stays in one place. Application becomes easier to understand and maintain. This is great. However some code and logic can be shared among projects.

Now that's look at reuse across applications.

Source-code Reuse. You obtain the source code from other project or some common code repository, and incorporate it into your own project. It may sound ok at first, but it is the equivalent of "Copy and Paste", only it happens at a different level. You may even modify the code to meet your own need. Such modification is hard to track and maintain.

Binary-code Reuse. You obtain and use the reusable asset in the form of binary library. It is better than Souce-code Reuse. At least you know there is no modification to the asset. In many cases, this form of reuse is the best option we have. However it still have the maintenance issue. For example, a new release of an asset fixes some defects. In order to get the fixes, each individual project must download the new release and incorporate it into the project.

Runtime Reuse. What if we package the reusable logic and stand it up as a service? So instead of embedding reusable code into each individual applications, let applications "use" the shared service at runtime. Yes, we are talking about Service-Oriented Architecture here. Of cause, we can't turn everything into services. SOA has it own issues such as service versioning and governance to worry about.

Spring Web Flow 10000 ft Overview

Spring Web Flow (SWF) is a workflow engine designed specifically for Web page navigation. SWF flow definition language is a Domain-Specific Language (DSL) written in XML. Developers use this language to define State Machines.

Here is a visualized main flow from the swf-booking-faces sample project:

There are quite a few benefits of using workflow-based UI process frameworks such as Spring Web Flow. Among them are:

1. UI flow are visible and easier to understand
2. Complex UI interaction is abstracted and modularized into flows and can be reused

Other comparable technologies is Seam + jBMP.

When using Spring Web Flow, you basically replace "controllers" in MVC with flows, because flows capture controlling logic. Creating and setting models has become the responsibility of the flows.

The most commonly used state is ViewState. ViewState displays a view to user. User's action on that view, such as clicking a button, generates an event that is handled by the view state. Typically event handling results in transition to other state. Each view state has a corresponding view template. By default, view template is located at the same folder where the flow is located. For example: enterSearchCriteria view state has a view template enterSearchCriteria .xhtml.

<view-state id="enterSearchCriteria">
        <on-render>
            <evaluate expression="bookingService.findBookings(currentUser.name)" result="viewScope.bookings" result-type="dataModel" />
        </on-render>
        <transition on="search" to="reviewHotels">
            <evaluate expression="searchCriteria.resetPage()" />
        </transition>
        <transition on="cancelBooking">
            <evaluate expression="bookingService.cancelBooking(bookings.selectedRow)" />
            <render fragments="bookingsFragment" />
        </transition>
    </view-state>

In this case, transition happens when user perform "search" action, which is defined in view template file as:

<sf:commandButton id="findHotels" value="Find Hotels" processIds="*" action="search" />

<on-render>is used to prepare the a ViewState for rendering. You can define actions in EL within a State to perform additional tasks such as invoking business service. Actions can be inserted into different places within a State: on state entry, on state exit, on view render, on transition etc.

Flow can have inputs (using <input>) and outputs (<output> elements in EndState).

Flow can also declare flow instance variables by using <var>.

Other type of states include:

• ActionState: used to perform an action and transition to another state based on the outcome.
• DecisionState: is similar to ActionState, with a different if-else syntax.
• SubflowState: SubflowState invokes a subflow. Caller flow can pass in input parameters to subflow and check the output of the subflow to determine the transition.
• EndState: flow is terminated when it enters in an EndState.
  
  

Claim-based Identity in SharePoint 2010

SharePoint 2010 includes Claim-based Identity framework as its new identity management feature. It involves a trusted identity authority issuing tokens that are consumed by SharePoint 2010. It does not replace the classic Windows Integrated or Form Based Authentication (FBA) in SharePoint 2007. It is actually a new framework under which Windows Integrated or FBA can be used along with other authentication methods.

First, here are some key concepts in Claim-based Identity:

• Identity: a set of information about an entity, such as a user
• Claim: a piece of information about the identity, such as user's name
• Security Token: it contains a set of claims and digitally signed by an identity authority
• STS: Security Token Service. It is a trusted identity authority that validates claims about identities and issues security tokens. The protocol used for issuing security tokens is based on WS-Trust. Trust relationship can be establised between STSs
• Identity Provider STS (IP-STS): An IP-STS authenticates a client and creates a SAML token based on the claims.
• Relying Party STS (RP-STS): RP-STS does not authenticate the client, but relies on a SAML token provided by an IP-STS that it trusts. It transforms the claims and issues new tokens based on the rules and policies.
• SMAL: a standard security token format

Be aware that Claim-based Identity is not a Microsoft's proprietary technology, but based on standards such as SMAL, WS-Trust and WS-Federation. For example you can use Novell Access Manager as a STS on a non-Windows platform.

Here are some benefits of using Claim-based Identity:

• It allows Federated Identity architecture which is easier to administrate, and potentially more secure.
• Unified authentication approach makes developer's life easier
• Application offloads complex authentication and identity management to a third party Identity Authority (STS)
• Application can get more identity information (claims) about the entity than simply user id
• Application can request the exact claims it needs by setting up policy.

Claim-based Identity in SharePoint 2010

SharePoint 2010 has a build-in STS (that is called it SP-STS). When Claim-based Identity mode is turned on, SharePoint 2010 is configured to only accept the security tokens issued by SP-STS. SP-STS can be used as either IP-STS, or RP-STS.

When SP-STS is used as IP-STS, browser or client is authenticated with SP-STS either using Windows authentication or Form-based authentication (aka ASP.NET authentication). Then security token is passed to SP 2010 to login. See the diagram below.

When SP-STS is used as RP-STS, browser or client is authenticated with a different IP-STS which may not be a Windows identity provider. This IP-STS is trusted by SP-STS. Client passes security token issued by the IP-STS to SP-STS. SP-STS then issues a new token which is acceptable by SharePoint 2010.

Spring @MVC Explained

SpringTravel project is used here as an example to illustrate how Spring MVC works.

The following diagram depicts the processing flow of Spring MVC.




Spring provides a Dispatcher Servlet called DispatcherServlet, which maps to an URI path pattern, in this case it is /app/*. You configure the servlet in web.xml.

    <servlet>















        <servlet-name>















            Spring MVC Dispatcher Servlet















        </servlet-name>















        <servlet-class>















            org.springframework.web.servlet.DispatcherServlet















        </servlet-class>















        <init-param>















            <param-name>contextConfigLocation</param-name>















            <param-value>/WEB-INF/web-application-config.xml</param-value>















        </init-param>















        <load-on-startup>1</load-on-startup>















    </servlet>































    <servlet-mapping>















        <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>















        <url-pattern>/app/*</url-pattern>















    </servlet-mapping>

Controller

Controllers are annotated with @Controller. The Spring MVC Dispatcher Servlet scans for all the conroller classes. There is no need to define the controllers as beans in the conext xml file, Spring automatically does that for us. All we have to do is adding one line in the context file
web-application-config.xml, which is passed in as an initialization paramter to the Spring MVC Dispatcher Servlet.

    <context:component-scan base-package="com.springsource.springtravel.hotels" />

Here is an example of a controller. URI path /app/hotels/* is mapped to this controller. Each handler method further narrows it down by additional URI path pattern and http method. For example search() method maps to /app/hotels/search and GET method. Handler methods have flexible signature and return type. In this example, they return three types:

• void: view is implied by RequestToViewNameTranslator


• string: view name


• Model object: view is implied by RequestToViewNameTranslator
  

@Controller















@RequestMapping("/hotels/*")















public class HotelsController {































    ...































    @RequestMapping(value = "index", method = RequestMethod.GET)















    public void index(HotelSearchCriteria searchCriteria) {















    }















































    @RequestMapping(value = "search", method = RequestMethod.GET)















    public String search(HotelSearchCriteria searchCriteria,















            BindingResult bindResult, Model model) {















        ...















        if (bindResult.hasErrors()) {















            return "hotels/index";















        } else {















            model.addAttribute("hotels", searchService.search(searchCriteria));















            return "hotels/search";















        }















    }































    @RequestMapping(value = "details", method = RequestMethod.GET)















    @ModelAttribute("hotel")















    public Hotel details(@RequestParam("id") Long id) {















        return searchService.getHotel(id);















    }































}

Model

Model in Spring MVC is actually a map, which contains beans (map values) and bean names (map keys). Model is completely separated from view and view rendering technology.

A special type of model is Form Model. Form model is specified in the form tag as following:

<form:form modelAttribute="hotelSearchCriteria" action="search" method="get">

In the handler method, form model object can be passed in as method parameter, or returned as return value. By convention-over-configuration, Spring figures out form model object name by its class name. You can always use @ModelAttribute if the names does not match.

Spring MVC vs JSF
Spring MVC is truly a MVC framework. However developers still need to deal with low level HTTP details such as URI path, form parameters to a certain degree. In the sense, Spring MVC lacks UI component model that can be found in JSF.