1.     J2EE Design Patterns

1.1.             Application Controller

Centralize retrieval and invocation of request processing components such as commands and views

Advantages

• Front controller acts as the centralized access point and controller for incoming requests, whereas application controller is a component for identifying and invoking commands / actions and dispatching to views.
• Improves modularity – Action and view management code in its own class
• Better reusability and extensibility

Disadvantages

Example              Struts 1.x RequestProcessor ,  ActionServlet to some extent

1.2.             Application Service

Provides a central location to implement business logic that encapsulates Business Object and services

Advantages

• Centralized reusable business and workflow logic that acts upon multiple Business objects
• Better reusability by encapsulating inter-business object operations
• Avoids duplication of code
• Simplifies façade implmentation

Disadvantages

• Additional layer introduced in the business tier

Example

1.3.             Business Delegate

Encapsulates access to a business service – Acts like client side business abstraction

Advantages

• Reduces coupling, better maintainability as client does not directly depend on business service
• Translates business service exceptions
• Improves availability as it can implement automatic recovery [in case of service failure] without exposing error to client
• Exposes simpler uniform interface to the service
• Can improve performance by caching into for common service requests
• Hides remoteness, lookup etc

Disadvantages

• Introduces another layer

Example

1.4.             Business Object

Separates business data and logic using an object model.  Business objects encapsulate and manage business data, behavior and persistence

Advantages

• Object oriented approach to business model implementation
• Centralized business behavior and state promotes reuse
• Separates persistence logic from business logic

Disadvantages

• Plain old Java object [POJO, i.e. not JPA or EJB] implementation can induce and are susceptible to stale data [when used in distributed multi tier applications]
• Adds extra layer of indirection.  May not be suitable when
  • Business model and business logic are trivial
  • Data model is a sufficient representation of the business model and letting presentation components access data directly using DAO is simpler
• Can result in bloated objects when more and more use-case specific behavior is implemented in BO

Example

1.5.             Composite Entity

Implements persistent Business objects using local Entity Beans and POJOs. Aggregates a set of related BOs into coarse grained Entity Bean implementations

Advantages

• BOs can be implemented as parent objects and dependent objects
• A parent object is reusable, independently deployable and manages its relation to other objects [May contain dependent objects[DOs]]
• A dependent object can be a simple self-contained object or may contain other dependent objects [DOs]
• Increases maintainability as number of fine grained entity beans is reduced
• In EJB 2.x or later, dependent objects can be implemented as local entity beans to take advantage of Container Managed Persistence [CMP] and Container Managed Relationships [CMR]
• Improves network performance by coarse grain entities
  • Improves overall performance in EJB 1.1
  • In EJB 2.x implementing BO As composite entity with local entity beans has the same benefit. 
• Facilitates composite Transfer Object creation

Disadvantages

• Local entity beans could impact performance – POJOs are faster than local entities due to container services

Example

1.6.             Composite View

View is composed of multiple atomic sub-view.  Each sub-view can be included dynamically into the whole and the layout of the page can be managed independent of the contents

Advantages

• Improves modularity and reuse [e.g. header & footer]
• Adds role based or policy based control as composite view and can conditionally include sub-views
• Managing changes to portions of a template is more easy

Disadvantages

• Aggregating atomic sub-view may result in potential display errors which can become a maintainability issue
• Runtime inclusion of sub-views may have minimal performance hit

Example      Tiles

1.7.             Context Object

Encapsulate state in a protocol independent way to be shared throughout the application.

Advantages

• Improves reusability and maintainability [application is not polluted with protocol specific data types]
• Easy testing as context encapsulates protocol information
• Reduces constraints on evolution of interfaces [ one context as parameter instead of numerous objects as parameters]

Disadvantages

• Reduces performance because state is transferred from one object to another

Example      ServletContext used by Servlets.   Protocol specific into is in concrete subclasses like HTTPServletContext

1.8.             Data Access Object

Used to abstract and encapsulate all access to persistence store.  DAO manages connection with datasource to obtain and store data. 

• Stateless
• Does not cache data

Advantages

• Enables transparency for clients [to the location and implementation of persistent storage mechanism]
• Provides Object oriented view and encapsulates database schema
• Easier migration to different databases as only DAO needs to change
• Organizes all data access code into a separate layer

Disadvantages

• Adds extra layer
• Needs class hierarchy design – Prefer factory method strategy over Abstract Factory strategy
• Introduces complexity to enable object oriented design

Example     

1.9.             Dispatcher View

When minimal / limited business processing required, use Dispatcher view with views as the initial access point being a request.  The minimal business processing is managed by view.

• Differs from ‘Service to worked’ – Business processing is done after control is transferred to the view

Advantages

• Leverages frameworks and libraries like JSTL
• Separates processing logic from view [to View Helper]

Disadvantages

• Poor separation of View from Model and Control logic

Example              A direct link to a static HTML page or JSP that displays existing presentation model [data already in session]

1.10.        Domain Store

Used to transparently persist an object model. Unlike CMP or BMP [in EJB 2.0], where persistence code is in object model, Domain store’s persistence mechanism us separate from object model

Advantages

• Separates Bean Management from persistence logic
• Improves testability, Bean management can be tested without actually persisting
• Improves understanding of 3^rd party persistence framework

Disadvantages

• Creating a custom persistence framework is complex
• Creating custom persistence might be an overkill for a small object model
• Multi layer object tree loading and storing requires optimization techniques

Example      EJB3 – EntityManager, Hibernate – SessionManager

1.11.        Front Controller

Centralized access point for presentation tier request handling

Advantages

• Initial point of contact for handling all related requests
• Improves manageability
• Improves reusability [ common code moves to controller]
• Improves role separation

Example      Struts 1.x  ActionServlet

1.12.        Intercepting Filter

Intercept and manipulate a request and a response before and after the request is processed in a centralized way.

Advantages

