Palmalex

Last Minute

When you are going to implement a project, any kind of project, you have to do an estimation of the time that you need to finish it.

No matters how you are accurate, even if you overestimate the total time, there will be always the last minute.

I meet the “last minute” in almost all the projects that I managed for my Job: Information Technology Project.

Usually you are in the last minute when you are very close to the deadline of the project (the day before… it’s enough close, but can be closer) and something goes wrong:

• A Bug in the software that you are going to delivery
• A Bug in an infrastructure  component that you are using …
• A misunderstanding of the requirements.
• …

This is the evidence of one, and  perhaps the most famous Murphy’s Law:

Anything that can go wrong will go wrong.

This kind of situation happened, and you cannot do anything to avoid them, it’s very difficult maintain the calm: you can feel the scary of the failure on your neck.

If you are working within a team, this is the moment where you can measure the team cohesion, these situation are usually solved by a single member of the team… but not alone. The success of a project  depends on the team and its cohesion… to archive  a success you have to work hard to build the “Dream Team”.

Mule Workaround

Unfortunately the WM integration server that I used doesn’t support the HTTP 1.1 specs, in particular the Transfer-Encoding: Chunked directive.

For the CXF outbound endpoint, it’s natural use this way to build the HTTP request as the message it’s a stream,
to obtain better performances especially with big payload. 

I tried to set up the CXF connector to doesn’t use this feature without lucky… very bad for an ESB, its main target is integrate.. also/especially for legacy systems.

After some session using tcpmon to sniff the request and a post on the community forum without any reply, I found a workaround… it’s not elegant but it works.

I added an additional bridge between the CXF outbound and the integration server.

Just to understand the problem, in my case the message arrived from a JMS queue, I transformed this message using XSLT then sent it to the WS. see the following Mule configuration fragment (I snipped the transformers) :

<service name="resumeWm">
			<inbound>
				<jms:inbound-endpoint name="job_in" queue="jobs_toResume_dev" synchronous="false">
					<transformers>
					</transformers>
					<response-transformers>
                                        </response-transformers>
				</jms:inbound-endpoint>
			</inbound>
			<echo-component></echo-component>
			<outbound>
				<pass-through-router>
					  <cxf:outbound-endpoint 
						applyTransformersToProtocol="false" 
						address="http://url" 
						proxy="true"   
						synchronous="true"
						>
					</cxf:outbound-endpoint>
				</pass-through-router>
			</outbound>
		</service>

I this way I wasn’t able to configure Mule and CXF to use only the HTTP1.0 specs… I tried to add a custom cxf.xml… but it seems to be ignored.

As ultima ratio I tried a workaround, I added a protocol bridge,hence instead of invoke directly the WS, I sent the messages on a VM queue using CXF, than I grab the message from the queue and using an http outbound endpoint I forwarded the message to the Integration service… using a simple http connector force HTTP1.0 it’s very easy. following the modified version :

<service name="resumeWm">
			<inbound>
				<jms:inbound-endpoint name="job_in" queue="jobs_toResume_dev" synchronous="false">
					<transformers>
					</transformers>
					<response-transformers>
                                        </response-transformers>
				</jms:inbound-endpoint>
			</inbound>
			<echo-component></echo-component>
			<outbound>
				<pass-through-router>
					  <cxf:outbound-endpoint 
						applyTransformersToProtocol="false" 
						address="vm://wmworkaround" 
						proxy="true"   
						synchronous="true"
						protocolConnector="vmConnector"
						>
					</cxf:outbound-endpoint>
				</pass-through-router>
			</outbound>
		</service>
 
		<service name="httpBridge">
		<inbound>
			<vm:inbound-endpoint address="vm://wmworkaround" connector-ref="vmConnector" synchronous="true"/>
		</inbound>
		<echo-component>
			<logging-interceptor/>
		</echo-component>
		<outbound>
			<pass-through-router>
			<http:outbound-endpoint address="http://url" synchronous="false">
				<mule-xml:xml-to-dom-transformer/>
				<property key="http.version" value="HTTP/1.0"/>
			</http:outbound-endpoint>
			</pass-through-router>
		</outbound>
		</service>

I verified this solution with TCPMON, and the request is HTTP1.0 compliant.

J2EE heart line

Some days ago, when I was reading some posts on google reader, I started to  read a shared one from a friend of mine about a lightweight application server that RedHat is going to release.
Good, I knew that RH was going to release a their package that slim the JBOSS distribution and left only a the embedded tomcat called jboss web, I thought that the post was only a way to launch the product… I was wrong.

Yesterday I noticed always in Greader the Rod Johnson’s post from Springsource.org Red Hat Reacts to SpringSource’s Leadership ,  I pointed my browser directly on the post, and I understood what is the new Red Hat product: The new application server is spring based, it seems to be a competitors for the spring dm and tc application server.

Reading the announcement seems that the failure of the J2EE stack for the enterprise applications is archived also in RH. Today few application actually needs an full J2EE stack, usually they needs only a servlet engine and some services as a JMS broker or/and an XA transaction manager. The functionalities that J2EE provides have been ignored since the first releases of the standard by the developers, and the reasons of that are the causes of the success of the spring framework : J2ee is too complex.

Writing an application using the pattern of a J2ee stack require a deep knowledge  of the application server where the application will be deployed, and the deployment phase can be a nightmare, you have to fight with the class loader of the AS and with AS dependent descriptor files. if you are working in an environment  where the separation of duties between developer and sysadmin is needed… a simple deployment could be a big mess. 

The introduction of new paradigms as Service Oriented Architecture or Cloud Computing and technology as ESB and SCA, is the Coup de grâce for the J2EE. No matters where a service is deployed or how is implemented, you are free to choose, hence why don’t use a simple and real portable implementation: POJO.

Springsource makes the simplification of the J2ee stack its manifest, RH is going to follow the same path… the choice of IBM and Oracle are not yet defined… what will be ? 

J2ee is (was) a standard defined throws steps shared with the developer community, the JCP influenced a lot the specification of J2EE; although it’s not an ISO or ECMA it’s standard de-facto, this assured a sort of portability between application server. 

To add noise, Oracle bought SUN: now it’s the owner of the standard…  

This can be the changing-game moment for Springsource, it can play the role of the independent third party and lead the transaction from J2ee to… whatever. 

Oracle said about spring :

One such open source technology is the Spring Framework, a leading application framework that enables developers to quickly and easily create high quality applications for deployment into high-end application servers.

On the other side a simple search on developerworks it’s enough to understand that also IBM is not insensible to the Spring Framework appeal.

What will be in the enterprise application ? we will see. I hope that the new standard will be lead by the innovation not by the stock market. SpringSource is a good candidate.