I am telling you...

I am telling you - the java.beans package is so under-estimated by most developers, that they ought to be ashamed...

Axis Custom BeanSerializer

I've noticed many of this blogs visitors have searched google for axis bean serializer. I've had a chat with my boss regarding open-sourcing our custom axis bean serializer (see previous post), but this is yet to be determined. Anyways - I was thinking about implementing a much more generic one, but I want to know whether people are acutally interessed in such a serializer or if you guys are more interessed in knowing how the current implementation works (users guide)? Any thoughts?

Tapestry update

Well - as previously mentioned I've startet developing a web application using Tapestry as framework. Tapestry has a clear seperation of concerns which is why I chose to look at it in the first place.

Many JSP developers think that implementing and using custom tags is a clear seperation of concern from layout and logic but I party disagree.
Whether you use a

<c:foreach...>

or a

<% for(Iterator i in coll.iterator;i.hasNext();) %>

is practically the same. You still have logic (looping) in your layout, but using the foreach tag is ofcoz to be preferred (the lesser evil).

Tapestry on the other hand does things alot different which is a step in the right direction in my opinion.
Let me show you an example using the above looping first in JSP, then the tapestry way:

<table border="0">
<c:forEach var="item" items="${myBean.items}">
  <tr>
    <td> <c:out value="${item.returnString}"/> <td>
  <tr>
</c:forEach>
</table>

Extremely simple JSP fragment iteration thru a collection of a context bound bean named "myBean". Each entry in the collection is bound in page-context by name "item" and referenced in the c:out part, where the method "returnString" is called on each item. Nothing fancy, just plain and simple...

<table border="0">
  <tr jwcid="foreach">
    <td> <span jwcid="string">Some text 1</span>   <td>
  <tr>
  <tr jwcid="$remove$">
    <td> <span jwcid="string">Some text 2</span>  <td>
  <tr>
</table>

The above is pretty much the same as the JSP example except its possible to edit this in a normal HTML editor and there is NO logic what-so-ever in the presentation layer. No saying which property of which bean we're looping thru and which property for each item should be presented in the TD section... All this is done in either the page or component specification (of tapestry).

<component id="foreach" type="Foreach">
  <binding name="source" expression="myBean.collection"/>
  <binding name="value" expression="value"/>
</component>
    
<component id="string" type="Insert">
  <binding name="value" expression="value.returnString"/>
</component>

Well - You'd probably have to have some knowledge of Tapestry to get the full picture here, but basically its saying:

Theres a component called "foreach" (jwcid="foreach" in HTML) which is "substituted" by a real Foreach component, which will loop thru myBean.collection and each item is bound to a property called value.
Then there's a component called "string" (jwcid="string" in HTML) which is "substituted" by a real Insert component (much like c:out) which will take the value from value.returnString and insert into HTML output.

Damn simple and powerful..

Well - to finish this off I'll say that the above examples are made just-out-of-my-head and might not "compile", but should give a decent picture of the game. As for the jwcid="$remove$" part, look itup in the tapestry users manual.. You'll see why that is smart... :-)

VW Golf II Vintage

Once again my somewhat vintage VW Golf II '90 has played me a trick. When I say vintage I actually mean old piece of crap thats just cost me enough money so I dont want to sell it... Remember theres a 180% TAX on cars in Denmark!! Yup - you read it right.. 180%..

Well - anyways, I was in a traffic-jam, when the idle just felt ahemm different.. Well - I thought it might be the over-heating fan that just kicking in, but when I started to drive I knew just what had happened.. :-( My exhaust-pipe broke just before the muffler leaving me with a LOUD noisy car... Theres a reason for people calling my Golf for a "tractor" :-)

Well - just another one of THOSE days I guess.. I digress..

Tapestry

Today I installed Tapestry for the very first time.
I've used Struts for a couple of projects but never really did like struts for anything other than a simple action-oriented application. I know you're able to emulate some sort of portal behaviour using Tiles and letting other action be included in the tiles-def, but still - its not what I want.

Tapestry on the other hand seems totally different from the normal request/response kinda frameworks alltogether and I can't wait to get more acquainted with it..

Will post a follow-up once I get the hang of it.. till then!

SOA for the scorched

I tend to read a different set of blogs spanning from very close technology minded to more philosophical minded. Loosely Coupled Corner by Raghu Kodali is one of them and this blog has recently been about SOA. SOA is an abbreviation of "Service Oriented Architecture" but quite quickly renamed to "Same Old Architecture". If this infact was true, why has SOA come to life yet again then? And is SOA really "Same Old Architecture"?

Well - as Einstein so elegantly put it "every thing is relative" - and so is this. Relative to a systems architect which has been designing systems in many years using a internal SOA like design where a single system may be broken into "services", and relative to, lets say, a whole department which has a couple of systems they've "weaved" together to function as a unit, but is this really SOA?

I don't think so.. I think the reason why some renamed SOA to "Same Old Architecture", was because they didn't really understand why SOA emerged. True, from a technology only view, there wasn't much newsworthy to tell about, but going from a homogeneous architecture to a heterogeneous is something worth telling about. Imagine a system made out of different components (services), located at different locations on earth and weawed together to form this system (and each component may be used in alot of other systems aswell). So - why did SOA emerge? I think most companies have realized its both costly to build and maintain systems. So if they're able to buy a "service" from a third-party and include this into their own systems at a low cost, why shouldn't they!

I'm telling you - this is the way things are moving right now... :-)

The lego way

I remember several years ago, my boss at the time, wanted to launch a marketplace for java components. None of us really felt like that was a great idea, because there were already many sites selling components and we were uncertain as to what a component really was.

Just today, I read a blog about SOA and this got me thinking.. Perhaps the world has shiftet from components to services and what we really ought to be doing was to sell services, like an application service provider (ASP). I think there's a market....

Model Objects Properties

Well - as a kind of a follow up on my post regarding using XML as model objects, I just thought - why not make all property access methods (get/set) package scoped??AND only allow acces to a certain object thru an access-object. I know many will think, well this breaks the "encapsulation" principle of the OO idea, but I beg to differ as there are many cases where this is exactly what you want, to instead end up putting logic into the get/set methods, which IMO is a bad idea.
Well - lets spill it, here are my thoughts in pseudo-code:

interface MyModelObject {
String getSomeString();
void setSomeString(String str);
}

Plain interface.. nothing new here

class MyModelObjectImpl {
private String someString;
public String getSomeString() { return someString; }
/* package */ void setSomeString(String str) { this.someString = str; }
}

Actual model object (container), please note it DOES NOT implement the MyModelObject interface as Im changing scope on the setSomeString method to be more restrictive.

class MyModelObjectNullAccess implements MyModelObject {
.. just delegates straigt-thru to the actual MyModelObjectImpl wrapped ..
}

A simple NULL type access object which only delegates straight thru to the wrapped MyModelObjectImpl. This DOES implemente the MyModelObject is it should..

class MyModelObjectValidationAccess implements MyModelObject {
.. May use some sort of validation only allowing string staring with "Homer" to be
set as someString ..
}

Again - a simple access class which DOES implement the MyModelObject interface, but rather this implementation may validate the string given to the setSomeString method and may even be connected to the struts validation framework - adding a ValidationError to the form's list of error, thus you have a server-side validation framework directly on-top of your model-objects, so even though another "user" (class) might try to set an invalid value, you'd still get an exception or whatever..
So, from the point of the users, the access class IS the model-object, but you're able to switch behaviour based upon need.. Meta-Object Protocol (MOP) like.


Well, till next time..