Site Sponsors:
BEST - Web Services for the Rest of Us? 
In the world of computer technology - as everywhere else - there is Knowledge, and then there is Wisdom.

Of course, Knowledge is simply knowing something...

Wisdom ... where & when to use it?

Problem Domain


While SOAP & REST -based web services are great for folks with racks of servers & software developers, a very real need exists for those businesses who presently - having neither - yet wish to create programmable interfaces to those legacy, web-based, HTTP Services. (For the purposes of this white paper, we are considering anything from a simple page request (HTTP GET) to a web-hosted, fill-out-form (usually HTTP POST,) to be a legacy, or classically defined, web-service.)

Indeed, as the demand for mobilized application support increases, the need to quickly host cost-effective, legacy-integrated Web Services, is becoming far, far more important every day.

Next, even after one can programatically re-use their Internet legacies from a rapidly-developed & previously-deployed Web Service, the NEXT most important task is - since most are ever aspiring to become the next "big company" - to be confident that one can GROW such services into a set of enterprise-class, ESB capable, secured transactions.

The present, often excruciating need to (1) rapidly & affordably create Web Services into our present, Business HTTP Services, as well as to (2) grow them into Enterprise worthy solutions, is why we have taken the time to define B.E.S.T.

BEST Overview


Business / Enterprise State Transfer (BEST) is a set of architectural guidelines. Conceptually drawing heavily upon successful Internet data interchange patterns & practices, the main focus of BEST is to both embrace and extend classic client / server requests and responses.

Rather than abandoning decades of successful data processing activities, the canonical BEST Reference Model (BEST-RM) seeks to encapsulate & extend traditional Internet client / server operations so as to support modern, version controlled, Web Services.

BEST-RU


Central to the core of a BEST architectural approach is the concept of the Request / Response Unit. Traditionally referred to as an RU, most of the BEST-RM demonstratively builds upon decades-old networking concepts.

When viewed as a self-contained data-interchange pattern, the goal of defining the BEST RU as a stateless, session-less, transactional architecture unit embraces the main design principles of both SOA/SOAP and SOA/REST.

Indeed, while a BEST-RU need not be stateless, widespread recognition of the scalability, maintainability, and robust nature of transactional processing systems are well documented.

Security


Another very real benefit of evolving state-bound requests & responses into far more stateless choreographies might be to apply a higher degree of design rigour. Indeed, once we acknowledge that designing-in support for stateless data representations can indeed provide all-in-one cyphers to would be system attackers, the practice of defining multiple RU's to provide data to any single business operation should be considered a security best-practice. -In many ways, providing support for multiple, varying RU encodings is merely a simple extension of proper RU / Service Version Control.

RU Service Concepts


The next best practice suggestion is - when not otherwise implied by a service legacy – that any and all operational requests simply be relocated into the body of the RU.

Indeed, while CREATE, READ, UPDATE, and DELETE (CRUD) operational requests are well documented, requests for SEARCH, SERVICE STATUS, SERVICE EXCEPTION, ROLLBACK / COMMIT, LOGON / LOGOFF, and SERVICE AUTHORIZE / DEAUTHORIZE actions have also been considered traditional design requirements. Hence, when defining the content of any RU, the exclusive, unary, operational nature of each anticipated service-request demands that each sibling operation be defined in the exact same place. (i.e. Avoiding present or future operation-state confusion and / or collisions is also an important part of a rational RU Maintenance Policy.)

BEST-RM


When viewed as a set of self-contained, stateless, version-controlled datagrams, the definition of the canonical BEST-RU easily embraces the classical Internet data exchange model. BEST does not require legacy servers to implement hitherto unnecessary HTTP Operations (such as PUT and DELETE.)

Implicit Version Control


Indeed, once the ostensible, legacy, service-oriented operational intent of a classic GET / POST request is understood to be merely a "1.0 Service Contract", then very little imagination is required to appreciate how every existing HTTP Request can be considered to be a BEST-RU.

