System Architecture and the User Interface
In an article I wrote for The Northrop Grumman Technical Review Journal, entitled Service-oriented Architecture and User Interface Services: the Challenge of Building a User Interfaces in Services, I described five functional categories of user interfaces that a system architect might use to enable a user to employ for an SOA-based Composite Application. These included: Thin Client, Portal, Rich Client, Smart Client, and Rich/Smart Client. I describe the characteristics sub-functions of each such that a system architect be able to determine which would serve the Composite Application's user best.
In the article I linked the user interface categories to three categories of users (not my categories, but I could not track down the source), informational, transactional, and authoring. An informational user is one who uses data and information in an ad hoc (through search and discovery methods) or regularly to retrieve information from one or more sources. The data flow is primarily to the user. Many commercial cable companies set up their networks for this type of user; with data rates twice as fast to the customer of the data and to the supplier of the data. A transactional user is one who repetitiously inserts and/or retrieves the same type of data from an application. For example, the office administrator in a doctor's office makes appointments, that is, he or she looks up on a calendar for dates and times that are open and then inserts an appointment. For organizations, including businesses, the vast majority for the uses of data and user interfaces are of this type. Finally, there is the "authoring" use. This customer function is the most creative and would include: programming, document, video, and audio file creation and editing, engineering, verification and validation, and enumerable other content creation. Creating a user interface for the authoring category is the most complex because this service links to the most complex functions of an application.
There were two reasons for writing this article. First, for SOA-based Composite Applications, to demonstrate that the user interface could be built in Service Components, as there was a good deal of discussion between myself and my colleagues on this point. Second, to demonstrate the patterns that a System Architect can use in the activity of decomposing the customer's system requirements and deriving the functional requirements, which is a key step in the system architecture process.
In an article I wrote for The Northrop Grumman Technical Review Journal, entitled Service-oriented Architecture and User Interface Services: the Challenge of Building a User Interfaces in Services, I described five functional categories of user interfaces that a system architect might use to enable a user to employ for an SOA-based Composite Application. These included: Thin Client, Portal, Rich Client, Smart Client, and Rich/Smart Client. I describe the characteristics sub-functions of each such that a system architect be able to determine which would serve the Composite Application's user best.
In the article I linked the user interface categories to three categories of users (not my categories, but I could not track down the source), informational, transactional, and authoring. An informational user is one who uses data and information in an ad hoc (through search and discovery methods) or regularly to retrieve information from one or more sources. The data flow is primarily to the user. Many commercial cable companies set up their networks for this type of user; with data rates twice as fast to the customer of the data and to the supplier of the data. A transactional user is one who repetitiously inserts and/or retrieves the same type of data from an application. For example, the office administrator in a doctor's office makes appointments, that is, he or she looks up on a calendar for dates and times that are open and then inserts an appointment. For organizations, including businesses, the vast majority for the uses of data and user interfaces are of this type. Finally, there is the "authoring" use. This customer function is the most creative and would include: programming, document, video, and audio file creation and editing, engineering, verification and validation, and enumerable other content creation. Creating a user interface for the authoring category is the most complex because this service links to the most complex functions of an application.
There were two reasons for writing this article. First, for SOA-based Composite Applications, to demonstrate that the user interface could be built in Service Components, as there was a good deal of discussion between myself and my colleagues on this point. Second, to demonstrate the patterns that a System Architect can use in the activity of decomposing the customer's system requirements and deriving the functional requirements, which is a key step in the system architecture process.
An Example
While a functional design for the user interface Service Component may seem like a semi-useful abstraction, Apple seems to have intuitively understood the concepts very well. For those versed in SOA, an Apple "App" is simply a Service Component. It performs a single function or a small group of closely coupled functions (in a system architecture sense), for the user. Apple, and subsequently many other suppliers of wireless user interface devices, are now selling these User Interface Service Components. Most of them are for the informational user, if you can call streaming a movie informational--the functional concept is the same. Likewise stock quotes, news feeds, the weather radar real time image, the restaurants closest to the user (with customer critiques), and earth images of the user's current location (i.e. navigational maps) are all informational, that is, they are likely used on an as needed basis, or semi-regularly, to gain data and information about what is going on in the environment that affects them.
Even Apple's iTunes and Apps store are informational in that they link to discovery and download functions (services) on the server-side of the system. There are Apps, like playing music, games, and currently, the calendar, that are standalone applications (functions), but even the camera function (service) is loosely couple with the e-mail user interface Service Component. Consequently, the system architecture of the new mobile devices is, in fact, SOA-based, they just don't want to call it that.
As further proof, Apple is treating their Apps the manner a Service Component supplier should be treated. Apple has significant verification process to ensure that Apple's policies and standards are met, before the App is offered to customers. That is, Apple is verifying the Apps, the way all Service Component supplier should verify Service Components, especially, a user interface Service Component. These include meeting security and dependability standards, as well as having a Service Component Description. The Apps Store serves as the Service Component registry and discovery function in the SOA-based architecture.
Consequently, this is an excellent example of an SOA-based architecture (though it really doesn't use Web Services).
For more on SOA see SOA in a Rapid Implementation Environment, Enterprise SOA vs Ecosystem SOA, Private Cloud Computing vs Public Cloud Computing, Choreography vs Orchestration: Much Violent Agreement, and SOA Orchestration and Choreography Comparison. For more on System Architecture see SOA in a Rapid Implementation Environment, Enterprise Architecture and System Architecture, and Lean or Agile Enterprises and Architecture.
Even Apple's iTunes and Apps store are informational in that they link to discovery and download functions (services) on the server-side of the system. There are Apps, like playing music, games, and currently, the calendar, that are standalone applications (functions), but even the camera function (service) is loosely couple with the e-mail user interface Service Component. Consequently, the system architecture of the new mobile devices is, in fact, SOA-based, they just don't want to call it that.
As further proof, Apple is treating their Apps the manner a Service Component supplier should be treated. Apple has significant verification process to ensure that Apple's policies and standards are met, before the App is offered to customers. That is, Apple is verifying the Apps, the way all Service Component supplier should verify Service Components, especially, a user interface Service Component. These include meeting security and dependability standards, as well as having a Service Component Description. The Apps Store serves as the Service Component registry and discovery function in the SOA-based architecture.
Consequently, this is an excellent example of an SOA-based architecture (though it really doesn't use Web Services).
For more on SOA see SOA in a Rapid Implementation Environment, Enterprise SOA vs Ecosystem SOA, Private Cloud Computing vs Public Cloud Computing, Choreography vs Orchestration: Much Violent Agreement, and SOA Orchestration and Choreography Comparison. For more on System Architecture see SOA in a Rapid Implementation Environment, Enterprise Architecture and System Architecture, and Lean or Agile Enterprises and Architecture.
No comments:
Post a Comment