Software Design

Beck’s rules for simple design:

  1. Pass all tests.
  2. Code should communicate.
  3. Avoid duplication.
  4. All things being equal, code should have fewest classes & methods.

Code usually communicates HOW,  not able to communicate WHY, and almost impossible to communicate WHY NOT.


Webservice Security


WS-Trust[WS-SecurityPolicy 1.2, SAML 2.0, UT, X.509, SAML, Kerberos profile]
CXF provides an implementation
OASIS is the standard extension to WS-Seurity dealing with issuing, renewing, validating etc.,

WS-Trust Architecture:

  • Requestor
  • Relying Party
  • Security Token
  • Claims (ex: privileges)
  • Policy
  • STS (Issue, Validate, Renew, Cancel)

SAML Architecture:

  • Assertions (format of a SAML Token):
    • AuthN data like tokens
    • AuthZ data like roles/privileges
    • Security attributes like issuer identity, name & address of subject
  • Protocols: describes request, response messages for operations such as Issue, Renew etc.,
  • Bindinds: Protocols to Network protocol mappiing
  • Profiles: particular use case of building a security system based on SAML

WS-Trust is independent of SAML but very similar.


  • Bearer Scenario: Server trusts if signarute is verified by the public key of the STS.
  • Holder-of-the-Key Scenario: In addition to Bearer Scenario the server authenticates the client using X.509 or UserToken credentials.

STS Architecture:


  • Logical (Type definitions & Port types)
  • Physical (policies, binidng)


  • Issue
  • Renew
  • Validate
  • Cancel

Policies: Boils down to the following three types of policies

  • Transport Layer Security (TLS):
    • X.509 (during SSL/TSL handshake)
    • UT token in SOAP header
  • Symmetric Binding:
    • Security is in SOAP layer( initiator must use UT token)
  • Asymmetric Binding:
    • Security is in SOAP layer( initiator must use X.509 certificate)

3 levels of policies:

  1. Binding Policy -> applies to all operations.
  2. Input Policy -> applies to the request.
  3. Output Policy -> applies to the response.

Example Binding Policy: Symmetric Key Binding & Clients must include UT credentials to authenticate themselves to STS.
<wsp:Policy wsu:Id=”####”>
<sp:IncludeTimestamp />
<sp:EncryptSignature />
<sp:OnlySignEntireHeadersAndBody />

The TokenIssueOp is customizable with staticSTSProperties, pluggable providers(CXF provides SAML & SCT providers)  & a new service.

STSProperties specifies the following:

  • Issuer: Uniquely identifies the STS (used in validating & reognizing issued tokens)
  • Callback Handler: (implement ) to provide passwords
  • Signature Key: Key to sign SAML tokens
  • Encryption Key: Key to Encrypt tokens
  • Realm Settings: ???


Bad Smells in Code
Smell Refactorings Priority
Alternate Class With Different Interfaces
  • Rename Method
  • Move Method
Combinatorial Explosion
  • Tease Apart Inheritance
  • Replace Inheritance with Delegation
  • Extract Method
  • Introduce Assertions
  • Rename Method
Data Class
  • Move Method
  • Encapsulate Field/Collection
Data Clumps
  • Extract Class
  • Introduce Parameter Object
  • Preserve Whole Object
Divergent Change
  • (One class needs to be changed in different ways for different reasons) Extract Class for each change – you feel better to have two classes handling changes separately than changing some methods of One class for several changes.
Duplicate Method
  • Extract Method
  • Extract Class
  • Pull Up Method
  • Form Template Method
Feature Envy
  • Move Field
  • Move Method
  • Extract Method
Inappropriate Intimacy
  • Move Method/Field
  • Change Bi-Directional to Uni-Directional Association
  • Replace Inheritance with Delegation
  • Hide Delegate
Incomplete Library Class
  • Introuce Foreign Method (helper method on a library class – use the libray class as first parameter)
  • Introduce Local Extension (lot of helper method’s for library class – extend the library class and use it).
Large Class
  • Extract Class
  • Extract Subclass
  • Extract Interface
  • Extract Domain Object (Duplicate Observed Data)
Lazy Class
  • Inline Class
  • Collapse Hierarchy
Long Method (Clean up straight-line code)
  • Extract Method (comments -OR- white lines  that deliniate code)
  • Replace temp with query
  • Replace Method with Method Object (Convert all the temp variables on the method to fields of a Object and use them to call the method)
  • Decompose Conditional (extract conditional logic to named method)
Long Parameter List
  • Replace Parameter with Method
  • Preserve the Whole Object
  • Introduce Parameter Object
Message Chains
  • Hide Delegate. (for all client calls to the delegates, let the server deal with the delegate and expose the API to client ex: employee.getDepartment().getManager())
  • Tell Don’t Ask (Law of Demeter) ex: a.b().c().d() (directly or indirectly).
Middle Man
  • Inline Method
  • Replace Delegation with Inheritance
  • Remove Middle Man
Parallel Inheritance Hierarchies
  • Move Method
  • Move Field
Primitive Obsession
  • Replace Data Value with Object
  • Replace Array with Object etc.,
Refusal Bequest
  • Replace Inheritance with Delegation (subclass only uses part of superclass or only inherits part of data).
Shotgun Surgery
  • (Opposite to Divergent Change. For one change lot of small changes to lot of classes) Move Method/Field
  • Inline Class.
Speculative Generality
  • Collapse Hierarchy
  • Inline Class
  • Remove Parameter
  • Rename Method
Switch Statements
  • Replace Conditional with Polymorphism
  • Replace Type code with Class
  • Replace Type code with Subclasses
  • Replace Type Code with State/Strategy
  • Replace parameter with Explicit Methods
  • Introduce Null Object (replace checks for null references with Null Objects).
Temporary Field
  • Extract Class
  • Introduce Null Object