Client/SOA

Encyclopedia : C : CL : CLI : Client/SOA

Client/SOA is a variation on the term Client/Server specifically describing a computing architecture in which the client component is a web browser and the server implements web-services accessible functionality, i.e. represents the server side of a Service-oriented architecture or SOA. Client/SOA is a true client/server architecture with specific component and API implications centered on web services-based applications.

By leveraging the best features of both client/server and SOA, a true Client/SOA application offers a powerful combination of centralized deployment, maintenance, and security along with high user interactivity, scalability, and fault tolerance. In contrast to "thick client" and "thin client", Client/SOA has been called "athletic client".

This architecture is considered by some to be the natural endpoint of evolution of the web from a primarily server-centric architecture, which includes what some have termed AJAX or HTML++, to one in which the browser is an autonomous component which can access and aggregate data from one or more user-selected web services, i.e. an architecture fully realized in a true client-side portaling application.

To be Client/SOA an application or framework must be server-agnostic, relying purely on web-service APIs rather than specific languages or implementation details of the server. In particular, a technology is not Client/SOA if it requires a specific server process or product to be installed. True Client/SOA technologies must be able to manage session state at the client until a transactionally-consistent web service call can be made. While Client/SOA applications must not require session management from the server, they may use it to enhance performance in certain large-data-set use cases. Finally, Client/SOA technologies must support local data caching and offline operation allowing them to run with or without an active server connection.

In summary, AJAX/HTML++ applications:

Manage session state primarily (if not entirely) on the server.
Generate the majority (if not the entirety) of the UI on the server.
Refresh the user's page quite often as a result of #1 and #2.
Communicate primarily using HTML-based CGI or Servlet invocations.
May degrade gracefully to non-supporting browsers or those with JavaScript turned off.

In contrast, Client/SOA applications:

Manage session state primarily (if not entirely) in the client.
Generate the majority (if not the entirety) of the UI in the client.
Rarely if ever reload the page as a result of #1 and #2.
Communicate primarily using XML or JSON-based web service APIs.
Require a JavaScript/XML Virtual Machine -- aka a modern browser.

One way of thinking about Client/SOA is to imagine that the web service calls provided by the server are simply "stored procedures" being invoked by the client, hence the naming and functional parallels with a traditional Client/Server design model.

Client/SOA was originally defined by Scott Shattuck, a software architect for Technical Pursuit Inc., maker of the TIBET Client/SOA Framework, as a way of describing the difference between AJAX-enhanced web sites and fully-realized enterprise applications whose deployment platform is a web browser.

Which toolkits fall into which category?

Client/SOA

[TIBET(tm)]

[TIBCO General Interface] Framework and Builder

[JackBe] Enterprise AJAX and Business Solutions

[Mendix]

[Backbase]

[Nexaweb]

AJAX/HTML++

[Flex]

[OpenLaszlo]

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.