Desing Web Services "Contract First"

In the Web Service arena many developers have recognised that the good old software engineering principles still apply these days: First discuss and design the interface and then implement it:

• The virtue of contract-first


• Thoughts on a SOA, part 3: It’s the Contract, stupid!
  

I somehow agree with this principle due to the following reasons:

• Interface constraints or restrictions cannot be expressed exactly enough using programming languages. For example: "enumerations of concrete values" or "date vs time" etc.
  
• Interface very often contains only subset of the internal domain data, maybe even transformed, often restricted. A separate layer of mapping is usually anyway requred.
• Designing the contract first encourages early discussion and agreement with service partners.
  
• Designing the contract first encourages explicit considerations of interoparability compliance (for example WS-I Basic Profile) instead of completely relying on a tool
  

Web Service toolskits on the other hand often encourage developers to use there well known programming environment and extract a the contract (WSDL) .

Axis supports contract first with it's WSLD2Java tool.

The open question is how good J2EE Web services (JSR 109) support this approach?

ALPS touchpad on Ubuntu breezy for Dell 510m

These observations were made with Ubuntu Breezy which has Kernel 2.6.12-9 and the Synaptics Driver Version 0.13.6 at the time this log entry is written.

The latest version and more information can be found at:
http://web.telia.com/~u89404340/touchpad/

1. check that the kernel modules are loaded:
$ lsmod | grep psmouse
$ lsmod | grep evdev

(Ubuntu Kernel has both of them compiled as modules: see CONFIG_MOUSE_PS2 and CONFIG_INPUT_EVDEV)

Unlike mentioned in the Ubuntu forums at several places (http://ubuntuforums.org/showthread.php?t=75431) I did not have to load the psmouse with any options like proto=EXPS. In fact doing this prevented the kernel from correctly detecting the ALPS touchpad.

2. check that the the touchpad is detected by the kernel:
$ cat /proc/bus/input/devices

I: Bus=0011 Vendor=0002 Product=0008 Version=7321
N: Name="AlpsPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio1/input0
H: Handlers=mouse1 event2 ts1
B: EV=f
B: KEY=420 0 70000 0 0 0 0 0 0 0 0
B: REL=3
B: ABS=1000003

3. Configure the /etc/X11/xorg.conf:

3.1 Load the synaptics driver in Section "modules":
Load "synaptics"

3.2 Configure the ALPS touchpad. Important is the Device (same reported before in Step 2) and the Protocol :

Section "InputDevice"
Identifier "ALPS"
Driver "synaptics"
Option "AlwaysCore"
Option "Device" "/dev/input/event2"
Option "Protocol" "event"
Option "LeftEdge" "120"
Option "RightEdge" "830"
Option "TopEdge" "120"
Option "BottomEdge" "650"
Option "FingerLow" "14"
Option "FingerHigh" "15"
Option "MaxTapTime" "180"
Option "MaxTapMove" "110"
Option "ClickTime" "0"
Option "EmulateMidButtonTime" "75"
Option "VertScrollDelta" "10"
Option "HorizScrollDelta" "0"
Option "MinSpeed" "0.45"
Option "MaxSpeed" "0.75"
Option "AccelFactor" "0.020"
Option "EdgeMotionMinSpeed" "200"
Option "EdgeMotionMaxSpeed" "200"
Option "UpDownScrolling" "1"
Option "CircularScrolling" "0"
Option "CircScrollDelta" "0.1"
Option "CircScrollTrigger" "2"
Option "SHMConfig" "true"
EndSection

3.3 Add the ALPS touchpad to the ServerLayout section:

Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "ALPS"
InputDevice "Configured Mouse"
EndSection

Those steps helped to get the ALPS touchpad working without having to compile a new version of the driver.

How to access the Spring Business Layer from Struts Web Layer

As usual with software there is not one right way to do things (Especially with open source software).
One question is still "How to access the Spring Business Layer from the Struts Web Layer".

I currently can see the following options:

Option 1: Hand code lookups by name

ServletContext context = request.getSession().getServletContext();

BeanFactory factory = WebApplicationContextUtils.

      getRequiredWebApplicationContext(context);

AccountService accountService = (



      AccountService) factory.getBean("accountService");

//...

//use the accountService

- This allows only access to the root WebApplicationContext loaded by the ContextLoaderListener

Option 2: Extend Spring's ActionSupport classes instead of Struts Action classes
Spring offers 4 extensions for Struts Action classes just to make the above mentioned access more convenient:
- Spring ActionSupport extends Struts Action
- Spring DispatchActionSupport extends Struts DispatchAction
- Spring LookupDispatchActionSupport extends Struts LookupDispatchAction
- Spring MappingDispatchActionSupport extends Struts MappingDispatchAction

BeanFactory factory = getWebApplicationContext();

AccountService accountService = 

    (AccountService) factory.getBean("accountService");

//...

//use the accountService

+ Allows to define individual WebApplicationContext per ActionServlet (do we need that?) and falls back to the root WebApplicationContext

Option 3: Use Spring managed Actions by using DelegetingActionProxy
Spring offers the DelegatingActionProxy
This allows to delegate the Action creation to Spring and allows to wire up the Actions with the business components directly by using Spring configuration

In Struts.xml:

<action path="/doit" 

           type="org.springframework.web.struts.DelegatingActionProxy">

In the Spring context:

<bean name="/doit" class="my.action">

  <property name="...">...</property>

</bean>

- Some generation tools do want to generate "Origanl Actions" not the Proxy Action.
+ Any request processor can be used with this


Option 4: Use Spring managed Actions by using DelegetingRequestProcessor
Similar to Option 3 but not using delegating Actions but using a Request processor.

In Struts.xml:

<action path="/doit" type="my.Action">

In the Spring context:

<bean name="/doit" class="my.Action">

   <property name="...">...</property>

</bean>

- only one RequestProcessor is allowed -> there is "out-of-the-box" DelegatingRequestProcessor and a TilesDelegatingRequestProcessor in Spring

Hibernate enums deprecated

One charachteristic of enumerations is that they are static. They possible enumerated values cannot be changed at run time. If the allowed values should be changeable it's problably not an enumeration but more a separate entity.
Enumerations are that static that their values are known when coding against them.

Hibernate does provide a method to persist enumerations. Nevertheless the Java Interface PersistentEnum is depricated
I found some suggestions for how to persist enumerations with hibernate:

1. UserType per EnumType


2. Extend PersistenEnum usertype


3. A Forum Article



4. Go for the non type save way and just use public static final int or String values

I'll check the first option by trying to map jakarta-commons-lang enums with hibernate. (I'll also have to check how this will behave in future with Java 5 enums)
Results will be posted here as soon as possible

