At the risk of not only stating the obvious, but also sounding like a prognosticating blowhard… I’d say that developers with a skill-set that only involves programming to a spec should worry about being automated out of their jobs. This has happened countless times through our history of near-continuous economic revolution and there’s no reason to believe that it can’t happen with software. (that was the blowhard part) The frameworks we code against have increased in sophistication and utility a tremendous amount over the last decade, and the previous decade for that matter, though it seems to be accelerating. What was once many lines of code is now few and I expect this trend will continue. Add to that the coming (this is the prognosticating bit) rise of domain specific languages and you can see that the design and the code will be converging and folks who make their living off the current delta are going to feel the squeeze.
The guy who wrote that is one of the guys that will get you new technologies. The text above is his typical day to day language. And he didn't learn his shit from the Discovery Channel or Wikipedia. Smarter than the rest of us combined, he is not a programmer. He invents NEW ideas, processes and programs. HE is the type of individual that NASA and this Government funds to get to Mars. Hell, who cares if the next ten missions explode before reaching orbit. The money funding the research is whats important. Same with military research and development. It employs very intelligent people keeping us on the cutting edge, instead of supporting some fat ass with twelve kids, no education, no job and no future.
One of his Patents: (His expertise is in development of artificial intelligence. Your "talking computers.") THIS is your Mars money.
Prescriptive architecture for application development description/claims
Brief Patent Description
TECHNICAL FIELD
[0001] The described technology is directed generally to application development and, more particularly, to an architecture for application development.
BACKGROUND
[0002] There is a current trend in software design toward modeling and delivering software logic and applications as services. With the growth of the Internet, and in particular, the maturing of the World Wide Web ("Web"), application developers are increasingly delivering these services as Web services.
[0003] As an example, an application developer may need to write some business logic and may want to package up the business logic in a way to expose it as a Web service. Typically, the developer will have to define an interface with the necessary input data, and will also have to define the output. The developer then writes the business logic that does some amount of work using the designed input and which creates the output. In addition to writing the business logic, the developer will also have to write logic for ancillary requirements to the business logic, such as auditing, security, error handling, caching, etc.
[0004] For example, the service may need to cache the output value. In order to properly incorporate this feature into the service, the developer will have to (1) check the value of the outputs, (2) create a kind of key based on those values, (3) match the key with a possible value in the cache and return the value if there is a match, otherwise proceed to the service logic to create the output value, and (4) add it to the cache before returning it back to the caller. The developer will need to design and implement other attributes of the cache, such as a strategy for expiring an item in the cache, a strategy for notification in the instance an item in the cache is expired, etc.
[0005] The developer will need to perform a similar task for each of the ancillary requirements. Additionally, because Web services typically communicate over a network, the developer will need to design and code the communication infrastructure for the service. Developing and delivering a large number of services in this manner can get tedious, especially given the fact that the ancillary requirements and the communication infrastructure do not contribute to the business logic. Further, the cost and complexity of implementing the Web services is increasingly becoming prohibitive, particularly for small to medium sized organizations.
[0006] One reason for this is that while the business logic generally does not change, the underlying and ancillary technologies are very likely to change over time. Presently, numerous standards that address various aspects of Web services are evolving and/or being developed. Because the Web services typically include the ancillary logic, the Web services and, particularly, the ancillary logic will have to be modified and enhanced as these standards evolve and develop in order to take advantage of the standards.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is a block diagram illustrating selected components typically incorporated in at least some computer systems on which a facility describe below executes.
[0008] FIG. 2 is a high-level block diagram showing an environment in which components generated by the facility operate.
[0009] FIG. 3 is a block diagram illustrating selected components of the facility, according to one embodiment.
[0010] FIG. 4 illustrates a flow chart of a method by which a service developer utilizes the facility to develop and deploy a service, according to some embodiments.
[0011] FIG. 5 illustrates an example code snippet of a calculator application containing service deployment metadata.
[0012] FIG. 6 illustrates the example code snippet of FIG. 5 further containing an aspect container attribute.
[0013] FIG. 7 illustrates an example code snippet illustrating both a class level and a method level aspect container deployment.
[0014] FIG. 8 illustrates a flow chart of a method by which the facility compiles the intermediary language assemblies, according to some embodiments.
[0015] FIG. 9 is a block diagram illustrating an example aspect container.
[0016] FIG. 10 is a display diagram showing a portion of an example graphical user interface suitable for configuring and administering frameworks, aspects, and aspect containers.
[0017] FIG. 11 illustrates a flow chart of a method by which the facility generates an aspect container at runtime, according to some embodiments.
[0018] FIG. 12 is a block diagram illustrating aspect containers attached to both a sender and a receiver, according to one embodiment.
DETAILED DESCRIPTION
[0019] The invention will now be described with respect to various embodiments.
[0020] The following description provides specific details for a thorough understanding of, and enabling description for, these embodiments of the invention. However, one skilled in the art will understand that the invention may be practiced without these details. In other instances, well-known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments of the invention.
Welcome Visitor! Please take a few seconds and 
