AXIS custom BeanSerializer

I recently implemented a custom BeanSerializer for AXIS. The reason for implementing (or actually extending the existing) was the lack of good configurable BeanSerializer.

We needed to expose existing model objects with Collections, hiding some properties or even adding new solely for the web service. To do so, we had the choice of making data-transfer-objects only to be used for the web service, and copying values from the model objects to the DTO's or dramatically extending the BeanSerializer. We chose the latter.

I extended the existing BeanSerializer to read an XML configuration and using this both when generating the WSDL and actually serializing the beans.

<serializer>
  <bean class="my.package.Bean">
    <exclude>*.</exclude>
    <include>owner</include>
    <include>someString</include>
    <introduce property="newString">serializer.introductions.BeanNewString</introduce>
    <map property="owner">serializer.maps.OwnerToId</map>
  </bean>
<serializer>

As you can see, the configuration example for bean my.package.Bean states:

All properties should be excluded
Then include property owner
Include property someString
Introduce new property (which is NOT available on the bean) newString
Finally the property of name owner should be mapped using the serializer.maps.OwnerToId mapper.

Including and excluded is pretty straigtforward. Introductions are merely the possibility to add new properties. An introduction is called during generation of the WSDL to set the correct type and again later (with the actual bean as parameter) when the bean is serialized.
Mappings are much like introduction in that they may choose the change the type (from a Collection to a simple array) and is also called with the object when serialized.

It works perfectly and is really useful when using existing model objects in a web service.

Using XML as domain (model) objects

Just an idea!

I have seen many system implemented using bean-like domain objects. Then they're transformed to XML for use in a web service or when rendered using XSLT or even during some sort of import/export mechanism....

Why not write your domain model using XML Schema's and generate the actual "bean" classes using XMLBeans or alike (JAXB, Castor)? So you still have your beans classes, its easily transformed to and from XML all you need is have some sort of persistence working underneath the objects.. Im not quite sure Hibernate will do the trick, but a XML database seems like a good choice..

Well - just a spawn of my brain, overheated by too much caffeine...

C#

Last year at the JAOO conference, I attended a session held by Anders Hejlsberg, the maker of the C# language (to my knowledge). I've been programming in the java language for the last 5-6 years or so, and never really did pay much attention to the .NET platform nor the languages from Microsoft (simply because they were from Microsoft :-) ) but I must say the above mentioned session really opened my eyes to the C# language.

Just recently I actually started to program a tad in C#, and I must say - I LIKE IT!

Well there you have it...

IM - File Sharing

Imagine Instant Messaging and File Sharing combined!

Intrigued? I am! - On the way home today, I was thinking about the implementation of the MSN Messenger Protocol I'm currently (not so much) working on, when a thought struck me - why not implement a Bot atop the implementation and let people search my online files or whatever I might be sharing. It should be as simple as

/search "Some filename"

(please note the IRC like commands :-) )

And the result could be a list of links to where ever the files are available for downloads like:

Some file
Some like file

By using some sort of ticket mechanism in each link which is combined with the user (remember we have the user of the trustee list), its even possible to make sure all others cannot download the files, but only people who have searched the file using the IM client, hence only people you TRUST (otherwise they're probably not on your IM friends list anyways, right?).
Well yet another nice idea I'd probably never will find the time to implement!!

DITC - Dependency Injection Thru Context

I recently read Cedric Beust's blog where he stated he's not getting the inversion of control containers. This got me thinking. Everyone (well many anyways) are talking about inversion of control (IoC) and dependency injection, but most implementations Ive seen assumes we want the base object injected directly!

Why not mix the Service Locator pattern and dependency injection by injecting a context to the given bean or object? The context semantics are much like the java:comp/env component in J2EE for an EJB, you can only lookup beans on which you depend.

When injected (preferably thru constructor injection), the bean is free to lookup the specific implementation for any interface, on which the bean depend, using the injected context. This could be as simple as:

public interface BeanContext
{
Object lookup(Class interfaceClass);
Object loookup(Class interfaceClass, Object selector);
}

public MyBean(BeanContext ctx) {
OtherBeanInterface obi = ctx.lookup(OtherBeanInterface.class);
}

By injecting the context, we avoid using a direct service locator paradigm, and by using the context as a service locator, the program should be more debugable. Also, and this is where my "design" pays of, is the possibility to add some sort of event listening scheme to the context, thus allowing the users of a context, to be notified when eg. a configuration-changed-event has occoured. This could spawn a re-lookup of the service in which the local bean depends, getting a brand new instance without destroying the current bean, since it HAS to be injected thru the constructor directly..

Well read this and give it some thoughts.....