Conainer Managed Auth. vs Application Managed Auth. in J2EE web applications

Authentication and Authorisation (Auth.) is part of the J2EE standard.

One design question that arises in each J2ee web application project is the wheter to use Conatiner Managed Auth. (CMA) or to impement own Application Managed Auth. (AMA).

CMA in pure web applications:

• standard way for application to query if the user has given role
• standard way to define how the user is authenticated (Basic authengication, Form-based authentication..)

on the other hand CMA

• does not define how an application server stores and retrieves the authentication/authorsisation information (username/password, roles). This is left to the application server provider or to the application developer.
  
• does not define how one plug in code into an application server to extend the authentication with more advanced authentication strategies (Captcha etc.)
• does not define how to maintain the Authentication/Authorisation information (e.g. how a user could change his password or how an administrator can add/remove roles)

AMA :

• is portable across application servers
• can be customized to any extend (e.g. authentication based on dynamic information)
  

on the other Hand AMA:

• introduces a security risk due to buggy implementation
  
• is not standardized

Definitly - if all use cases can be implemented with CMA one shold use it. But how often is that the case in real world web applications?

References:

• J2EE security: Container versus custom
  

UML 2.0: semantical difference between composition and aggregation

Associations are describing a set of tuples of typed instances.

In general there is no semantic difference between the instances paricipating in such a tuple. Very often though one of the instances is playing the special role of a whole whereous the others represent the parts of that whole. As an example take the association between companies and departments. Departments are part of a company. Such forms of whole-part associations are Aggregations and Compositions.

An Aggregation is adding semantic information to a general Association by defining which end is the whole and which is the part.
A Composition is an even stronger kind of aggregation. The instance that is composing the parts is responsible for the life-cycle of the parts i.e. a part can not live without the whole and a part can at a given time only be owned by one whole. (Nevertheless is it possible that the part can be passed to an other owner)

Aggregation and Composition are not represented sub types of a general Association in UML 2.0 as one could think at the first glance. Instead an attribute of an associations member properties of the type AggerationKind is controlling this aspect.

AggregationKind is an Enumeration with the following literals:

• none
• shared
• composite

UML 2.0: who owns properties

In UML 2.0 properties can be owned by ether a class or an association.

In case the property is owned by a class it is called attribute i.e. attribute is a role a property can take. There are two notations for attributes:

1. as attribute inside a class
2. as assiociation end (at the navigable end). The role name is the name of the attribute

Both notations are equivalent.

In case an association has an association end that is not navigable the property is not owned by the class at the association end but the association itself.

The navigability of an association end therefore detirmins the ownership of the property:

navigable	property is owned by the class at opposite end (attribute)
not navigable	property is owned by assiciation

Firefox ldif file processor for importing int windows address book

Firefox correctly encodes special characters like German "Umlaut" characters according to the LDIF RFC 2849.

In order to successfully import such ldif file into the windows address book the character encoding has to be changed from UTF-8 to iso-8859-1 (found by experiment):

1. filter for lines with properties separated by double colon (instead of single colon)
2. decode the value using Base64 decoder
3. convert the byte stream into a character stream using a UTF-8 decoder
4. convert the character stream into a byte stream using a ISO-8859-1 encoder
5. encode the byte stream with a Base64 encoder

After this conversion the file can be succesfully imported into the windows address book.