Working Notes on Protocol Centric Compositional Architecture: Section 2 - Protocol Translating User Agents and Models by

1. Working Notes on Protocol Centric Compositional Architecture: Section 2 - Protocol Translating User Agents and Models by Robert J. DuWors with consideration of AJAX designs produced by PTC Corporation as works for hire for the Boeing Corporation. 04 / 26 / 2005

2. Innovating the next Dominant Design for Large Scale Distributed Systems Section 1: Compositional Architecture Need: Architectural understanding of what we really do in practice everyday on the Web and to jump start better architectures for more effective solutions. Solution: Compositional Architecture is the first architectural framework as flexible as the Web itself and offers a powerful framework going forward. Section 2: Protocol Translating User Agents and Models Need: Provision of well structured customized functionality and unique User Experience for specialized User Community markets at competitive cost. Solution: Application Level Protocols (ASLP) link Service Oriented Models (SO-M) that extend core product functionality flexibly and inexpensively, to Protocol Translating User Agents (PTUA) that tailor User Experience on the fly. Section 3: Distributed Capability Architecture Need: Trustworthy security from top to bottom of all architectural levels without too much or too little securing of highly scalable, dynamic, distributed systems. Solution: Permission Rule Based Capability model for coarse through fine grained control, and for scalable, adaptable “just right” security controls from top-to-bottom and end-to-end: a big step beyond the currently dominant but troubled Access Control List (ACL) model.

3. Application Protocol Centric Models and Protocol Translating User Agents: Well Structured Extension of Product Functionality and Adaptation of User Experience • Opportunity: • Gain far reaching competitive advantage in product line architecture by providing dedicated application • components connecting on-demand to modularized User Interfaces that can be created quickly using • standardized technologies at low cost by in-field solution architects, VARs, and developerson behalf of • multiple user communities. Build better, cheaper, faster, and with much more flexibility! • Challenges: • The technology pendulum swings as pendulums do: • glass Teletypes and 3270s to UNIX Workstation and PC Windowing System, back to X-Windows, • forward to Web Browsers, back to Server Pages, forward to AJAX architecture • But there has never been clear and concise guidelines as to what belongs in User Interface, what belongs • in the application, where and when it should all happen: • the technology progresses but architecture seems to bounce randomly: where are the architectural • guidelines to determine division of responsibility and placement of functionality which are the heart • of distributed system architecture? Is there a natural architectural equilibrium? • The current industry domination design, (Java and ASP) Server pages undesirably mix together design • issues of display and information content in troublesome and ultimately inefficient ways that: • require multiple skill sets that do not belong together, i.e. client side, server side, application specific • results in severe impact on business models: high cost, late delivery, reliance on rare skill sets, • missed marketing windows, competitive disadvantage of being priced out of markets, and • unnecessarily inflexible products incapable of serving the needs of specific user communities • Needed: A new dominant design in distributed architecture to greatly advance Application and UI creation • Solution: Protocol Translating User Agents (PTUA) and Models (SO-M) Architecture

4. Beyond Marketing Buzzwords and Hype: Thin/Virtual Terminal Clients Rich/Smart/Fat Clients Protocol Translating User Agents (PTUAs) Protocol Translating User Agents (PTUAs) come at the mid-point of the fuzzy continuum between “Thin” Clients and “Rich” Clients but only PTUAs are well defined regarding precisely what they do and don’t do!

5. Separation of presentation from application logic “One of the major downfalls of most web applications is the tight coupling of user interface elements with … application logic. This poses a significant problem in team environments because the skills required to develop these two parts are often satisfied by different people. … The layout and appearance of … applications can be altered independently of the application definition and logic… This degree of separation results in applications that are easier to maintain by programmers and readily customized by designers and language translators.” Easy customization, localization, or branding Another highly practical benefit of the separation … among application logic, presentation, and language text is the ease of customizing for different customers or groups of users. From: http://www.mozilla.org/projects/xul/joy-of-xul.html

6. “Model View Controller” Pattern Controller user interaction UserActions Set State ChangeView Update Event View model representation Model Domain Semantics GetState

