HP JetSend Network Architecture
Developed in the mid 1990s, HP JetSend was breakthrough technology at the time and has still never been matched. It enabled direct peer to peer communication over any network or any other connection technology. This package contains the specifications that enabled this unrestricted connectivity. The technology described in this document package is protected under the following international patents which are owned by the Hewlett-Packard Company: DE69802792D1, DE69802792T2, DE69835314D1, DE69835314T2, EP0872991A2, EP0872991A3, EP0872991B1, EP0886411A2, EP0886411A3, EP0976058A1, EP0976058B1, US6202096 B1, US6502000, US6721286, and WO1998047076A1.
HP Jetsend was a next-generation Internet appliance communication protocol designed to allow mobile users to communicate between different devices like PCs, laptops, PDAs, cellphones, set top boxes, smart whiteboards, digital cameras, LCD projectors etc., without using a server or other host. This allowed users the flexibility to use devices without installing drivers or worrying about what format the information was in before sending or receiving it. This flexibility was unique since other solutions required users to consider the file type and capabilities of the devices that they are sending information to.
This download package contains the HP JetSend network software architecture and design specifications. This technology was operating system-independent, transport-independent, server-independent, application-independent, and could be built into any information appliance. It used a singular driver to communicate with all HP JetSend-enabled appliances, and offered reliable and efficient virtual-circuit connectivity and simultaneous, multi-channel session communications.
An Architecture for IT Architectural Roles
IT organizations refer to a single, individual system as an "asset." Large IT organizations own hundreds or thousands of assets. To manage complexity, they organize the assets into Asset-Groups - a hierarchical scheme in which they group assets into Platforms, which are in turn grouped into Domains, which are then grouped into Enterprises. Each level of asset-group organization defines a corresponding Architect role. Each asset has somebody serving in the role of an Asset Architect. (The Asset Architect role is usually part of the "Technical Lead" role.) Each platform has somebody serving in the role of a Platform Architect. Each domain has has a Domain Architect. Each enterprise has an Enterprise Architect. Asset-group architect roles are stable over time. As long as the asset, platform, domain, or enterprise exists, the corresponding architect role exists. These roles are not tied to projects or the lifespan of projects.
A Solution is a set of capabilities from one or more assets that automate one or more related steps of a business process. Each solution calls for a corresponding Solution Architect role. The Solution Architect role is temporary. It is tied to a project and the lifespan of the project. The Solution Architect role only exists for as long as the project to develop the corresponding solution exists. A Solution Architect would typically migrate from one project to another as the work on the previous project wrapped up.
To understand a role requires more than a role definition and list of responsibilities. It also requires understanding the context that gives the role its meaning. This presentation describes the IT environment that provides the context for defining IT architecture roles and then proceeds to identify and describe the consequent architectural roles.
Signed And Secure Communications
How can you trust files that you download from the Internet? How do you know a file really is coming from who it says it's coming from? How can you be sure that the file has not been altered maliciously between the time it was created and the time you download it? These are particularly important questions when you are downloading software to run on your computer and which will have access to the computer's file system and other resources. This paper describes the most common method of making the Internet a safe and reliable source for software distribution - code signing.
Providing A Web Service Using A Network Of Servers
This invention includes a system and method that mediates access to a network of servers hosting a website. A central controller or server is the primary host for client requests, mapping the requests to the appropriate server by redirecting client web requests to the appropriate host server. The status of the server network is constantly monitored by the primary server by periodically "pinging" each of the servers in accordance with standard Internet Protocol (IP.) If a server becomes unavailable, the "down" status is recorded and future client requests for pages hosted by the down server are either immediately issued a user friendly error message or are redirected to an alternate web page on the primary host server or on another available server.
Architecture Development Guide
Systems are usually hierarchical structures of components. At the top of the hierarchy is the system as a whole comprising a small set of interconnected high-level objects. These objects may be static data structures, dynamic algorithms, or composite objects (objects that encapsulate lower level objects). The next lower level consists of decomposing those high-level objects, each of which may itself be composed of a small set of interconnected lower-level objects. From Architects who design using levels of abstraction to Programmers who decompose their code into hierarchical sets of objects, Developers use the principle of "design in order of increasing detail" at all levels of system design, regardless of the design paradigm (structured, object-oriented, etc.).
This document describes an approach - consistent with the hierarchical nature of systems - to defining a software architecture. It also explains the reasoning behind the approach and describes the artifacts that the Architecture Team should produce.
Using a Pair-Choice Decision Matrix
A "Pair-Choice Decision Matrix"- which is often called a "Pair-Wise Ranking" - is frequently used as a means of prioritizing or ranking lists of options. Ranking options helps in deciding the order in which to do things and whether to do some things or not do them at all.
When valuable resources are involved, those with the loudest voices, who are often the most powerful, tend to be heard and get their way. Furthermore, each person has a natural bias toward their own concerns and areas of interest. It is therefore important that when people are making important decisions about resource use, they use a method that gives all involved a chance to have their views heard. A Pair-Choice Decision Matrix in which each item on a list is compared in a systematic way with each other provides such a method. This users guide describes how to setup and use a Pair-Choice Decision Matrix.
For many Developers, it is very difficult to assimilate the concept of endianness to the level of clarity necessary to actually implement software that gracefully handles it. All the verbal or written explanation in the world does not seem to "sink in" very easily. This is a topic where a good picture is worth a thousand words. Consequently, this document contains a diagram which I think clearly illustrates endianness and obviates the usual long-winded and baffling explanation.
Corralling Complex Regular Expressions
Sometimes as Programmers, despite our best efforts to avoid them, we have to face the horror of creating, maintaining, or even just comprehending a complex regular expression. I once found myself confronted with a Java syntax colorizer that used regular expressions exclusively to find syntactical elements within a Java source code file. Regular expressions are not the optimal way to parse Java source code, but too bad, I had to provide this colorizer with regular expressions anyway.
The first syntactical element for which I needed a regular expression was a Java method declaration. I am not a regular expression guru and with one look at the grammar for Java method declarations, I knew I was headed into too deep of water. Java method declarations are a cornucopia of variability and any regular expression that can match them is going to be big and complicated. Java method declarations span at least the range of complexity from declarations like this:
To declarations like this:
public static synchronized final
<TypeReturn, TypeParameter , Type1 extends Comparable, Type2, Type3, Type4, T>
List<? extends T> param1,
throws iOException, NumberFormatException , DEStitute
I decided it was time to punt. I Googled for a usable regular expression that someone better than me had already constructed; and I actually found one - just one. Encouragingly, it looked like a big enough pile of gibberish that I felt it must surely work. I downloaded it and compiled it into some Java code so I could run some tests and see what it did. And it did work - mostly. Unfortunately, "mostly" was not good enough. So, I tried to debug it, and that is when the nightmare began. It was a solid block of text when I downloaded it, so I started by structuring its layout with newlines and indentation, and that went easily enough. On the other hand, I was aghast at the number of nested levels of groups it contained. It was convoluted beyond my ability to analyze it and comprehend it sufficiently to debug it. I decided I would have to construct one myself from the ground up so I could understand it.
Having only ever constructed simple regular expressions, my approach was to try to crank out the regular expression string sequentially. That did NOT work! It quickly became very long and complex and I could not keep my mind wrapped around enough of it at one time to continue. And so, I began to break it down into parts, with each part tailored to match a specific portion of the method declaration syntax. I noticed I was writing the same short sequences repeatedly within a large and growing body of regular expression code. I also noticed that no matter what I did, the whole thing was going to be an unmaintainable monolith when I was done. The next person that had to read, understand, and maintain it was going to have to be put on suicide watch. Moreover, that person just might be me sometime in the not too distant future. Consequently, I hastened to develop a method that would lead to a robust and correct regular expression and at the same time leave a trail of artifacts that would make maintaining and comprehending the regular expression a tractable task. This paper describes that method.
Calculating End-to-End Series and Parallel Solution-System Availability
This document is provided as an MS PowerPoint slide set and therefore requires that you have PowerPoint installed to be able to open the file after downloading it to your computer. However, you can view the slides as images without PowerPoint by clicking on the "View Document" button.
The slide set also contains embedded MS Excel objects. Consequently, Excel must be installed on your computer for those portions of the slide set to function as described.
The slides describe in simple terms how to compute the availability of a composite system based upon the availability of its constituent parts. An example of a composite system is an IT solution that is generated by connecting multiple IT systems together. In such scenarios, the overall availability of the composite solution is calculated by modeling the system as an interconnection of parts in series and parallel. These slides explain how to compute the aggregate availability of components connected in series and parallel. The slides include embedded calculators for entering actual component availability numbers and calculating the resulting composite availability.