• Centralized common processing across requests
• Pre and post processing components loosely coupled
• Filter manager combines loosely coupled filters in a chain
• Improves reusability
• Declarative and flexible configuration

Disadvantages

• Sharing into among filters may be costly as they are loosely coupled

Example              Servlet Filters

1.13.        Service Activator

Used to receive asynchronous requests and invoke one or more business services.  It is implemented as a JMS listener

Advantages

• Integrates JMS into enterprise application
• Provides asynchronous processing for any business tier component
• Enables standalone JMS listener [no container support needed]

Disadvantages

• EJB 2.x or later can use MDBs instead

Example     

1.14.        Service Locator

Implements and encapsulates service and component lookup. Hides the details of lookup mechanism and encapsulates related dependencies

Advantages

• Abstracts complexity of lookup from the client
• Uniform service access to clients
• Facilitates adding new components (as client is not aware of EJBHome objects or JMS connection factories, new components can be added without impacting client
• Can improve network performance by aggregating network calls required to lookup and create components
• Can improve performance by caching[e.g. using InitialContext or Factory objects]

Disadvantages

Example     

1.15.        Service to Worker

Centralize control and request handling to retrieve a presentation model before turning control over to the view. The view generates a dynamic response based on presentation model. 

This pattern involves multiple patterns.

• Application Controller – Request Handling
• Front Controller – Centralized control
• View Helper – View creation

Advantages

• Better modularity, reusability, maintainability
• Better role separation

Disadvantages

Example      ActionServlet,    RequestProcessor, and Action

Retrieve / construct ActionForm and process business logic before forwarding to JSP.

1.16.        Session Façade

Encapsulates business tier components by exposing a coarse-grained service to remote clients.

Benefits:

• Manageability
• Centralized logic
• Flexibility

Advantages

• Session Façade implemented as Session Bean interacts with business components such as Business objects and application service
• Reduces coupling between tiers
• Reduces complexity
  • Using application service reduces complexity of Session Façade
  • Using business delegate to access session façades reduces complexity of client
• Improves performance by reducing fine grained remote calls
• Centralizes transaction control with the coarse grained method
• Exposes fewer remote interfaces to client

Disadvantages

Example     

1.17.        Transfer Object

It is used to carry multiple data elements across a tier. Transfer object is pass-by-value between tiers [if they are remote]

Advantages

• Reduces network traffic
• Simplifies remote interface as it can use coarse grained getData() type methods
• Can reduce code duplication by using Entity inheritance TOs
• With JPA entities are POJOs with annotation, once detached from entity manager, they are like TO – However for better control, validation etc, it may still be useful to have TOs separate

Disadvantages

Example      ActionForm

1.18.        Transfer Object Assembler

Used to build an application model as a composite Transfer Object.  It aggregates multiple Transfer Objects from various business components and services and returns it to the client

Advantages

• Reduces coupling between clients and the application model
• Improves network performance by reducing number of remote calls [i.e. helps in getting many Transfer Objects at once]
• Potential to introduce stale data

Disadvantages

Example

1.19.        Value List Handler

Value list handler is used to search, cache [the result]. And allow client to tranverse and select items from the result

Advantages

• Provides search and iteration functionality. Uses DAO to get results for a query from database
• Efficient alternative to EJB finders
• Caches search results
• Better network performance – only a subset of results is sent to the client instead of the entire list
• Allows deferring entity bean transaction

Disadvantages

• Creating a large list of Transfer Objects can be expensive – Mitigate this by creating Transfer object for a limited number of records from the query result

Example     

1.20.        View Helper

Separates view from its processing logic. Use views to encapsulate formatting and helpers to encapsulate view processing logic

• Helpers are adapters between View and Model [ like in the Model-View-Controller]

Advantages

• Better application partitioning, reuse and maintainability
• Eases testing as processing logic is in helper
• Helper usage mirrors scriptlets

Examples    Tag classes [e.g. to handle if-else check]
Action & ActionForm classes in Struts

1.21.        Web Service Broker

Used to expose one or more services using XML and web protocols.  A web service broker is a coarse-grained service exposed as a web service.  It co-ordinates interactions among one or more services, aggregates responses and may demarcate and compensate transactions

Advantages

• Introduces a layer between client and service
• Existing remote session façade need to be refactor-ed to support local access for the broker
• Network performance may be impacted due to web protocols

Disadvantages

Examples

1.     GOF DESIGN PATTERNS

1.1.             Abstract Factory

Provide an interface for creating families of related or dependent objects with out specifying their concrete classes

Advantages

• One level of abstraction higher than factory pattern – It is a factory method that returns one of several factories
• It encapsulates a group of individual factories having a common theme
• Isolates concrete classes
• Makes exchanging product families easy
• Promotes consistency among products

Disadvantages

• Supporting new kind of products is difficult

Example      EJBHome interface that creates new EJBObjects
javax.servlet.jsp.JSPFactory – Abstract class that defines factory methods available to JSP at runtime

1.2.             Adaptor

Convert the interface of a class to another interface that the client expects

Advantages

• Allows two or more incompatible objects to interact
• Reuse of older functionality
• Adapter class ‘adapts’ adaptee to target by committing a concrete adapter class
  • Adapter is a subclass of adaptee
  • Introduces only one object for adaption
  • It will not work when a class and all its subclasses have to be ‘adapted’
• Object adapter has an instance variable of type Adaptee
  • Single adapter works with all of adaptees sub-classes
  • Makes it harder to override adaptee behavior
• Adapter is usually used to avoid changing existing classes [not an up-front design choice when both systems do not exist] Unlike Bridge pattern – both ends of adapter already exist and it glues them together

Example      Vendor specific subclasses of an abstract DAO

1.3.             Bridge

Decouple an abstraction from the implementation so that the two can vary independently

• Abstraction                  =  Entity
• Implementation            =  Behavior
• Similar to Adapter – The Entity adapts the behavior to a different interface [Entity interface]
• Differs from Adapter – It is a design choice [both ends do not exist for Adapter
• Similar to Strategy and State in structure
• Differs from Strategy and State because these two design patterns have a single hierarchy of classes, so the behavior varies but the entity does not.

Advantages

• Two hierarchies of classes that vary independently
• The abstraction [entity] has-a implementation [behavior]
• Used rarely, often combines with AbstractFactory – [creating a family of products – Entity and Behavior]
• Hides implementation details from client
• Allows to assign and change behavior of entities at runtime

Disadvantages

• Behavior interface will be wide if the entities are highly orthogonal [Many varieties of operation]
• Delegation from Entities to Behaviors may degrade performance
• If a new entity is not satisfied with the current behavior interface, then changing interface needs extensive work

Example     DAO Implements Bridge pattern to separate services

1.4.             Builder

Separates the construction of a complex object from its representation so that the same construction process can create different representation

• Special case of strategy applied to create object
• Director has a fixed high-level procedure, but the actual construction process depends on what is being built.  This construction process is encapsulated in a Strategy object called the Builder.  E.g. Builder separates the push scheduler and data formatter for HTTP GET request

Advantages

• Lets you vary a products internal representation
• Isolates code for construction from representation
• Finer control over construction process
  • Director constructs the object step by step
  • Each step is implemented by a concrete builder
  • Once all steps are done Director retrieves the result

Example

1.5.             Chain of Responsibility

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.  Chain the receiving objects and pass the request along the chain until an object handles it

Advantages

• Reduced coupling – Client need not know the receiver of request
• Added flexibility in assigning responsibilities to objects

Disadvantages

• Receipt of request is not guaranteed
• Chain may get lengthy and introduce performance problem

Example      Commonly used for parsers

1.6.             Command

Encapsulate a request as an object to parameterize clients with different requests, queue, or log requests and support undo operations

Advantages

• Easy to add new commands
• Can be assembled into composite commands
• Decouples the invoking object from the object that performs an operation
• Similar to Strategy – execute is the strategy method
• Differs to Strategy –
  • command is a user triggered action
  • Various commands can be unrelated – e.g. Strategy represents a single business rule such as tax calculations.  All Strategies do the same thing in a different way e.g. State Tax calculation verses Federal Tax calculation
  •  

Disadvantages

Example

1.7.             Composite

Compose objects into a tree structure to represent whole-part hierarchies

Advantages

• Lets clients treat individual objects and compositions of objects uniformly
• Defines hierarchies of primitive objects and composite objects
• Makes it easier to ass new kinds of components

Disadvantages

• Leaf has meaningless methods like add()
• Design could be made overly general, making it harder to restrict the components of a composite e.g. Make a composite have only certain components
• Type system will not enforce those contraints

Example      Aggregate Entity Beans,   XML DOM Model,     Swing/AWT containers

1.8.             Decorator

Attach additional responsibilities to an object dynamically

• Proxy is a special case of decorator pattern.  Proxy is used with regard to security and networking and typically a class with a proxy cannot be accessed directly.

Advantages

• Modifies the behavior of individual objects without having to create a derived class and do this at run time
• More flexibility then static inheritance [ ‘has-a’ not ‘is-a’]
• Avoids feature laden classes high up in hierarchy
• Each feature is implemented in separate decorator class

Disadvantages

• A decorator and its component are not identical.  So cannot rely on object identity when using this pattern
• It results in a lot of little objects composing the system

Example    The java.io streams library implementation uses decorators to add responsibility to the stream

1.9.             Façade

Unified interface to a set of interfaces in a system.

Advantages

• Reduces number of objects a client has to deal with
• Promotes weak coupling and less compilation dependencies
• Clients can still use subsystem classes [i.e. they do not have to go to the façade]

Example      Session entity façade pattern in J2EE

1.10.        Factory Method

Defines an interface to create an object but it lets the subclasses decide which class to instantiate

• A public creation method typically of the class that the method belongs to

Advantages

• Gives subclasses a hook for returning subclass

Disadvantages

• Have to subclass creator just to create a particular concrete product

Example      EJBHome interface,   Connection factories for EIS

1.11.        Flyweight

Use sharing to support large number of fine grain objects efficiently

Advantages

• Key concept is distinct between intrinsic and extrinsic state – Intrinsic state is stored in the flyweight, Extrinsic state depends and varies with flyweight’s context and so cannot be shared
  • Client objects are responsible for passing extrinsic state to flyweight
• Minimizes memory occupation by sharing as much data as possible with other similar objects
• Reduction in number of objects to handle

Disadvantages

Example      Pooled EJBs,    Pooled database connections

1.12.        Interpreter

Given a language, defines a representation for its grammar along with an Interpreter that uses the representation to interpret sentences in the language

• Special case of Composite is applied to Parsing

Advantage

• Implementing grammar is easy
• Easy to change and Extend grammar

Disadvantages

• Complex grammars are hard to maintain. At least one class per rule.

Example     

1.13.        Iterator

Provide a way to access elements of aggregate object with out exposing its underlying representation.

Advantages

• Supports traversals of objects in a collection
• Variation in traversal achieved just by changing iterator

Example

1.14.        Mediator

An object that encapsulates how a set of objects interact

Advantages

• Centralized control
• Loose coupling by preventing objects from referring each other

Example

1.15.        Memento

 Without violating encapsulation, capture and externalize an object’s internal state so that it can be restored to this state later

• Related to Command pattern regarding undo pattern

Advantages

• Preserves encapsulation boundaries
• Simplifies the originator [Object does not have to cache its own state as it changes]

Disadvantages

• Expensive if large data resides in Memento’s state
• It may be difficult in some languages to ensure only originator can access memento’s state
• Hidden cost of caring [and deleting] members

Example      dfs

1.16.        Observer

Defines a one-to-many dependency between objects, so that when one object changes state, all the dependents are notified and updated automatically

Advantages

• Abstract coupling between subject and observer
• Support for broadcast communication

Disadvantages

• Unexpected updates – Since observers are unaware of each other’s presence, they can be blind to the cost of changing the subject.  A seemingly innocuous operation on the subject may cause a cascade of updates to observers and their dependent object
• Without additional protocol to help observers discover what changed, they may be forced to work hard to deduce what changed

Example      Swing/AWT Listeners and Observers

1.17.        Prototype

Specify the kind of object to instantiate using a prototypical instantiate using a prototypical instance and create new objects by copying this prototype

Advantages

• Add/remove concrete products just by registering a prototypical instance with a client
• Define new kinds of objects by instantiating existing classes and registering the instances as prototypes of client objects
• The client exhibits different behavior by delegating responsibility to the prototype
• Reduce sub-classing – Factory pattern often produces hierarchy of creator classes that parallels the product class hierarchy The prototype pattern allows cloning a prototype instead of using a factory method to create a new object

Example

1.18.        Proxy

Provide a surrogate or place holder for another object to control access to it.

Advantages

• A remote proxy provides a local representation for an object in different address space
• A virtual proxy creates expensive objects on demand
• A protection proxy controls access to the original object
• A smart reference is a replacement for a bare pointer that performs additional actions when an object is accessed [e.g. counting number of references, loading persistent objects to memory on access, etc ]

Example    EJB’s remote interface is a proxy for a bean

                   Proxy is used in RMI

1.19.        Singleton

Control the number of instances of a class to a constant usually one and provide single global point of access.

Advantages

• Avoid polluting namespace with global variables
• More flexible than class variables or methods

Example      Math class in Java

1.20.        State

State pattern allows an object to alter its behavior when it’s internal state changes.  The object will appear to change its class.

Advantages

• Localizes state specific behavior and partitions behavior for different states
• Makes state transition explicit – All variables of state change together in a single call.
• State objects can be shared like flyweights if states do not have instance variable [Type is a state]
• State objects are often singletons [Gof page 313]
• Similar to Strategy [& Command] – Single class/interface with many subclasses.  The behavior is that of Strategy / Command design pattern
• Differs from Strategy [& Command] – Intend is different.  Behavior is varied by changing state of object and not by performing[or invoking] a single action.
• Similar to Bridge – State is the implementation of behavior for abstract object
• Differs from Bridge – Bridge separates abstraction from implementation and is not based on the state of the object. Bridge pattern can implement any behavior on any instance of the abstraction

Example

1.21.        Strategy

Defines a family of algorithms, encapsulates each one and makes them interchangeable [Alternative to sub classing – Context ‘has-a’ instead of a ‘is-a’ behavior]

Advantages

• Easier to extend a model to incorporate new behavior

Disadvantages

• Clients must be aware of an understand different strategies
• Increased number of objects
• Single interface for all strategies so simpler implementations may not need all the parameters given – Communication overhead.

Example

1.22.        Template Method

Defines a skeleton of an algorithm in an operation deferring some steps to subclasses

• An alternative to Strategy when there are invariant parts of the algorithm

Advantages

• Fundamental technique for code reuse
• Inverted control structure [parent class calls subclass’s method]

Example      The director in builder pattern may be implementing this pattern – only difference being Builders are not subclasses of Director

1.23.         Visitor

It represents an operation to be performed on the elements of an object structure. 

• Visitor lets us define a new operation without changing the classes of the elements on which it operates
• Each new operation is a subclass of the abstract Visitor

Advantages

• Visitor is after-the-fact substitute for multiple inheritance
• When an element is visited, it calls the visitor operation that corresponds to its class. The element supplies itself as an argument to this operation to let the visitor access its state
• Gathers related operations and separates unrelated ones. [Related operations in visitor and unrelated in their won visitor subclasses
• Visitor can visit objects that do not have same parent class

Disadvantages

• Adding new concrete elements is hard [needs new visitXXX method visitor] Consider whether it is most likely to change the algorithm [visitor] applied over an object structure or the classes that make up the structure
• Breaking encapsulation to allow visitor to access state

Example      jaxb XJC implementation uses Visitor pattern

In the last post I had a short description on webservice security. In this post, we build a secure webservice and create a client to access it. For doing so, the same environment as in the Simple Webservice example is used. We will use Metro’s WSIT features to enable secrity for our webservice.

Creating the webservice

The steps for creating and deploying an unsecured webservice are described in this post. Follow these steps till Step 6 (we do not deploy the webservice yet). Now we need to make the webservice secure.

Generate Key Pair

In order to perform encryption and signature, the webservice and the client need a public-private key pair. The public key is wrapped inside a X509 certificate. In this example we do not use mutual certificates. The private key (or identity key) is with the webservice only. The public key (X509 certificate) is distributed to clients. What is encrypted using the public certificate, can only be decrypted using the private key and vice-versa. In this example, the private key is part of a KeyStore configured on the webservice, and the public certificate is part of a TrustStore configured on the client side.

To create a key-pair for use with this example, create a directory to keep the KeyStore and TrustStore in (call it <KEY_DIR>). Browse to this dir on command prompt and run
keytool -genkey -alias serviceKey -keypass mykeypass -keystore wsKeyStore.jks -storepass changeit -keyalg RSA -dname "CN=Tech Tips, OU=Blog, O=The Tech tips, L=DFW, ST=TX, C=US"

This creates the keystore with the private key in it. Now export the public certificate:
keytool -export -alias serviceKey -keypass mykeypass -keystore wsKeyStore.jks -storepass changeit -file publicCert.cer

and import the public certificate into a truststore:
keytool -import -alias publicCert -keystore wsTrustStore.jks -storepass changeit -file publicCert.cer

Specify Security Requirements

In order to convey their security constraints to clients, webservices can include their security specifications as part of the WSDL. This is done by making use of WS-Security Policy (WSSP) assertions. The clients who have access to the WSDL therefore know the security contract for accessing the webservice.

Instead of creating a custom way of specifying security requirements when creating a webservice, WSIT (part of metro stack) makes use of the already developed way (using WSSP assertions). In order to enable security for our webservice, all we need is a static WSDL-like definitions file which contains the desire WSSP assertions assigned to our endpoint. This file needs to have a special name ‘wsit-<fully qualified implementation class name>.xml‘.

In MetroWebserviceSample eclipse project’s WEB-INF directory, create a file named ‘wsit-test.metro.sample.TestService.xml‘. The contents of this file should be as follows:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.1.2-hudson-182-RC1. -->
<definitions targetNamespace="http://sample.metro.test/"
 xmlns:tns="http://sample.metro.test/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns="http://schemas.xmlsoap.org/wsdl/"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
 xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
 xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy">
 
   <wsp:Policy wsu:Id="TestService_Security_Policy">
  <wsp:ExactlyOne>
   <wsp:All>   
    <sp:SymmetricBinding >
     <wsp:Policy>
      <sp:ProtectionToken>
       <wsp:Policy>
        <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
         <wsp:Policy>
          <sp:WssX509V3Token10/>
          <sp:RequireDerivedKeys/>
          <sp:RequireIssuerSerialReference/>
         </wsp:Policy>
        </sp:X509Token>
       </wsp:Policy>
      </sp:ProtectionToken>
      
      <sp:AlgorithmSuite>      
       <wsp:Policy>
        <sp:Basic128/>
       </wsp:Policy>       
      </sp:AlgorithmSuite>
      
      <sp:Layout>      
       <wsp:Policy>
        <sp:Strict/>
       </wsp:Policy>       
      </sp:Layout> 
      <sp:IncludeTimestamp/>  
      <sp:EncryptBeforeSigning/>   
     </wsp:Policy>
    </sp:SymmetricBinding>
    <sp:Wss11>
            <wsp:Policy>
              <sp:MustSupportRefIssuerSerial/>
            </wsp:Policy>
          </sp:Wss11>
             <sc:KeyStore wspp:visibility="private"
              xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
              xmlns:sc="http://schemas.sun.com/2006/03/wss/server"
              location="<KEY_DIR>\wsKeyStore.jks"
              type="JKS" keypass="mykeypass"
              alias="serviceKey"
              storepass="changeit">
             </sc:KeyStore>
   </wsp:All>
  </wsp:ExactlyOne>
 </wsp:Policy>
 
 <wsp:Policy wsu:Id="TestService_Encryption_policy">
  <wsp:ExactlyOne>
   <wsp:All>    
    <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
     <sp:Body />
    </sp:EncryptedParts>      
   </wsp:All>
  </wsp:ExactlyOne>
 </wsp:Policy>
 <wsp:Policy wsu:Id="TestService_Signature_policy">
  <wsp:ExactlyOne>
   <wsp:All>
    <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
     <sp:Body />
    </sp:SignedParts>
   </wsp:All>
  </wsp:ExactlyOne>
 </wsp:Policy>
 
 
<portType name="TestService">
  </portType>
 
  <binding name="TestServicePortBinding" type="tns:TestService">
   <wsp:PolicyReference URI="#TestService_Security_Policy"></wsp:PolicyReference>
   <wsp:PolicyReference URI="#TestService_Encryption_policy"></wsp:PolicyReference>
   <wsp:PolicyReference URI="#TestService_Signature_policy"></wsp:PolicyReference>
  </binding>
 
  <service name="TestServiceService">
     <!-- Uncomment this section if above configured security is to be enabled -->
     <!-- -->
  
<port name="TestServicePort" binding="tns:TestServicePortBinding">
   </port>
  </service>
</definitions>

The above file has the minimum content required for this configuration (in other situations we can have the complete WSDL, plus the policy declarations and references). It enforces encryption of the SOAP body element followed by signing the encrypted body (EncryptBeforeSigning) for all messages (requests and responses). For the purpose of encryption and signing derived keys based on an X509 token are used. The location of the token is specified using Metro specific element.

Deploy the Webservice

Note that the element describing the location of X509 token (keystore etc) is not visible in the online WSDL.

Create the Client

In order to create a POJO client which does not run inside a container, the Metro libraries will be needed. As indicated in this post, download Metro and put the expand the contents (call this directory <METRO_HOME>).  For convinience the directory <METRO_HOME>/bin can be added to the environment variable Path, so that the tools wsgen and wsimport can be used without qualified location. For JDK 6 onwards, these tools are part of the jdk.

Create a directory for the client code <CLIENT_HOME>. This can as well be an eclipse Java project. However, the instructions here are for running the client without using eclipse.

While the webservice is running on Tomcat, on the command prompt run:
wsimport -d <CLIENT_HOME> -s <CLIENT_HOME> -p test.metro.sample.client http://localhost:8080/MetroWebserviceSample/test?wsdl
This will create the classes needed by the client, under the package structure test.metro.sample.client. Note that the classes are already compiled, so we will not recompile them.

In the directory <CLIENT_HOME>/test/metro, create a directory named client. Create a file TestServiceClient.java in this directory (so the package for this class is test.metro.client). The contents of TestServiceClient.java should be:

package test.metro.client;

import test.metro.sample.client.TestService;
import test.metro.sample.client.TestServiceService;

public class TestServiceClient {

 private String defaultGreeter = "TheTechTips";
 /**
  * @param args
  */
 public static void main(String[] args) {
  
  TestServiceClient client = new TestServiceClient();
  TestService service = new TestServiceService().getPort(TestService.class);
  System.out.println("Greeatings are...");
  if (args.length == 0) {
   System.out.println(service.greet(client.defaultGreeter));
  } else {
   for (String greeter : args) {
    System.out.println(service.greet(greeter));
   }
  }
 }

}

To compile the above class, browse to <CLIENT_HOME> directory on command prompt (for convinience) and run:
javac -cp %CLASSPATH%;.;<METRO_HOME>/lib/webservices-api.jar test/metro/client/TestServiceClient.java

Client Security Configuration

Similar to the wsdl-like file we created for securing the webservice, we need to specify where the client can find the security certificate to send proper requests to the service. The client config file should be named <service>Service.xml and placed in the META-INF directory. In addition, another xml file called wsit-client.xml is to be pesent in META-INF. The latter file imports the former.

Create a META-INF directory under <CLIENT_HOME>. Put files TestServiceService.xml and wsit-client.xml in the META-INF directory with following contents.

TestServiceService.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.1.2-hudson-182-RC1. -->
<definitions targetNamespace="http://sample.metro.test/"
 xmlns:tns="http://sample.metro.test/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns="http://schemas.xmlsoap.org/wsdl/"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
 xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
 xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy">
 
 <wsp:Policy xmlns:sc="http://schemas.sun.com/2006/03/wss/client"
  xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
  wsu:Id="TestService_Security_Client_Policy">
  <wsp:ExactlyOne>
   <wsp:All>
      <sc:TrustStore wspp:visibility="private" location=
        "<KEY_DIR>\wsTrustStore.jks"
        storepass="changeit"
        peeralias="publicCert"/>

   </wsp:All>
  </wsp:ExactlyOne>
 </wsp:Policy>

 
<portType name="TestService">
  </portType>
 
  <binding name="TestServicePortBinding" type="tns:TestService">
   <wsp:PolicyReference URI="#TestService_Security_Client_Policy"></wsp:PolicyReference>
  </binding>
 
  <service name="TestServiceService">
     <!-- Uncomment this section if above configured security is to be enabled -->
     <!-- -->
  
<port name="TestServicePort" binding="tns:TestServicePortBinding">
   </port>
  </service>
</definitions>

wsit-client.xml

<?xml version="1.0" encoding="UTF-8"?>
 <definitions
 xmlns="http://schemas.xmlsoap.org/wsdl/"
 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
name="mainclientconfig">
    <import location="TestServiceService.xml" namespace="http://sample.metro.test/"/>
</definitions>

Run client

To run the client, execute (while command prompt is in <CLIENT_HOME> directory)
java -cp %CLASSPATH%;.;<METRO_HOME>/lib/webservices-api.jar;<METRO_HOME>/lib/webservices-rt.jar test.metro.client.TestServiceClient

The output will be something like
Oct 2, 2009 11:14:43 AM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser] parseModel
INFO: WSP1049: Loaded WSIT configuration from file: file:<CLIENT_HOME>/META-INF/wsit-client.xml
Greeatings are...
Hello TheTechTips!

1. Protocol level security: The security mechanisms used for regular request/response for the particular protocol. For example, Basic Authentication and SSL certificates for HTTP. These mechanisms only ensure that the messages are secured till they reach the protocol (say HTTP) destination. After that, when the actual SOAP message is un secured till it reaches the actual Web service endpoint.
2. SOAP message security: In this case the messages are to be secured all the way to the endpoint beyond the protocol level. This is specified by the WS-Security specifications.

WS-Security Specification

The WS-Security specification 1.0 was released in 2002. The next version 1.1 was released in 2006. It specifies how to enhance SOAP messages to secure the information exchange.

From the WS-Security specification (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss#overview):

“WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies.”

The WS-Security spec provides SOAP extensions that can be used when building secure web-services. There are three main aspects of security:

1. Message AuthenticationWS-Security provides a way of associating security tokens with SOAP messages. These tokens (like Basic Authentication or SSL certificates for HTTP) can be used to identify the sender of the message. The specification does not require use of any particular token. Two commonly used tokens are Username tokens and X509 tokens. Other tokens like Kerberos tokens can also be used. These tokens can be included directly in the SOAP message header, or an indirect reference to the token can be sent using digital signature or encryption.
2. Message Integrity Message integrity ensures that the message was not tampered with on its way from the sender to the receiver. WS-Security provides a way to include XML digital signatures in the SOAP message header to help verify integrity. Exactly what parts of the message are signed or what digest/algorithms are used is left to be decided by the web-service provider.
3. Message ConfidentialityMessage confidentiality means that on the wire, the message should not be readable. WS-Security specifies how the full message or parts of the message can be encrypted and sent so that they are unreadable to attackers. This will use XML encryption and the encryption related information is exchanged in the SOAP header. Either the whole message can be encrypted (like HTTPS transport encryption), or parts of the message are encrypted. Again, the encryption algorithms to be used, the way of exchanging keys (or tokens) is to be decided by the web-service provider. 

In the next post, I am going to create a secure web services using JAXWS implementation Metro and create client for the service. Explaining the various types of security in more detail.

An EJB3 session bean’s remote business interface needs to have RMI-IIOP compatible interface according to the EJB3 spec. In addition EJBs should be available over CORBA/IIOP for interoperability. The EJB’s remote home or remote business object obtained over IIOP need to type narrowed instead of plain type casting.

In JBoss the EJBs are not bound to CORBA Naming Service by default. That means if we just deploy annotated EJBs in a ejb-jar file to JBoss, they will not be available over IIOP protocol. Instead the beans are available over JBoss’s JNP protocol. When trying to access EJBs over JNP, we must use an array jboss client jar files in the client’s classpath. This works fine in most scenarios, until we want to access from non Java client or in a situation where we have library conflicts.

What works:

What does not work:

EJB3 Session Bean:

Because of changes between JBoss 4.2.x and 5.x, the IIOP enabled EJB3 session bean looks different in the two versions.

For JBoss 4.2.x, the interface and bean are

package test.ejb3;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;

public interface TestSessionRemote extends EJBObject{
 public String greet(String name) throws RemoteException;
}

package test.ejb3;

import javax.ejb.Remote;
import javax.ejb.Stateless;
import org.jboss.annotation.ejb.RemoteBinding;
import org.jboss.ejb3.iiop.IORFactory;

/**
 * Session Bean implementation class TestSessionBean
 */
@Stateless
@Remote(TestSessionRemote.class)
@RemoteBindings({
 @RemoteBinding(factory=IORFactory.class),
 @RemoteBinding(factory=StatelessRemoteProxyFactory.class)
})
public class TestSessionBean {
     public String greet (String name) {
  if (name != null && name.trim().length() > 0) {
   return "Hello " + name + "!";
  } else {
   return "No one to greet.";
  }
 }
}

Note that according to EJB3 specification, the remote business interface MUST NOT extend EJBObject, but that is allowed in JBoss 4.2.x.  Also, our EJB3 cannot be accessible over IIOP if the remote business interface does not extend EJBObject. This may be a bug or just an unsupported feature. Another thing to notice here is that the bean class does not implement the remote business interface (does not declare that it implements). In JBoss 5 these have been corrected and the remote business interface cannot extend EJBObject.

For JBoss 5.x, the interface and bean are

package test.ejb3;

public interface TestSessionRemote {
 public String greet(String name);
}

package test.ejb3;

import javax.ejb.Remote;
import javax.ejb.Stateless;
import org.jboss.ejb3.annotation.RemoteBinding;
import org.jboss.ejb3.annotation.defaults.RemoteBindingDefaults;

/**
 * Session Bean implementation class TestSessionBean
 */
@Stateless
@Remote(TestSessionRemote.class)
@RemoteBinding(factory=RemoteBindingDefaults.PROXY_FACTORY_IMPLEMENTATION_IOR)
public class TestSessionBean implements TestSessionRemote {

 public String greet (String name) {
  if (name != null && name.trim().length() > 0) {
   return "Hello " + name + "!";
  } else {
   return "No one to greet.";
  }
 }
}

No other configuration is required because we are using annotations to provide all configurations for the beans. These two classes can be directly packaged into a .jar file (with proper directory structure according to package) and deployed to JBoss. Once the JBoss server is started, the deployed EJBs JNDI bindings and Corba Naming bindings can be viewed in jmx-console.

Client:

The reason for using IIOP is that the same client can work on any EJBs available over IIOP.  Below is the client that we use for testing invocation of EJB3 session bean over both IIOP and JNP.

package test.ejb3.client;

import java.util.Properties;
import javax.naming.InitialContext;
import test.ejb3.TestSessionRemote;

public class TestClient {
 
 static final String IIOP_PROVIDER_URL = "corbaloc::localhost:3528/JBoss/Naming/root";
 static final String JNP_PROVIDER_URL = "localhost:1099";
 static final String JNDI_NAME = "TestSessionBean/remote";
 
 public static void main (String[] args) {
  TestClient client = new TestClient();
  try {
   client.testJNPInvocation();
  } catch (Exception ex) {
   System.out.println("Error in JNP test: "+ ex.getMessage());
   ex.printStackTrace();
  }
  try {
   client.testIIOPInvocation();
  } catch (Exception ex) {
   System.out.println("Error in IIOP test: "+ ex.getMessage());
   ex.printStackTrace();
  }
 }
 
 private void testJNPInvocation() throws Exception{
  Properties props = new Properties();
  props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
  props.put(InitialContext.PROVIDER_URL, JNP_PROVIDER_URL);
  props.put(InitialContext.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
  
  System.out.println("Running JNP test...");
  InitialContext intCtx = new InitialContext(props);
  System.out.println("Found JNP InitialContext");
  
  Object obj = intCtx.lookup(JNDI_NAME);
  TestSessionRemote remote = (TestSessionRemote) obj;
  System.out.println("Found JNP EJB Remote");
  invokeEJB(remote);
 }
 
 private void testIIOPInvocation() throws Exception{
  Properties props = new Properties();
  props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");
  props.put(InitialContext.PROVIDER_URL, IIOP_PROVIDER_URL);
  
  System.out.println();
  System.out.println("Running IIOP test...");
  InitialContext intCtx = new InitialContext(props);
  System.out.println("Found IIOP InitialContext");
  
  Object obj = intCtx.lookup(JNDI_NAME);
  TestSessionRemote remote = (TestSessionRemote) javax.rmi.PortableRemoteObject.narrow(obj, TestSessionRemote.class);
  System.out.println("Found IIOP EJB Remote"); 
  invokeEJB(remote);
 }
 
 private void invokeEJB (TestSessionRemote remote) throws Exception{
   System.out.println("Invoke result: "+remote.greet("World"));
 }
}

In order to run this client, the EJB3 interface must be in the classpath. Therefore, create two jar files with only the interface TestSessionRemote in them (two jar files one for each version of the interface above). Let us name the jar files EJB3ExampleJBoss4.jar and EJB3ExampleJBoss5.jar.

To run the client, create a directory in desired location (lest call it <CLIENT_DIR>). Under <CLIENT_DIR>, create the directory structure test/ejb3/client/ and put the TestClient.java file there. Place the jar files EJB3ExampleJBoss4.jar and EJB3ExampleJBoss5.jar directly under <CLIENT_DIR>. Now compile and run the client (these steps are for jdk-5): 

1. cd <CLIENT_DIR>
2. Compile the client:
   • For JBoss 4.2.x client:
     javac -cp %CLASSPATH%; EJB3ExampleJBoss4.jar; <JBOSS4_HOME>\server\default\lib\jboss-j2ee.jar test\ejb3\client\TestClient.java
   • For JBoss 5.x client:
     javac -cp %CLASSPATH%; EJB3ExampleJBoss5.jar test\ejb3\client\TestClient.java
3. Run the client: Put the appropriate location for <JBOSS_HOME> below (Jboss4.2.x of 5.x locations for respective clients):
   • For JBoss 4.2.x client:
     java -cp %CLASSPATH%; EJB3ExampleJBoss4.jar; <JBOSS4_HOME>\client\jbossall-client.jar -Djava.security.manager -Djava.security.policy=C:\client.policy test.ejb3.client.TestClient
   • For JBoss 5.x client:
     java -cp %CLASSPATH%; EJB3ExampleJBoss5.jar; <JBOSS5_HOME>\client\jbossall-client.jar -Djava.security.manager -Djava.security.policy=C:\client.policy test.ejb3.client.TestClient
   • We are using the jbossall-client.jar only for the JNP test. For running just the IIOP test, no JBoss specific files are needed.
4. Note that the java.security.manager and java.security.policy parameters are needed because we do not have static stubs for the EJB. So the client ORB will need to download the stubs dynamically at runtime. The download will fail with a proper security principal being set. Since we did not enforce any security roles on the server side (in the bean or in config), all roles are allowed. The client.policy file used above just indicates that:
   grant { // Allow everything for now        
   permission java.security.AllPermission;
}; 

When JBoss4.2.x example is running, the output is:

Running JNP test...
Found JNP InitialContext 
log4j:WARN No appenders could be found for logger (org.jnp.interfaces.TimedSocketFactory).
log4j:WARN Please initialize the log4j system properly.
Found JNP EJB Remote
Invoke result: Hello World!

Running IIOP test...
Found IIOP InitialContext
Found IIOP EJB Remote
Invoke result: Hello World!

When JBoss 5.x example is running, the output is:

Running JNP test...
Found JNP InitialContext
log4j:WARN No appenders could be found for logger (org.jnp.interfaces.TimedSocketFactory).
log4j:WARN Please initialize the log4j system properly.
Found JNP EJB Remote
Invoke result: Hello World! 

Running IIOP test...
Found IIOP InitialContext
Error in IIOP test: null
javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]  
at com.sun.jndi.cosnaming.ExceptionMapper.mapException(Unknown Source)  
at com.sun.jndi.cosnaming.CNCtx.callResolve(Unknown Source)  
at com.sun.jndi.cosnaming.CNCtx.lookup(Unknown Source)  
at com.sun.jndi.cosnaming.CNCtx.lookup(Unknown Source)  
at javax.naming.InitialContext.lookup(Unknown Source)  
at test.ejb3.client.TestClient.testIIOPInvocation(TestClient.java:55)  
at test.ejb3.client.TestClient.main(TestClient.java:22)

As we can see, the EJB3 access over IIOP does not work for JBoss 5.x. If anyone has been able to access these EJBs over IIOP while running on JBoss5.x, please correct me. 

System Environment

1. JRE 1.5.0_10
2. Tomcat 5.5.28
3. Eclipse 3.2

Introduction

JAXWS stands for Java API for XML Web Services. It is the new web services specification for creating and consuming web services in J2EE. It makes use of annotations for creating web services and their clients.

JAXB stands for Java API for XML Binding. It is the new xml binding specification for Java to XML and XML to Java binding (again makes use of annotations). The bindings can also be specified using xml files.

Metro is Sun’s web services stack also packaged with the Glassfish server. It includes WSIT (Web Service Interoperability Technologies) in addition to JAXWS-RI and JAXB-RI (Sun’s reference implementations of the specs).

Creating the Service

Before starting, download Metro and extract the libs. Lets create a simple servlet endpoint using a POJO now.

1. Create a Dynamic Web Project in Eclipse (lets name it MetroWebserviceSample).
2. Copy the Metro download’s webservices-api.jar, webservices-rt.jar and webservices-extra.jar to WEB-INF/lib.
3. Under the java source directory (the ‘src’ directory), create a new package named test.metro.sample.
4. Create a class TestService.java under test.metro.sample package. 

   
   package test.metro.sample;
   
   import javax.jws.WebService;
   
   @WebService
   public class TestService {
    public String greet (String name) {
     if (name != null && name.trim().length() > 0) {
      return "Hello " + name + "!";
     } else {
      return "No one to greet.";
     }
    }
   }
   
   

5. Configure WSServlet and WSServletContextListener to web.xml. This servlet should be set up to load on start-up

   
   <?xml version="1.0" encoding="UTF-8"?>
   <web-app id="WebApp_ID" version="2.4" xmlns="<a href="http://java.sun.com/xml/ns/j2ee">http://java.sun.com/xml/ns/j2ee</a>" xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001/XMLSchema-instance</a>" xsi:schemaLocation="<a href="http://java.sun.com/xml/ns/j2ee">http://java.sun.com/xml/ns/j2ee</a> <a href="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd</a>">
    <display-name>MetroWebserviceSample</display-name>
    
   	<listener>
   	<listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class>
    </listener>
    <servlet>
       <description>JAX-WS + WSIT endpoint - wsit-enabled-fromjava</description>
       <display-name>wsit-enabled-fromjava</display-name>
       <servlet-name>TestWebService</servlet-name>
       <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
       <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
       <servlet-name>TestWebService</servlet-name>
       <url-pattern>/test</url-pattern>
    </servlet-mapping>
   </web-app>
   
   

6. The WSServlet looks at a config file sun-jaxws.xml to deploy the webservices specified in this config file. Create the following sun-jaxws.xml and put it in the WEB-INF directory

   
   <?xml version="1.0" encoding="UTF-8"?> 
   
   <endpoints xmlns='http://java.sun.com/xml/ns/jax-ws/ri/runtime' version='2.0'>
       <endpoint name='TestService'
           implementation='test.metro.sample.TestService'
           url-pattern='/test'/>
   </endpoints>
   
   

7. Right click the eclipse project MetroWebserviceSample and export to a .war  file (MetroWebserviceSample.war).
8. Copy MetroWebserviceSample.war to <TOMCAT_HOME>/webapps and start the Tomcat server.
9. The WSDL can be looked up at http://localhost:8080/MetroWebserviceSample/test?wsdl.

SOAP-UI can be used to quickly test that the webservice is working. Eclipse also has a tool called, ‘Web Services Explorer’ which can be used to quickly test webservices. The steps for creating a Java client will be included later.

T3

Will follow up with the first post soon.

T3