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.


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.


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


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


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.


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.

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

<<First <Back | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | Next> Last>>