Thereafter, and again when not otherwise implied by a much wider service legacy, we must merely note that any future operational requests must also be encoded into the body of the RU. Thereafter, just as when evolving any other service definition forward, a unique RU and / or Service Version identifier should be provided.

Protocol Neutrality


Another practical effect of moving operational requests into the next version of an RU not only allows for the continued operation of classic GET / POST client / server operations (hidden form fields, etc.), but also supports many other RU delivery techniques, as well. -Either one, or a series of BEST-RUs can be stored & forwarded in everything from disk-files & USB devices, to regression-testing tools & frameworks.

Clearly, in as much as legacy HTTP/S Forms & Services can continue to be supported by BEST-RM Web Service (BEST-WS), even real-time, production-level diagnostics can continue to take place using traditional, browser-based interfaces. No special web-service testing tools will be required.

Finally, we might note that adopting a self contained, BEST-Oriented, transactional mindset not only extends our service operations far outside of the HTTP protocol, but also prepares an RU for operation across such modern processing platforms as the Enterprise Service Bus (ESB.)

Conclusion


Ultimately, when adopting a BEST Approach, the mature, natural, and rational requirement to embrace existing, as well as future, RU-submission techniques encourages a more evolutionarily, incremental, enterprise-worthy, & economical adoption of Modern Web Services.

Elevator Pitch?


At some point in time, we need to relate the technical advantages of BEST in such a was so that even a PHD laureate might understand them?

In the mean time, from a completely business vantage-point, simply understand that, unlike REST, rather than:

(1) Updating / discarding traditional HTTP Servers

(2) Hiring an army of software developers to support hitherto unnecessary HTTP Operations

(3) Breaking legacy browser-based services

(4) Alienating popular server-side technologies (such as PHP)

(5) Re-writing legacy server-side Service Providers

(6) Introducing latencies as a service request is re-encoded

(7) Translating HTTP requests to make sense elsewhere

(8) Relying EXCLUSIVELY upon any single protocol (HTTP/S)

(9) Multiplying the number of RUs flowing throughout the enterprise for any single request

-The BEST-RM simply:

(1) Moves operational service-requests into the RU when not otherwise implied

(2) Assumes an un-versioned request is for the legacy service

(3) Allows any BEST-RUs to be submitted to any BEST Application-Service (classic transaction processing is an ESB Pattern.)

(4) Assumes the existence of Input, Output, and Error Reporting Processing for each and every BEST-RU

(5) Improves transactional monitoring, accountability, & traceability (1 end-to-end RU for the entire service operation)

(6) Can both encapsulate & deliver Classic HTTP/HTML, SOA/SOAP, SOA/REST and / or any other type of service requests.

Everything else should be able to be appreciated by anyone who understands the way the Internet has operated for the last 20-odd years.

Postscript


It is hoped that the above discussion is enough to support your attempts to more economically & rationally embrace, encapsulate, & extend your present service legacies.

Please note that I plan to add more diagrams, discussions, and BEST-RM walk-thrus as time permits.

In the mean time, the reader might wish to refer to the original post.


[ add comment ] ( 3428 views )   |  permalink  |  related link
New: ClassIO Code Generation Applet 
We recently decided to post applet versions of some of our projects on the main site.

In addition to our "Reasonable Rate Calculator", "Time Machine", and "JVM Speed Test", today we added ClassIO to the list.

Cheers,

-Rn


[ add comment ] ( 1477 views )   |  permalink  |  related link
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", "foo@bar.net"),
new TagValue("title", "geek of the week"),
};
request.setParam(array);

// 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. :)

Versions


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...

Security?


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 (service.post(request, 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:

https://sourceforge.net/projects/easyhttp/

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 Java.net 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";
exit();
}
}
$action = $_GET['op'];
if ($action) {
if (strcmp($action, 'test') == 0) {
echo "Success: $action - PHP GET RECEIVED.\r\n";
exit();
}
}
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/Test.java.

https://sourceforge.net/projects/easyhttp/

B.E.S.T!


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 :-)


Enjoy,

-Rn

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



[ add comment ] ( 3842 views )   |  permalink  |  related link

<<First <Back | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | Next> Last>>