7. “Model-View-Controller” as Adapted from OOP to Web Environments by The Currently Dominate Application Server Pages (ASP) and Java Server Pages (JSP) Architectures Display Browser “Page” Rendering & User Interaction User Input HTTP Get/Post of HTML etc. Server Side View and Information Content Binding 1 Specialized Framework Protocols 3 Controller 4 “View” 2 1 ASP or JSP 2 Not really the View, but rather a description of the view (consider HTML and its ilk as meta-views) 3 Typically script or DLL/JVM method calls 4 Script/ “Code Behind” or “JSP tag libraries”: typically includes the Controller’s own notion of “intra-page control” and “inter-page flow” (often application process/transaction oriented) 5 COM++/IIOP/RMI/ODBC/JDBC etc. 6 Often “Business Rules” plus DBMS Assorted Specialized Protocols 5 Model including Application Persistence 6

8. What’s Wrong With This? • MVC is an Object Oriented Programming Pattern useful for very tightly • coupled code (inter-related classes) with lots of low overhead interactions • (method calls) using small amounts of information (parametric values) • exchanged frequently in the same (high speed) memory space • Distributed System Architecture favors decoupled logic where invocations • tend to be relatively expensive (lots of protocol overhead and delays) • favoring fewer interactions (protocol operations) that use large amounts of • data (often documents or pages) exchanged relatively infrequently over the • network • Real MVC fails in a highly distributed environment (full MVC over CORBA or • COM+? shudder), so the ASP/JSP architecture is really an adaptation to a • radically different environment (web server) • Unfortunately, a poor one – Resulting from a bad separation of concerns • due to poorly drawn boundaries and division of responsibility in the basic • ASP/JSP architecture

9. Beyond Model View Controller* [AJ]SP * Actually we want to change HOW we use these technologies

10. What’s Wrong With This – cont’d • Fundamentally, the application model and user presentation concerns are being smeared • together by the middle man (the ASP/JSP pages) through mixing in: • Model + ASP/JSP Page + Browser Page Instance = • (Application Model Logic Semantics) • + (Application Model Control X • Binding of Instance Content X • Generation of User Display Description X • Generation of User Interaction Description X • View Control Logic X • Interpretation of Returned User Interaction Descriptions) • + (actual User Display X • actual User Interaction in the browser) • The above creates “entropic synergy” i.e. joining items together creates much worse • results than when they were on their own! • Solution: Refractor! • Model X Generic User Agent X Model Data Instance = • (Application Model Logic Semantics X Application Model Control) • + (Generic User Display Description X • Generic View Control Logic X • Generic User Interaction Description) • + (Binding of Instance Content X • actual User Display X • actual User Interaction X • Interpretation of User Interactions)

11. What is the Glue that Holds The Refactored Solution Together? In a Word: Application Service Level Protocols (ASLP) • Model Centric Architectural Principles are at the core of the strategy: • Models are primary, User Agents are secondary side effects • Models provide content, User Agents make content accessible to • humans • Models and User Agents interact exclusively by means of Application • Level Protocols (ASLP) • The interior of the network (i.e. “models” and “services”) has no • business concerning itself with user presentation – that should happen • only in edge nodes, i.e. only in User Agents • This approach could be considered “Web Services Lite”, but it’s also • compatible with “Web Services Heavy”, for those who want all that stuff • Application Model Controls and Interpretation of User Interaction are the architecture hooks • Application Model Controls depend upon Application Model Logic Semantics and are • independent of actual User Display • Interpretation of User Interaction involves translating them into the actions of • Application Model Controls • Presentation of actual User Display involves translating the Application Model • Semantics, including Application Model Controls, into forms intelligible to humans

12. Anatomy of a Generic Protocol Local Application Program Interface (API) Local Application Program Interface (API) Network Link Network Node B Network Node A AtoB Message 1 AtoB Message 2 AtoB Msg 3 BtoA Message 1 BtoA Message 2 Service Access Point (SAP) a.k.a. Network Address or Network Port • Definition: The protocol is the rules for valid types of messages “on the wire” and the legal sequence of messages (i.e. the “behavior” of each end). • The Application Programming Interface (API) provides the mean by which developers gain access to each Protocol. • APIs relate to Protocol in N:M ways. • In general, a specific Protocol is vastly more important than a specific API in Network Computing Architecture. Traditional software engineering mentality not withstanding!

