The term J2EE is deprecated since 2006. The meaning has never changed: it’s still Java for the enterprise. But, it’s officially rebranded:

“The platform was known as Java 2 Platform, Enterprise Edition or J2EE until the name was changed to Java Platform, Enterprise Edition or Java EE in version 5.”

So it’s J2EE only until 1.4, but Java EE from 1.5 onwards, dropping the “1.” prefix.

The latest version can be found here.

MTOM is short for Message Transmission Optimization Mechanism. The keyword here is: optimization. When you’re slim, your body is considered optimized. How does this happen then?

Fat Data

Remember that SOAP is just XML. When you embed non-text data into it, for instance, an image - it has to be converted into a datatype that an XML processor can understand.

Without MTOM, your image will be converted to an XML-format binary string and placed smack in the middle of your SOAP envelope. This conversion process makes the data fat.

<tns:data>A very looooooong base64Binary string</tns:data>

Here’s a simple illustration:

MTOM to the Rescue!

With MTOM, the image will be transmitted outside the envelope as a MIME attachment. In short, it’s sent according to its original datatype: a jpg, png, or gif. Of course it’s still transmitted as binary data, but this time, there’s no XML-related conversion, avoiding the unnecessary overhead. XOP comes into the picture as it’s the one that gives the location of the externalized image.

<tns:data><xop:include href="SomeUniqueID-ThatLeadsToTheImage"/></tns:data>
Content-id: "SomeUniqueID"
Content-Type: image/png
**image binary data here**
In the end, they each serve their own purpose in the service-oriented world. SOAP is mature but bloated. REST is relatively younger, but is a more natural fit with HTTP. It has huge potential, especially when service contract standards are put into place. When WADL matures, it will boost the popularity and adoption of REST.
I'm currently doing an overhaul of this blog. Content will be restored in a couple of weeks.

Happy Connection

It is so easy to create a new connection every time:
Connection myConnection = myDataSource.getConnection();

Do You Eat on a Plate?

This is what a plate looks like.

Do you throw away your plate after each use?

No, you wash it and put it on the dish rack, so you can use it again on your next meal. Buying new plates every time is out of the question. If you did that, you will have wasted enough money to buy a new iPad in one year.

Plates, Pools and Family

Think about connection pools again.

But this time, the connections are your plates, the connection pool is your dish rack. Your wallet and your energy embody the system resources (memory and bandwidth).
The key is in knowing how many plates (connections) your family (application) will need in any given day.

While extra tasks are involved in setting up connection pooling, it’s less taxing in the long run compared to creating new connections every time.

Pools are useful for database connections, threads, entity beans and factory-derived objects.

Powered by Blogger.