Client/SOA

From Wikipedia, the free encyclopedia

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.^{[neutrality disputed]} In contrast to "thick client" and "thin client", Client/SOA has been called "athletic client"^{[citation needed]}.

This architecture is considered by some^{[citation needed]} 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++^{[citation needed]}, 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^{[citation needed]}. 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^{[citation needed]}. 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.^{[citation needed]}

In summary, Ajax/HTML++ applications:

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

In contrast, Client/SOA applications:

1. Manage session state primarily (if not entirely) in the client.
2. Generate the majority (if not the entirety) of the UI in the client.
3. Rarely if ever reload the page as a result of #1 and #2.
4. Communicate primarily using XML or JSON-based web service APIs.
5. 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^{[citation needed]}, as a way of describing the difference between Ajax-enhanced web sites and fully-realized enterprise applications whose deployment platform is a web browser.

[edit] References