13. What is the Glue that Holds This Together? First, The Application Service Level Protocol Application Service Level Protocol Application Protocol Model Content Protocol Translating User Agent (PTUA) Model Logic & Persistence (SO-M) Application Protocol Model Controls Physical User Presentation Physical User Interaction Persistence Engine Legend; Service Access Points (SAP) a.k.a. Network Addresses

14. Model Logic & Persistence2 (SO-M) Application Service Level Protocol Structures (Assuming Mainly HTTP Transport) XML Content XML Content XML Content Presentation e.g.. HTML, Javascript (once) Client Web Browse (PTUA) Portal Server1 Request XML Data e.g.. Post data Request XML Data e.g.. Post data Request XML Data e.g.. Post data Request UA e.g. URL + parms (once) User Agent Source Server2 1 Portal Server is Optional if direct connect used 2 Model and UA Source Servers may be directly connected to client

15. The First Five Design Rules For Protocol Translating User Agents and Models • 1. The Model, or more generally the interior network services, contain all of the application semantics: • “Everything that can be known about the application is known to the Model.” • or • “The Model is the source of all of the possible application content.” • The Application Service Level Protocol (ASLP) is the only method by which the model exposes application semantics: • “The Application Level Protocol is the voice of the application.” • The ASLP communicates but does not add to application semantics revealed to it by the Model: • “The Application Level Protocol carries application content but does not embellish it.” • All application semantics expressible by the User Agent comes exclusively from the ASLP: • “The ASLP is the application content, the whole content, and nothing but the content to the User Agent” • The User Agents understands only enough application semantics to give expression to the ASLP by means of user presentations and interactions that in themselves can not insert any additional application semantics. • “The User Agents expresses application content but does not add to it.” • or • “The User Agent is a gloried style sheet for the applications content carried by the ASLP.” • or • “The User Agent only knows about the application only through what the ASLP tells it.”

16. What is all the Glue that Holds This Together? The Application Service Level Protocol and User Agent Loading Protocol User Presentation Application Service Level Protocol User Interaction Application Protocol Model Content Model Logic & Persistence ( May be a Core Model or an Extension Model) Protocol Translating User Agent (PTUA) Application Protocol Model Controls Persistence Engine User Agent Source Server User Agent Needed User Agent Library/Templates Generic User Agent Whole or Part User Agent Library/Templates User Agent Loading Protocols

17. The Sixth and Seventh Design Rules For Protocol Translating User Agents and Models • The Compositional Architecture Rule for Protocol Translating User Agants (PTUA): User Agents are constructed in whole or part (transclusion) as needed from network resources. • “User Agents are created as needed from URIs.” • or • “The User Agent adapts to the ASLP as needed.” • or • “The User Agent gets its brains from the rest of the network.” • or • “The User Agent expresses distributed knowledge from throughout the network (subject only to security constraints).” • 7. The Compositional Architecture Rule for Models (SO-M): same as above for models as needed.

18. The Heritage of Protocol Translating User Agents And Service Oriented Models (UML Conventions) Data Flow Architecture Hardware Data Flow Architecture Software Language Data Flow Architecture, etc. Network Agent and Service Architecture Search Engine Spider Architecture Web Services Architecture etc. Service Oriented Edge Node Architecture Embedded Controller Architecture Sensor System Architectures etc. PTUA/SO-M Architecture

19. AJAX Architecture: Some of the Most Effective Current Technologies for building Protocol Translating User Agents Figure 1: The traditional model for web applications (left) compared to the Ajax model (right). From: http://www.adaptivepath.com/publications/essays/archives/000385.php

20. Why The Extensive Use of XML for the Application Level Protocol? “He gives an example of how XML makes it easy to swap out an application's current GUI -- presentation layer -- with another. "Before XML, we'd been trying to factor out the presentation layer away from the underlying code using some pretty interesting techniques in a homebrew of Perl, ColdFusion and Java," Ostergaard said. "But when XML and XSLT hit the stage, we were able to throw out our own home-grown code and use standards-based code to factor out the presentation layer and bind in a new front end.“ XML also made the binding of the presentation layer to the underlying code much cleaner, and improved performance. "We were able to remove tremendous amounts of old code," he added. “ From: http://idevnews.com/TipsTricks.asp?ID=139

