Site Sponsors:
EasyHTTP - A simple design for Java GET / POST 
With all of the hoopla over Web Services, you would think that servicing user requests over HTTP was something new.

Well, we all have lots of experience with REST, JSON, XML, SOAP, WSDL, HTTPS, and even EDI ... but at the end of the day, it all comes down to legacies, security, and performance?

Classic Web Support

The ideals behind SOA, SOAP, & REST are crystal clear. Just as clearly, a real & current need also remains to leverage the traditional ways of providing services to our Internet Users. --Wouldn't it be great if our web services could re-use our existing web-based forms, urls, and interfaces?

Well, with EasyHTTP, they can!

Because legacies are important, EasyHTTP allows our "Web 2.0" Web Services to continue to inter-operate with our "Web 1.0" HTML Forms & Services.

Indeed, using EasyHTTP, support for classic HTTP GET / POST Forms & URLs can be integrated into your Web Service Project in an average of 3 lines of plain-old (no annotations required!) Java Code:

TextResponse response = new TextResponse();
HttpService service = new HttpService(new URL("http://localhost/test.html"), true);
if (service.get(response) == true) {

Add two more lines of code, and even creating a web service to automate the completion of an HTML fill-out form is easy:

// TEST: Rich, multi-param, POST
PostRequest request = new PostRequest();
TagValue[] array = {
new TagValue("firstname", "randall"),
new TagValue("lastname", "nagy"),
new TagValue("phone", "123-456-789"),
new TagValue("email", ""),
new TagValue("title", "geek of the week"),

// Works the same as for GET
TextResponse response = new TextResponse();
HttpService service = new HttpService(new URL("http://localhost/test.php"), false);
if (service.get(response) == true) {

(Yup: EasyHTTP makes it that simple to create a Web Service call to fill-out & pass data to your classic HTTP Forms!)

Why should we care about their legacies? Because supporting your legacies means that any existing PHP, ASP, JSP .. and even our browser-based JavaScript operations - will not have to change! (i.e. EasyHTTP could save companies who are now fixing decade-old services - HTML Forms that were never broken in the first place - millions of dollars. :)


I recently read a discussion about how using classic GET and POST parameter passing make service interfaces fragile. Yet, can we ASSUME that a 'no version identifier' is requesting our 1.0 Service? If so, then by thereafter including an official service-version field, all is fine once again.

Moreover, once we acknowledge that HTTP respects the 50-year-old need for designing in both a stdout, as well as a stderr response, most of us cannot see what in the HTTPS is wrong with continuing to use classic data-exchanging techniques. -Even arguments over using the more lean array encoding in JSON -v- XML seem moot: The classic use of & and = are as terse as it gets? -Certainly everything outside of what HTML 5 Forms can support is an exercise best described by the Pareto Principle?

Once again, if it ain't broke, why spend industry-billions trying to fix it? --Book sales??

(In other words, perhaps we all should first try to understand how things work BEFORE we try to re-invent things as small... uh ... as the Internet? (i.e. Every first-year web designer knows that HTTP Forms can have hidden fields. Why not a hidden service-version identifier, as well?))

Real World Results

Indeed, when used as a forms-injector, I was able to forms-inject over 180,000 recipes into a web-hosted, HTML Wiki tool. -The results can be seen at the Wiki Recipe Club.

But legacies are not everything. Oh sure, it is great to be 'easy to use', but what WE find easy to use, others will find just as easy to hack...


Therefore, once our service version(s) are under control, the next simple idea here is to allow us to focus more upon the transactional plumbing, than the data-exchange protocol. (i.e. While HTTP is great, modern enterprises are about a lot more than HTTP!)

Hence EXTENDING a legacy to be able to SWAP TRANSACTIONS with a "blind" HTTP Endpoint / Service is far more clandestine:

// TEST: Complex POST (ping -w- redundant GET parameters)
PostRequestTest request = new PostRequestTest();
if (, response) == false) {
if (response.isComplete() == false) {
if (response.isNull() == true) {
String[] lines = response.getResponse();

Operationally encoded, data-driven, and / or custom-encrypted (rather than clearly protocol-dependant & far too demonstrative,) transactions. (All one needs to break a cypher, after all, are enough common keywords to look for? -Put enough of those tokens in the exact same location each time, and one might as well not encrypt anything at-all?)

The Project

So without further ado about how to 'properly' encoded data, operations, and 'service contracts', here is a fast, easy way to exchange data with any HTTP Server:

Unlike Apache's wonderful HTTPCore, EasyHTTP consists of a mere handful of classes. A minimalist feature-set that will allow us to secure either our data, or our server-side operations, in any way WE feel the need to do-so.

Finally, because EasyHTTP uses far fewer classes to manage the exact same base classes used by other techniques, it doesn't get any faster than this, folks... even our installation, download, & compilation times will improve.

Easy Features

In addition to being a light, properly-encoded way to encapsulate those troublesome URL / HTTP Connections, EasyHTTP also includes a simple PHP test case:

$action = $_POST['op'];
if ($action) {
if (strcmp($action, 'test') == 0) {
echo "Success: $action - PHP POST RECEIVED.\r\n";
$action = $_GET['op'];
if ($action) {
if (strcmp($action, 'test') == 0) {
echo "Success: $action - PHP GET RECEIVED.\r\n";
echo "Test Protocol Error: PHP GET/POST 'op=test' not detected.\r\n";

So to start enjoying a significant size-decrease for your "web service" legacies, AND your leaner & meaner obfuscated HTTP Server-support Projects, simply download EasyHTTP from Sourceforge, copy test.php to the root of your localhost, then run php/


Looking back, the ideas to (1) Embrace the architectural principles of RESTfull Services, yet to (2) add version numbers to support, rather than to simply abandon our legacy web services, then to (3) encode our CRUD as PART of our operations so ANY PROTOCOL (not just HTTP/S) can pump transactions throughout our enterprise (a Security / SOAP 'thang) inspires me to create a catchy acronym to sum up such a simple, evolutionary, concept.

How about the "Business / Enterprise State Transfer"?

-You can call it BEST :-)



p.s. - The EasyHTTP jar file also includes the source code.

[ view entry ] ( 3880 views )   |  permalink  |  related link
PHP EzLog? 
I am teaching a class on Advanced PHP today. Was surprised at how much we all enjoyed a simple logging demonstration:

* Just ezlog a message to a file.
* @author profnagy
class logfile {

var $defaultFile = 'default.log';

public function open($file) {
$rev = strrev($file);
if (strpos($rev, 'gol.') != 0)
$this->defaultFile = $file . '.log';
$this->defaultFile = $file;
$br = file_exists($this->defaultFile);
return $br;

public function write($message) {
$now = date('Y-m-d H:i:s', time());
$line = "$now\t$message\n";
$result = file_put_contents($this->defaultFile, $line, FILE_APPEND | LOCK_EX);
if ($result === false)
return false;
return true;

public function remove() {
return unlink($this->defaultFile);


The example succinctly demonstrates using PHP dates, time, file I/O, locking, strings... and a little bit more. (i.e If you ever went looking for a Java-Style "endsWith()" in PHP, then consider the fast & easy use of strrev() in the above. Can be logically the same as a "startsWith" in the C/C++/PHP/Standard Lib/PHP Core.)

So if you are just getting into the more advanced features of PHP (or, if you enjoy seeing the spirit of the Standard C Library in use!), then you might enjoy playing with the above PHP Class.

By way of a bonus, it looks and smells a lot like the RFC Log Date & Time format I used for my Open Source / Skype's C/C++ (.ezlog) Legacy.

Time-tested & ready for production.



[ view entry ] ( 9402 views )   |  permalink  |  related link
UML & Hadoop 

What the "H"?

I first bumped into Hadoop in 2010.

While Consulting at the Electronic Proving Ground (EPG) as the Technical Sections Leader, our section was exploring ways to digest the the terabytes of data captured from a typical battlefield. Simulation.

While our flagship product (RICS) had no problem faithfully logging everything from sessions & phone calls to pictures, the SQL Database-bound post-processing could take days. -Far too much time when troops were wanting in the wings to see the KML. Something had to be done to speed things up.

Big Data?

Well, after driving my truck around Fort Huachuca, harvesting the KML for the Google Map proved to be the easy part. -What was daunting at the time was that "T" in terrabye... -Almost as taunting as the "P" in petabyte sounds today! (Got hardware? --Then Hadoop can tackle both 'P' & 'T' ...)


This story had a happy ending... But I would have to shoot BOTH of us if I told anyone why ;-)

Recollecting the challenge I had to host a Hadoop VM ... let alone 50 ... on the racks, I was happy when a colleague of mine asked me to train a his 2013 students on Hadoop. Why? Because - while named for a toy elephant, many believe that wresting a "do-oop" pun out of the mascot's name would make for an extremely accurate pun. HadOOP.



Resolving to make our training for Hadoop a lot more OOP-ey, today I cracked out our favourite editor for a little UML Action. --I wanted to share the ease of the chore, as well as some of the results, with you.

After a few hours tinkering, it seems that we could get NetBeans to generate diagrams, but the UML Feature is decidedly no longer ready for prime time. We decided to use Eclipse, instead.

Today we also downloaded & played with JDeveloper’s UML feature set. A recommended experience!



[ view entry ] ( 1657 views )   |  permalink  |  related link

<<First <Back | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | Next> Last>>