Chain of Responsibility
The Java Servlet filter framework is an example of chain of resposibility design. Note that the chain.doFilter() is the method that should be called to make the chain roll. If the subclass missed it, the whole chain would be stopped or blocked.
Java exception handling is another example of chain of responsibility design. When an error occurs, the exception call will look for a handling class. If there is no handler, the super Exception class will be called to throw the exception. Otherwise, the handler class will handle it.
Mediator (Allows loose coupling by encapsulating the way disparate sets of objects interact and communicate with each other. Allows for the actions of each object set to vary independently of one another. )
An airport control tower is an excellent example of the mediator pattern. The tower looks after who can take off and land - all communications are done from the airplane to control tower, rather than having plane-to-plane communication. This idea of a central controller is one of the key aspects to the mediator pattern.
An observer based variation of the mediator pattern is used in Java Message Service (JMS) implementations, which allows applications to subscribe and publish data to other applications. This is a common combination of patterns that makes sense.
Aspect-oriented programming is a way of modularizing crosscutting concerns much like object-oriented programming is a way of modularizing common concerns. AspectJ is an implementation of aspect-oriented programming for Java.
AOP's core idea is "separating the business logic in an application from the common services that support it," according to Adam Magee, a Senior Solution Architect with Avanade, a technology integrator that specialises in Microsoft technologies.
正如Avanade公司的高级方案构架师Adam Magee所说,AOP的核心思想就是“将应用程序中的商业逻辑同对其提供支持的通用服务进行分离。”
IIOP is CORBA's communication protocol. It defines the way bits are sent over a wire between CORBA clients and servers. CORBA is a standard distributed object architecture developed by the Object Management Group (OMG). Interfaces to remote objects are described in a platform-neutral interface definition language (IDL). Mappings from IDL to specific programming languages are implemented, binding the language to CORBA/IIOP.
Java class loader hierarchy
We have 3 main class loader :
- Bootstrap class loader, called primordial class loader. It's a part of the JVM., and is responsible for loading classes from the core Java package (java.lang, java.util etc.) These classes are found in JAVA_HOME/jre/lib/rt.jar.
- Extension class loader. It monitors the JAVA_HOME/jre/lib/ext folder and load the existing jars.
- System class loader. It monitors the folders and Jars which can be find in the classpath.
An important point is that a class loader can only see the class locations that are above it in the hierarchy. So a class loaded from Extension class loader can't see a class from the class path.
Bootstrap classloader is the parent of all classloaders and loads the standard JDK classes in lib directory of JRE (rt.jar and i18n.jar). All the java.* classes are loaded by this classloader.
Extensions Classloader is the immediate child of Bootstrap classloader. This classloader loads the classes in lib\ext directory of the JRE. For example, JDK1.4.x ships with its own implementation for JCE. The JCE implementation is identified by the sunjceprovider.jar and is present in JRE/lib/ext directory and is loaded by the extensions classloader.
System-Classpath classloader is the immediate child of Extensions classloader. It loads the classes and jars specified by the CLASSPATH environment variable, java.class.path system property, -cp or –classpath command line settings. If any of the jars specified in one of the above manner have a MANIFEST.MF file with a Class-Path attribute, the jars specified by the Class-Path attribute are also loaded.
LDAP
So What is a Directory?
A directory is a type of heirarchical database. It is made up of entries, that have a globally unique name, and contain attributes that are named collections of data values. A simple conceptual example:
A country { relative name 'c=au' , description = 'Australia' }
|
|
---- A company { relative name = 'o=computer associates', web address = 'www.ca.com' }
|
|
----- A person { relative name = 'cn=Chris', favorite drink = 'japanese slipper' }
|
----- A person { relative name = 'cn=Trudi', favorite drink = 'beer' }
|
----- A person { relative name = 'cn=Jay', favorite drink = 'mineral water' }
This shows a simple directory with five entries. Each entry has a unique name relative to its parent called its 'relative distinguished name' or RDN. The combination of all its ancestors RDNs is called the 'distinguished name' - hence the distinguished name of the last entry above would be "c=au, o=computer associates, cn=Jay".
Each LDAP directory can have a root DN (rootdn), which is similar to the superuser account on Unix systems. When authenticated, this DN is authorized to do whatever the user desires.The root DN also requires a corresponding root password (rootpw), which can be stored in clear text or encrypted form using one of the prefixes accepted by the password-hash parameter.
The binddn and bindpw parameters provide a means of specifying the credentials to use when contacting the remote LDAP directory.
LDAP URLs have the following syntax:
ldap[s]://hostname:port/base_dn?attributes?scope?filter
Component |
Description |
hostname |
Name (or IP address in dotted format) of the LDAP server. For example, ldap.example.com or 192.202.185.90. |
port |
Port number of the LDAP server (for example, 696). If no port is specified, the standard LDAP port (389) or LDAPS port (636) is used. |
base_dn |
Distinguished name (DN) of an entry in the directory. This DN identifies the entry that is the starting point of the search. If no base DN is specified, the search starts at the root of the directory tree. |
attributes |
The attributes to be returned. To specify more than one attribute, use commas to separate the attributes; for example, cn,mail,telephoneNumber. If no attributes are specified in the URL, all attributes are returned. |
scope |
The scope of the search, which can be one of these values:
base retrieves information only about the distinguished name (base_dn) specified in the URL. |
one retrieves information about entries one level below the distinguished name (base_dn) specified in the URL. The base entry is not included in this scope. |
sub retrieves information about entries at all levels below the distinguished name (base_dn) specified in the URL. The base entry is included in this scope. |
If no scope is specified, the server performs a base search. |
filter |
Search filter to apply to entries within the specified scope of the search. If no filter is specified, the server uses the filter (objectClass=*). |
(
General structure of an LDAP tree)
An entry can be located in LDAP by specifying either the distinguished name (dn
) or the relative distinguished name (rdn
). The dn
is the full LDAP tree path whereas the rdn
is just a unique identifier for a specific entry in the tree.
One way to easily conceptualize the difference between the dn
and rdn
is to think of the difference between directions and an address. The dn
would be equivalent to giving directions from the airport to a hotel. The rdn
would just be the address of the hotel. Similar to an address a rdn
must be unique. It would be very difficult to find your hotel on a city map if its address was not unique.
Ref
http://java.dzone.com/articles/design-patterns-mediator
http://docs.oracle.com/javase/tutorial/rmi/compiling.htmlhttp://avricot.com/blog/index.php?post/2011/02/18/tomcat-class-loader%2C-priority-orderhttp://www.javapractices.com/source/SourceAction.do;jsessionid=8B35187C2A4BA9742D2DD5A35F98B6E4http://www.objectsource.com/j2eechapters/Ch21-ClassLoaders_and_J2EE.htm http://www.keutel.de/directory/public_ldap_servers.html