21. Classic Web Protocol Structures Presentation e.g.. HTML, Javascript Presentation e.g.. HTML, Javascript Content Content Client Web Browser Web Server Request Data e.g.. Post data Request Action e.g. URL + parms Request Action e.g. URL + parms PTUA/SO-SM Application Protocol Structures (Assuming Mainly HTTP Transport) XML Content XML Content XML Content Presentation e.g.. HTML, Javascript (once) Client Web Browser (PTUA) Portal Server1 Request XML Data e.g.. Post data Request XML Data e.g.. Post data Request XML Data e.g.. Post data Request UA e.g. URL + parms (once) 1 Portal Server is Optional if direct connect used 2 Model and UA Source Servers may be directly connected to Client Comparison of Classic Web and PTUA/SO-M Protocol Structures (Assuming mainly HTTP Transport) Model Logic & Persistence2 (SO-M) User Agent Source Server2

22. Protocol Translating User Agents and Models: Internal and Network Structures Robert J. DuWors 04 / 26 / 2005

23. Anatomy of a Logical SO-UA Mapping Adapter Protocol to User Interface Informational Transform User Interface View and Interaction Generator Protocol Handler User Inteface to Protocol Informational Transform Physical Presentation Application Protocol Browser Engine Physical User Action

24. Anatomy of an Example AJAX SO-UA (Karam Style*) Protocol View Controllers typically including Presentations and basic Interactions XML Based & Other Application Level Protocol Units URI Loads * Protocol Major State and Action Handlers typically including Submenus URI Loads * Basic User Agent Services including Screen Real Estate, Utilities, and typically Top Level Menus URI Loads * Browser Engine : I.E., F.F., etc. HTML, XML, XLST, Javascript, CSS, Java and so on. * Via URI Application Protocols HTTP XML, Streaming data, etc. User Agent Loading Protocols HTTP HTML, XLST, Javascript etc * It all began by trying to make architectural sense out of this!

25. Service Orientd User Agent (SO-UA) Integration Server Mapping Adapter Protocol to User Interface Informational Transform BizTalk Server / IBM WBI / Windchill etc. User Interface View and Interaction Generator Protocol Handler User Inteface to Protocol Informational Transform (the SO-M never has to talk to the Web Server) Physical Presentation Application Protocol: (HTTP[S], Pure XML) Browser Engine Physical User Action User Agent Loading Protocol: (HTTP[S], HTML, Javascript, XLST, CSS, XML configuration, etc.) An Example Value Proposition: The Protocol Translating User Agent (PTUA) in the Browser connects directly to the Integration Server as a cost effective no frills Data Translation, Business Process Orchestration, and Collaboration Engine (SO-M). Web Sever (Apache/IIS/Tomcat etc.) (Only used to load appropriate User Agent as needed upon request)

26. An Extended Example of using Integrations Servers as an Direct Integration/Collaboration Models (SO-M) with Protocol Translating User Agents (PTUA) using “AJAX” technology Pux – Protocol for PT User Agent, type X (XML) Pm1 – Protocol for Model server, type 1 Puy – Protocol for PT User Agent, type Y (XML) Pm2 – Protocol for Model server, type 2 PLx - Protocol for loading PT User Agent, type X Pss – Protocol for Security server PLY – Protocol for loading PT User Agent, type Y Data Translation & Collaboration Rules Persistence Engine e.g. ODBC Model Type 1 Servers & Persistence : PuX (Pure XML) Pm1 e.g. SOAP, UPnP, etc. Pss Integration Servers: Integration and Orchestration SO User Agents Type X Pm2 e.g. COM+, CORBA, EDI, etc. Puy (Pure XML) Model Type 2 Servers Pss e.g. LDAP, etc. SO User Agents Type Y PLy e.g.HTML, Javascript, XLST, etc. Pss Pss UA Servers (e.g. Apache / IIS) User Profile & Security Servers PLx e.g.HTML, Javascript, XLST, etc. Pss e.g. LDAP, etc.

27. Example of Core Architectural Protocols: with Customization Extension Models and Portal Servers Pm1 – Model protocol, type 1 Pux - PT UA loading protocol (HTTP+HTML+…), type X Pm1A - Extension model protocol, type 1A PuY - PT UA loading protocol, type Y Pss – Security server protocol, type S Pxn – eXternal server protocol (strictly optional), type n Psu – UA server protocol, type u PuX PTUA Type X Pxn Pm1A Model Type 1 Instance “A” (Model Based Security) Pm1 Pm1A PTUA Type X Portal Server PuX Pm1A (Note: All Application Logic resides only in Core Models and in Extension Models) PTUA Type Y Pm1 Extension Model Type 1A PuY Pm1 Psu Pss Pss Model Type 1 Instance “B” Pss User Profile & Security Server UA Server UA Server Pss

28. PTUA/SO-M Layered Architecture1 • Core Models may connect to each other, to Extension Models, or to nothing. • Extension Models must connect to at least one Core Model or to another Extension Model, and may connect PTUAs. • PTUAs must connect to one and only one either Core Model or Extension Model, but never connect to each other! i.e. This Is NOT a P2P architecture. • User Profile and Security Policy Servers may be types of Core Models and may be types of Extension Models. • User Agent Servers live in their own space, but likely have extensive contact with the User Profile and Security Policy Servers, and of course load all PTUAs. • N.B. If needed, there may be a Portal Layer between the Extension Model Layer and the PTUA Layer • 1 Motivated by real world experience. (Note: All Application Logic resides only in Core Models and in Extension Models) User Agent Servers PTUA D Loads all PTUAs PTUA A Extension Model 1 PTUA E Extension Model 2 Core Model A User Profile & Security Servers Core Model B User Profile & Security Servers Core Model D Extension Model 4 Core Model C Core Model Layer Extension Model 3 PTUA E PTUA Variant B1 Extension Model Layer PTUA C PTUA Variant B2 Protocol Translating User Agents

29. The Significance to Product Line Architecture • There are 7 significant degrees of freedom that are the architectural inflection points: • 1. Protocols that can be added, enhanced, or replaced relatively painlessly • Provide minimum coupling between servers and agents • Are the basis of plug and play for the rest of the architecture • 2. Core models that can be added, enhanced, or replaced relatively painlessly • Generally contain the “core product functionality” • 3. Extension models that can be added, enhanced, or replaced relatively painlessly • Further complete product functionality on the basis customized vertical market needs, user community needs, • or individual customer requirements without disturbing the core product • Useful product functionality can be added in the field without privileged knowledge of core product internals • Ensure that all application logic remains in the hands of the server side product architects and away • from the meddling of User Agent designers • 4. User Agents that can be added, enhanced or replaced relatively painlessly • Keep the product suite’s presentation to end users separate from design of the product’s functionality • Put all User Interface concerns solely into the User Agents and in the hands of the User Agent designers • Keeps server side architects from specifying really, really dumb and inflexible User Interfaces • Primary point of customization for the market place: “small changes can have big impact - the 20/80 rule: • 20% of the effort for 80% of the gain”, or somewhat more cynically, “sell the sizzle, not the steak” • 5. User Agent Servers that can be added, enhanced, or replaced relatively painlessly • User Agents may be statically or dynamically generated for application, security, or personalization needs • Might be the last refuge of JSP and/or PERL,  but XLST also likely to be a major tool • 6. User Profile &Security Servers that can be added, enhanced, or replaced relatively painlessly • As noted in the Distributed Capability Model, security severs can interact with both personalization and model • based security, as well as with filter based security • 7. Portal Servers that can be added, enhanced, or replaced relatively painlessly • Provides deployment architecture “glue” as needed, likely to get around “same source” security policies, and/or • differences in multiple realm administration

30. The Significance to Product Line Architecture – cont’d • Commonality/Variability Analysis (CVA) • The greatest Commonality and stability exists in the central Core Model layer, and decreases outward • The greatest Variability and instability exists in the edge User Agent layer, and decreases inward • Relationship to “Service Oriented Architecture” • Every node in PTUA/SO-M architecture is “service enabled” in that it speaks a defined machine-to-machine • protocol • this makes it relatively easy to “mix and match” at all stages from design time through run time • it might be call “Service Oriented Architecture Lite” • it is fully compatible with the goals and techniques of “Service Oriented Architecture Heavy”: • SOAP, WSDL, etc. • Only the User Agents are User Interface oriented as well • PTUAs are “service enabled” on their back end • PTUAs are also “user interface oriented” on their front ends, which are viewed as specialized forms of • human-to-computer protocols