Wednesday, September 29, 2010

How to Join the HLL Open Source Project

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.


The High Level Logic (HLL) Open Source Project is hosted on; and joining the HLL project is just like joining any other project hosted on

1. To become a member of the project, you first need to register (free) at

2. Then you need to contact me by email. Include your registered name and ask to be added to the project. -> my email.

I will grant you Observer status. Then we can chat if you want to do something special for the project.

Otherwise, feel free to sign up for email discussions and announcements, or visit the project forum and start to discuss something.

BTW: Have you subscribed to this blog yet? What about the High Level Logic (HLL) Facebook group? Note that all the page information and my email address are in the upper right hand corner of this blog page.

Sunday, September 26, 2010

The Reincarnation of SOA - Sort of!

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

Wouldn't it be nice if a comment on Service Oriented Architecture (SOA) would attract a lot of attention (for my blog, I'm thinking)? Thousands of people googling 'SOA' come right to my site and find out more about HLL. I can't expect that, because I'm provoked on this occasion to comment in response to a discussion that started in January of last year.

VP and Research Director of The Burton Group, Anne Thomas Manes wrote an article entitled, SOA is Dead; Long Live Services. Burton Group surveys IT R&D and provides business consulting services. They have a particular interest in SOA related development. Ms. Manes' noted a high percent of failure in efforts to use SOA and warned that the change-over is disruptive; requiring a full commitment to succeed. Then she added:
The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.
One of the many respondents was Kurt Cagle, editor at O'Reilly Media. In SOA is Dead? It's About Time!, he says he is philosophically quite close to Manes with regard to SOA, and adds “that it seemed to be less technology and more marketing term for a number of fairly distinct things, to the fact that distributed technologies are, by their very nature, distributed.”

I particularly enjoyed this comment:
RESTful services - are beginning to gain real traction even as the big-box SOA projects are falling to the accountant's axe. The publish/subscribe model in which what you're publishing are not blogs but data documents (think XBRL or HL7) performs the same type of decoupling that message-oriented SOA did, but completely abstracts the intent from the process of communication.
Now what about HLL? First off, I have to say that I tend to use the dictionary. Not some specialized up to date listing of technical terms – you know, the plain old English language dictionary. I helps to keep me from getting confused by marketing hype. To me, the term “Service Oriented Architecture” refers to an architecture that is oriented to providing services. It's a general term. If you are going to use HLL in support of providing services, that's fine. It can do that (and I think you should). Just don't say something like HLL is an implementation of SOA. SOA isn't a specific thing, so it's grammatically confusing at the very least. SOA isn't itself a technology, even though there seems to be a set of rather basic requirements to do a good job of it.

In the light version of HLL, sockets are used in support of loosely coupled communication. What's generically called the "Java EE" version will probably use JMS. In core processing, HLL will use FIPA to “abstract the intent from the process” in a way that facilitates communication with other systems. Traditional XML (and even SOAP) processing is also supported … and ... HLL actually allows message passing through a variety of structures using the generic 'Object' with object type recognition on the receiving end. The choice for application happens out in the application software, unencumbered by HLL's core architecture.

As for the difficulty of implementing SOA systems – remembering that HLL is HLL and isn't marketed this way at all (although by all means, if SOA is what you want, I'd be pleased if you'd take an interest in HLL) – HLL provides the structure. I don't see it as having the problems the other author's describe. It's flexible. You can centralize to the extent that centralization makes sense, and you can also put copies of HLL on many machines, specializing each set of applications they support, give them access to remote applications and services, either directly or through another copy of HLL.

They seem like old problems. Too boot, HLL is very resource oriented, so much so that I'm almost tempted to refer to its architecture as an ROA - well, maybe I should. If services is what you want, how are you going to do that? (The question how is so very fundamental to engineering.) Well, depending on how you define "resources" (check the dictionary again) - using an ROA might be the answer. Rather trivial once you say it. How are you going to provide services? Is there even any way to do that without using resources?

Well, that's all for now. This entry was just meant to be a quick comment; and it really is - nothing more.

Friday, September 24, 2010

Google Programmer Wanted

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

HLL Issue #12 - Fast Processing Large Amounts of Distributed Data

Google is exceptionally good at dealing with large amounts of distributed data. If you haven't tried the latest version of Google Chrome, you should; but you already know that the Google search engine now comes close to performing miracles. Google also offers an API and an opportunity to use their physical infrastructure for rapid processing of large amounts of distributed data in your applications.

It would be of interest to this project if someone is interested in investigating the use of Google technology to support HLL applications with large amounts of distributed data. I (project owner rogerfgay) would be happy to support such an investigation with ideas on the concept and integration with HLL.

Becoming part of the HLL project requires (free) registration at Then send me your registered name to request "observer" status for the project:

Monday, September 20, 2010

High Level Logic: Rethinking Software Reuse in the 21st Century

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.


An application programmer spends six months perfecting a set of components commonly needed in the large company that employs him. Some of the components were particularly tricky and key pieces required very high quality, reliable and complex exception handling. It has all been tuned to run quickly and efficiently. Thorough testing has demonstrated his success. Part of his idea of “perfection” was to build in a way that the software, even many of the individual components, could easily be reused. But it is surprisingly likely that no one outside of a small group within the project will ever hear of it.

Tens of thousands of programmers building thousands of applications, repeatedly building the same functionality over and over again. A collective nightmare for CFOs. There are those who believe that the problem has been addressed with “best practice” object oriented programming techniques, enterprise frameworks, and strategic development of specialized open source systems. Certainly they are right – up to a point.

While many available tools and good programming technique offer opportunities to reuse software, and most definitely reduce the need to rebuild many “lower level” (relatively speaking) functions, they also facilitate development of much more complex systems and provide a plethora of gizmos for doing old things in new ways, producing a never-ending stream of reasons to update what has already been done. Out there on the edge, where application programming actually takes place, the software reuse problem is a moving target.

Generally speaking, the benefits of software reuse far outweigh the costs. [1] But in the messy world of real-world application development, the challenge can be complex. Many managers value rapid prototypers over “best practice” engineers, not understanding that building on somewhat sloppy early results will typically and dramatically increase project time and cost and reduce quality. In larger organizations with shared interests, they wonder which project should bear the increased cost of building reusable software components? Who pays the cost of searching the (sometimes huge, distributed, and insufficiently documented) code-base to look for possible matches? Should a software project focus time and money on special packaging, documentation, and “marketing” material to promote reuse of components it builds?

I believe it is possible to realign the software development process in a way that will make everyone happy; from the executives who will see measurable improvements in productivity, to project managers pushing for rapid results, to the programmers who fantasize about widespread use of their best work, to the CFOs who see the company mission fulfilled on a smaller software maintenance budget.

Such a dramatic statement needs a theatrical follow-up. In the spirit of The Graduate, I just want to say one word to you – just one word. Are you listening?


Exactly what do I mean by that? There is a great future in configuration. Think about it. Will you think about it? … Shh! Enough said. That's a deal.

OK, it's not actually enough said in this context. I'll get back to “configuration” below. What I want you to think about first, really think about, is that this is the age of software components.

In the distant past, it was easy to see that it would be useful to represent often repeated binary sequences in hexadecimal code, then an obvious step to package sections of code into a machine language to handle common operations at a higher level. Then combine those into commonly used functions. It's been almost a half century since we got a little excited about “structured programming.” We built functions and libraries, and once again noticed that program structure and flow as well as development tasks often had commonalities across applications. Special tools emerged. It has been thirty-five years since the first IDE was created.

Believe it or not, it has been a half century since an object oriented programming language with classes and instances of objects, as well as subclasses, virtual methods, co-routines, and discrete event simulation emerged from research in artificial intelligence (Simula 67). C with Classes was renamed C++ in 1983 and developers quickly replaced their C compilers with C/C++ compilers. The Java Language Project was initiated in 1991 and Sun Microsystems offered the first “Write Once, Run Anywhere” public implementation in 1995 and the first release of the Java Enterprise Edition in 1999. This is the age of software components. But even one decade is a very long time in the software world. One might almost expect that something new is about to happen.

Beyond Guestbooks and Smiley Faces

If you're entrepreneurial, perhaps you have already realized that you could package sets of useful components as finished product suites (components = products). If you are an independent consultant or operate a specialized software development company, you can offer high quality services based on proven technology with your own product suite(s). (Shame on you if you don't already.)

But let's say that you want to build a complete system, for some purpose, that does something besides impress people with its quality and reusability in the development process – an application. Adaptation by configuration is pervasive. Here are some examples.

Word processing software serves a very specialized purpose. It is adaptable by configuration. You can install specialized language support, adjust the characteristics of various text blocks, add templates for complete (reusable) document layouts, and even adapt it for use by the visually impaired. Some word processing systems are also extensible.

Lotus Notes has a history that reaches back into the 1970s (PLATO Notes). It is familiar to many software developers (and others) as an interactive, networked system that is adaptable (by configuration) to the specifics of a project or other activity, and also extensible. This is a bit more general than a word processor, providing a suite of services, but still somewhat specialized. IBM offers both extensions and tools. Custom code can in fact be added to extend the capabilities of the out-of-the-box system. Extending the concept, Lotus Sametime is offered as middleware for building custom networked applications.

WordPress “is web software you can use to create a beautiful website or blog,” says the WordPress website. “We like to say that WordPress is both free and priceless at the same time.”
The core software is built by hundreds of community volunteers, and when you’re ready for more there are thousands of plug-ins and themes available to transform your site into almost anything you can imagine. Over 25 million people have chosen WordPress to power the place on the web they call “home”.
People all over the world build and post their own components. It doesn't take a software professional or layers of bureaucracy to select and add powerful new interactive features (beyond guestbooks and smiley faces) to customize websites. Welcome to the 21st century (and pervasive CMS)!

The Brave New World

What if you could do that with all software development? And what if a major portion of the reusable software components in a company, starting with their design, were treated seriously as independent internal products rather than vaguely outlined portions of a large pile of 1s and 0s? The idea might be much more practical than you think.

The shift to object oriented programming changed the way programmers think about creating systems. Components are what systems are made of these days. This major technological paradigm shift has also had a major impact on project process; which now leans toward “lean,” discrete, and agile. [5]

Some of the most complex and potentially expensive aspects of software reuse involve getting all the software organized, identified, documented, and searchable. But consider what is already inherent in the tools and processes commonly used by modern software engineers. Software objects are arranged in packages. In best practice, naming of packages and components is systematic and aims to make functional purpose easy to recognize. Package identifiers can also serve to direct programs to the physical location of each component. Documentation on individual objects, arranged in packages, can be automatically generated (easy to organize and keep up-to-date).

Best software practices encourage reusability. If I'm creating an application that reads and interprets 25 XML files, it only makes sense to write one (only one) general purpose read and parse component for XML files, so long as that is possible, rather than new code for each file. Only that part which must be treated uniquely requires additional code.

My experienced observation is that much of the time, in common practice, building nifty general purpose code is less expensive than building sloppy spaghetti code. Building good code from the start dramatically decreases project time and cost. There will be fewer avoidable complexities in downstream development, fewer bugs, and consistently higher quality. Consider also that experience matters. Developers who spend their careers building good code, not only prefer doing the job right, but become extremely efficient at it. When they design, what will come to their minds is good code, not junk. When they implement the design, they are quite familiar with the techniques and details needed to build good code.

From a variety of perspectives, developing reusable components in the spirit of discrete products is beneficial, and the time is right. What more is needed then, to maximize the benefits of software reuse?

Regular Stuff + Artificial Intelligence = Something

The Java language and frameworks like Java EE continue the development path that started with binary sequences in the first section of this article. They differ in that one does not generally innovate on the concept of adding two integers, for example. Initially, getting good fast versions of common functionality for a variety of machines was the point. Both Java SE and Java EE (and others) provide support for higher level functionality supporting, for example, a variety of ways to move data around on a network for display and processing.

In the world of artificial intelligence research however, it seems people enjoy branching off in new directions, “moving things around” (so to speak) to change the character of computing. The old research definition for AI was simply to get computers to do things that at present, humans do better. From the start, people thought about moving the human role (part of it anyway) into the computer.

In the mid to late 1980s, complex rule-processing software came on the market. New companies emerged marketing “expert systems” tools, large companies invested, and more powerful rule-processing capabilities were added to existing commercial products like database systems. A slightly deeper look yields something more interesting than a packaged way to process lots of “if-then” statements. AI researchers wanted to move logic out of application programs and into a general processing engine, with application logic treated as data. I'm going to cast that into the perspective I offer now, with a description that the researchers and developers at that time may never have used. Expert systems applications were built by configuring the processing engine with a rule base (and other information).

More powerful systems like KEE became commercially available in the same decade, incorporating a new and powerful programming component - objects - into the mix. The object oriented programming concept itself repackaged some of the common elements of complete applications into individual components; not just by definition, but by encouraged design practice. Its introduction was disruptive, setting vast numbers of working engineers to the task of rethinking how software systems should be written. An “object” you say? Sounds classy!

My agent is on the phone.

“A software agent is a piece of software that acts for a user or other program in a relationship of agency,” says Wikipedia (citing two sources [2][3]). Agent technology also has a history. The concept can be traced back to 1973 [4]. An actor is "a self-contained, interactive and concurrently-executing object, possessing internal state and communication capability.” One might call it the ultimate object.

Agent technology has already emerged from artificial intelligence laboratories. Modern agents extend the “Write Once, Run Anywhere” idea, even to the extent that there are what might be called “door-to-door” salesman varieties; traveling agents (also called robots, bots, web spiders and crawlers and even viruses) that move around the Internet (sometimes duplicating themselves) to perform tasks.

The telecommunications industry recognizes the importance of a new technology that screams to be used as a central processing system for a wide range of applications that can service the wide range of networked devices available today. JADE (Java Agent DEvelopment Framework) is a free software Framework distributed by Telecom Italia, that “simplifies the implementation of multi-agent systems.”

It changes the way you think about software development. Don't worry about the wide range of interfaces needed for so many devices. They're supported. Don't worry about the complexities of communication. The code is written and maintained by someone else. This goes beyond the relatively “low level” programming components available in IDEs and support offered by higher level development frameworks like Java EE. Much of “the system” already exists. Just focus on the very specialized components needed for your particular application that can be cast into the agent framework. Only that part which must be treated uniquely requires additional code.

You then let the framework know when your agents are needed. When they are, they get the call; automatically. And by the way; intelligent agents can sense when they are needed and respond appropriately, even learn and adapt to new circumstances.

Sometimes one is not enough. A multi-agent system (MAS) is a system composed of multiple interacting intelligent agents. Multi-agent systems can be used to solve problems which are difficult or impossible for an individual agent or monolithic system to solve. Examples of problems which are appropriate to multi-agent systems research include online trading, disaster response, and modeling social structures.

High Level Logic

OK, quick! Think of a way to go beyond what's been discussed so far.

How about this?
  • Design what is basically an agent-type system that easily interacts with others of its own kind installed anywhere in the world and may also communicate with other agent systems facilitated by use of standard message structures. (Note that the FIPA standard message offers SOAP level power.)
  • Identify high level logical processes that you expect to be common to thousands of applications (maybe every conceivable application?) and provide generic engines for doing that part of the work; both in the spirit of “expert systems” above – i.e. moving additional, common, higher level application logic to a generic engine for the first time and embellishing on the new generic processor and also support more basic processes like intelligent XML, encryption, authentication, rule-processing ....
  • Provide a “general problem solving” (high level process … what do you want, what are the variables … etc.) engine.
  • Include the ability to carry out more complex processes by implementing custom plans.
  • Devise an even higher level generic processor that ties all of the above together in a top-level process.
  • Allow application developers to extend and customize if they wish, without destroying the ability of one system to interact, cooperate, and share with the others.
  • Provide a simple way to tie in a GUI – as needed – for a great variety of devices.
One more thing, while we're on the subject of code reuse.
  • Provide a mechanism to call upon any level of reusable code, from large systems to discrete components integrated through plans, rule-processors and other high level structures. Support options for utilizing common code remotely (if, for example, the process utilizes other remote resources), to fetch and utilize temporarily, and to fetch and store locally.
Now what you have is an outline for a system known as “High Level Logic” - HLL. The High Level Logic (HLL) Open Source Project stems from a history that goes back into the 1980s, as a concept for unleashing the power of expert systems. Prototype software was more recently built as part of a larger intelligent robotics project. The commitment to open-source development was made in July, 2010.

Although the development project is now (September 2010) at an early stage, there is sufficient software available to create applications. The plans to complete the first complete “light-weight” version, using only Java SE, that will have the full set of characteristics described above are quite concrete, already committed to specific technical issues logged in the project's issues tracker. An outline for a somewhat heavier version using Java EE components is given on the project description page.

Yet Another Path to Code Reuse

Subtly perhaps, four different approaches to code reuse have been mentioned and illustrated in this article.
First, the development of higher-level languages involved assigning names to commonly used bits of logic in lower level coding and the development of tools to translate (interpreters, compilers, …) back into lower level code. One common implementation of the lower level code was then used by everyone using the same higher level language (compiler …).

Second, object-oriented computing involved re-organizing some of the processes common to applications from the complete application level, down to component level.

Third, a more open mass use of certain web-based technologies led to common application cores and shared extensions. (Proprietary: Lotus Notes → Open: WordPress; and also more on the extreme techie side, consider the history of Sun Java development).

Fourth, highly innovative research identified distributed application logic that could be extracted into generic processing engines.
At least one more exists, which will be the subject of later articles. Learning and adaptive software has already reached well into the stage of commercial use. Developers write code explaining the results they want. The learning system automatically creates the code. There are many circumstances in which the same specification code written by developers can be reused on various platforms (physically different robots for example) in different environments and for different purposes (identifying and moving different objects in new environments for example). Even existing application code can be reused and automatically adapted to differences.

The direction of HLL incorporates all of the above providing a useful general purpose application platform rather than a specialized application platform (like CMS for example). It will be part of the purpose of the HLL Blog to provide further focus on these characteristics of the HLL system.

Given the current state of HLL, there is at least one characteristic that should be emphasized. Application developers focus their coding work only on those components that are unique to their application. There is a great deal of flexibility in what can be done on the application, because – simply – there are no restrictions. Java developers, for example, can write any kind of Java components they wish. The HLL engine can use components from anywhere an HLL system exits on any installed HLL system (component sharing). Components that builders wish to be accessed by HLL are named (like higher level language), and accessible to HLL systems through their configurations.

This aspect of HLL is worth emphasizing. It is the intent, that – especially as an organization builds its library of reusable functionality – application development will be largely a matter of configuration; and that's a very good reason to push reusable code development.

  1. SOFTWARE REUSE ECONOMICS: COST-BENEFIT ANALYSIS ON A LARGE-SCALE ADA PROJECT, Johan Margono and Thomas E. Rhoads, Computer Sciences Corporation, System Sciences Division. (I believe this 1992 article in ACM, which I found freely available on the Internet, is still quite relevant. Margono and Rhoads however, did not say “benefits … far outweigh the costs.” They actually said; “benefits … have so far outweighed the costs. We believe that this will continue to be the case.” Eighteen years later, with a great variety of new advantages mentioned in this current article, it is surely even more true due to long-term technical focus on the issue; and this article recasts the issue in that light. We've come a long way.)
  2. Nwana, H.S. 1996. Software Agents: An Overview. Knowledge Engineering Review, Vol.11, No.3, 205-244, Cambridge University Press
  3. Schermer, B.W., Software agents, surveillance, and the right to privacy: A legislative framework for agent-enabled surveillance. Leiden University Press, 2007, p.140.
  4. Carl Hewitt; Peter Bishop and Richard Steiger (1973). A Universal Modular Actor Formalism for Artificial Intelligence. IJCAI.
  5. Agile software development methods Review and analysis, Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, and Juhani Warsta, Espoo 2002, VTT Publications 478, 109 p.

Sunday, September 19, 2010

Robot Ethics and HLL

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

Work on my next blog post just hit 2500 words (which I hope are well-chosen) and it looks like I'll be busy for a while trying to give a good introduction to the HLL concept, character, rationale and purpose (and state of project, etc.) before delving more deeply into the technology (and of course, working on the software).

There is however, a topic of special interest that I would like to write more about, particularly w.r.t. what HLL can have to do with creating autonomous moral agents, but for now will simply introduce quickly with some links.

Brainstorm Responds to Robot Ethics Challenge comments on the use of HLL in the context of international discussion on the topic.

Ethical and Legal Aspects of Unmanned Systems Interviews is a set of interviews conducted by Gerhard Dabringer, Institut für Religion und Frieden, for the Austrian military. My little contribution, which contains a similar description of HLL to that in the article above (and more) starts on page 169, titled; A Developer’s Perspective.

English language transcript of a Swedish television documentary on robot ethics (includes limited coverage of Barcelona experiment mentioned in my interview - video also available; see transcript).

If the topic, autonomous moral agents seems intriguing to you, I suggest Wallach and Allen's book; Moral Machines, Teaching Robots Right from Wrong. Their blog is (click) here.

And here's a link to the Robot Ethics Facebook group.

Thursday, September 16, 2010

What is an Agent?

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

This entry includes section 2.1 of A Methodology for the Analysis and Design of Multi-Agent Systems using JADE, by Magid Nikraz1a, Giovanni Caireb, and Parisa A. Bahria aSchool of Engineering Science and Parker Center, Murdoch University, Dixon Road, Rockingham, Western Australia 6168 bTelecom Italia Lab, Via Reiss Romoli, Turin, Italy 10148.

It is intended here as part of a larger discussion on the use of the agent approach in HLL. HLL is not simply another agent platform, so it is important to first note what agents actually are, to allow a clear discussion on the extension that HLL provides. Note that the HLL concept was first conceived in the mid-1980s as a way of unleashing the power of "expert systems." I don't believe I'd even heard of software agents back then. But it is cause to smile, that there is now a well recognized and developing technical approach underlying the HLL "extension." (More on this in future blog posts; I assure you.)

The paper being quoted discusses development methodology for agent systems using JADE as a concrete example. This is also a good topic related to application development using HLL - since developers will need to adapt their process, working more exclusively on their specialized application components, and opening up to the idea that sophisticated, interacting, "intelligent," distributed systems are not so difficult with the right tools; and that software component reuse is taking another big jump in practicality.

HLL is also good for smaller "smart" systems. But even then, the use of standards for communication and message structure facilitates interaction with other agent systems. To roughly quote a new-age adage, the Internet becomes The application.

2.1 What is an Agent?

The term agent is very broad and has different meanings to different people. However, on close observation of the literature, it is sufficient to say that two usages of the term agent can be identified: the weak notion of agency and the strong notion of agency [37]. The weak notion of agency constitutes the bare minimum that most researches agree on, while the stronger notion of agency is more controversial and a subject of active research.

The weak notion of agency denotes a software-based computer system with the following properties [37]:
  • Autonomy: agents operate without the direct intervention of humans or others, and have some kind of control over their actions and internal state.
  • Social ability: agents interact with other agents (and possibly humans) via some kind of agent communication language.
  • Reactivity: agents perceive their environment and respond in a timely fashion to changes occurring therein.
  • Pro-activeness: in addition to acting in response to their environment, agents are able to exhibit goal-directed behaviour by taking the initiative.
The strong notion of agency is an extension of the weaker notion, and advocates additional humanistic, mental properties such as belief, desire, and intention [29].

Consistent with the weak notion of agency, one author [13] has gone so far as to say that software agents are application programs that communicate with each other in an expressive agent communication language. Though at first this definition may seem a little simplistic, it allows one to clearly identify what constitutes a multi-agent system, i.e. agents are just pieces of autonomous code, able to communicate with each other using an agent communication language. The view of agents assumed in the proposed methodology is based on this definition. Specifically, the methodology assumes the following definition for an agent:
agents reside on a platform that, consistent with the presented vision, provides the agents with a proper mechanism to communicate by names, regardless of the complexity and nature of the underlying environment (i.e. operating systems, networks, etc).
Thus, the assumed view is exactly the same as that presented in [13], but in addition, the agents have unique names as a means of identification.

This particular view of agents is the only assumption for analysis, while the design is specific to the JADE platform, which is a FIPA-compliant realization of the above vision, i.e. in the design phase, the constructs provided by the JADE platform are assumed.

13. M. R. Genesereth and S. P. and Ketchpel, "Software Agents," Communication of the ACM, vol. 37(7), 1994.

29. Y. Shoham, “Agent Oriented Programming,” Artificial Intelligence, vol. 60(1), pp. 51-92, 1993.

37. M. Wooldridge and N. R. Jennings, “Intelligent agents: theory and practice,” The Knowledge Engineering Review, vol. 10(2), pp. 115-152, 1995.

Wednesday, September 15, 2010

General Problem Solver

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

If you review the initial source-code offering (a cleaned up version of the 2007 prototype) or try the current runnable demonstrations, you may either conclude that HLL does simple things in an overly complicated manner or that it represents a good start on a grander design. It's the latter, and one of the reasons I'm writing this post is to assure you that it's not the former. But this post will end with a comment on "high level" support for a general problem solving method.

HLL has been developed in a way that makes it "open." By that I mean, you can do things with it - lots of things - even things I haven't thought of yet. That's the point. It's supposed to provide support for a broad range of applications, making them easier to build, and once the grander design level is reached in reality, more powerful than you thought your time and budget allowed. Expanding the application with increased complexity or even using your earlier work as "experts" in a larger system is going to be all the easier.

Here are some examples, and remember, you don't need to write all the code for this stuff. That's why there's HLL.

The use of an agent approach to pass messages may seem overly complicated if you're only sending "Hello World!" to another part of your application. You may wonder if you really need sockets to pass the message. If you are building to run on a local machine (Is that a lost art?), then you can set the host to "localhost" and you're fine. If you have reason to make use of more than one machine on a LAN, that works too - just set the host to a local IP address. Communicate with machines around the world - HLL is "open" to that as well - just use an IP address or host name recognizable to the outside world.

Although you can pass messages in other ways within your application code, what about the complexity of an agent's message? If you're passing messages between agent layers (actors), but your needs are simple, you can set messages up to have defaults. Your application code then only needs to specify what it needs to specify. Within the application code, it's still simple. If your need becomes more complex, the agent message standard that will be supported is "open" to allowing you to do that.

And of course, you can write as many "experts" as you wish and make them as complicated as you need - from simply command responses, to complete external systems. HLL is easy to extend into your application world.

The "Hello World!" example is a perfect case for making agent "layers" (actors) look a little silly. All three layers do something unique, but in the end, you've just typed "run" in the console (or used the browser-based GUI), to get "Hello World!" printed out. Well - if you've done much Java programming, your used to that. "Hello World!" is part of the culture - a very simple way of showing the details of how something works. Each of the agent "layers" (actors) is designed to provide a set of support functions - and (eventually) application programmers will be able to define their own actors. The basic three - executive, manager, and expert will always be supported as part of the HLL Core system (with increasing power and grace as time goes by). These three will support things that tons and tons of applications need to do and will also form the initial structure of a larger "organization." (HLL was designed by taking something from nature so to speak - then nature of human work organizations.)

The latter may not immediately seem interesting to general purpose Java programmers who tend to move around a lot. (Or maybe it does if you're entrepreneurial - read on.) Consider the fact that many companies provide software with a specialty area. I've spent enough time in more than one such company to know that various software functionality related to the company's area of specialization is sometimes repeatedly redesigned and rebuilt; something that's not supposed to happen in the age of object oriented reusable software components. Instead, you can define actors with basic capabilities commonly needed in software in that specialty area. Various products can be defined with different sets of "experts" (supported by the same actors). If you're a specialized consultant, you can do the same thing - licensing your software for resale or being paid to write new experts. If you're building something to support a company's internal operations, you can build "actors" to reflect the company organization itself. (Start by thinking about departments of operation).

Best of all - you don't need to maintain the HLL Core software yourself. Somebody else is doing that for you - keeping the technology up-to-date and making it ever more perfect. :)

There is another use of the "sufficient complexity" of HLL that I would like to mention. It's related to XML plans (on the issues list). If you've read though the old ppt presentation (available for download on the right side of this page) this should be familiar. The original HLL concept includes the idea of providing general "high level" support for problem solving. There are five steps involved:
  1. Define the Problem
  2. Collect Information
  3. Perform Analysis
  4. Identify Alternative Solutions
  5. Recommend a Solution
I'm looking forward to getting the core software to the point that I can concentrate effort directly on providing "high level" support that will make it very easy for application developers to apply this particular problem solving approach.

Follow up, see blog entry: The Ghosts in My Machine: Chapter 2


Multi-use Browser-Based GUI

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

I have already provided one blog entry on the browser-based GUI, about how it's a time killer for development but that there is a reasonable rational for doing it. Now, just a quick word on its specific design. There is actually more than a bit of thought behind it. It has survived several prototyping activities. The reason this is interesting, is that it adds to the idea that browser components can be reused - saving developers time and effort when creating new applications.

Although HLL is really separate from the browser-based GUI, it is the intent of the project to provide reusable software even for the GUI. Especially for applications built with HLL, there seems to be a good opportunity to do so - since the "high level logic" of the application is somewhat predictable. The HLL /GUI pair can even use a common general message format, perhaps based on FIPA for example, or customized to support a company or development house specialization. This idea just leans on good design practice - thinking in layers. Very general communication and processing support can be provided by the HLL GUI. Specialized organizations can extend that capability to provide reusable support for the type of software that they develop and maintain.

The use of frames provides an easy way to modify the content; simply load a different html page into the frame. Another frame can maintain state variables that will allow returning to the same state if you reload an earlier page, or provide an up-to-date state instead (or use AJAX to deliver to / fetch from server or app. - yes, HLL apps. can even incorporate typical, common, everyday ordinary request-response processing). Frames can be resized on the fly or frame content can be expanded to a separate full-screen browser window. I've also been using one frame (upper left with a logo in it) to contain the applet that accepts data pushed in from the outside. It also contains functions to channel the data to the frame.method() where it is used. The upper right frame, which displays title and menu, is what I use to store generally useful javascript functions and state information for other frames.

It can also load or reload the upper left frame(s) to control use of applets. Just to illustrate; imagine a process of switching from one human operator to another in which there is a need for both operators to be online temporarily during the change over. One could switch from a single secure URLConnection to Multicasting during the transition, giving full use to two terminals. Once the new operator is in full control, the communications link is switched back to a URLConnection at the new operator's terminal. There may be a need for multiple applets for some applications. I've typically met that need by stacking smaller frames into the same small upper left corner. (Size doesn't matter).

Here are some visualizations for robot related applications that I created when presenting the HLL concept (in the context of a robotics project) in 2006.

The first suggests use of HLL and the browser-based GUI in a mobile surveillance / security robot application (in a German airport in this illustration).

HLL browser airport security application

The next illustration suggests use of HLL and the browser-based GUI in a development tool application for robots that can learn and adapt (using genetic programming). - This comes close to the original concept GUI: with the thought of providing a tool to support development of HLL applications.

HLL browser development application

The next illustration suggests use of HLL and the browser-based GUI in a related research tool application.

HLL browser research application

The next illustration, from one of my working prototypes, shows a screen expansion to get a closer look at some XML.

HLL Browser expanded frame

HLL Robotics Demo Video

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

I've decided to release a 2007 video of the robot demonstration (which will be available for download with the new version sometime relatively soon). Let me orient you first so you know the relationship between this old video and the current project software downloads.

I created the HLL prototype during the summer of 2007 as part of a much larger robotics software project. HLL was not originally conceived as part of a robotics system, but robotics fits well within the much broader scope of potential applications. As mentioned in more than one blog post already, I originally used Multicasting to the browser, which only worked within a LAN when machines had their security adjusted to allow it. I worked in a completely different city than the rest of the project participants, so a video demonstration - just to bring people up to date and show that something was working - made sense.

The idea behind building HLL during the project was that it would be connected to the robotics software being built on the project; as the upper three layers in what would then be a six layer learning / adaptive software system for robotics. Another package became available at the time of project start that offered somewhat more mature SOA kinds of processing that HLL intended to offer (Microsoft Robotics Studio), which was subsequently used with the other robotics software. The tech. team chose to work with the other software, which had the advantage of already existing, and HLL did not get past the prototype stage.

HLL is still very interesting for robotics, imo; but also a much broader range of potential applications. Nonetheless, there's been a time skip between the 2007 prototype work, which was used to flush out design details, and where we are now. The commitment to open source happened just two months ago, and I've written in an earlier post here about the technical work that's been done since then (browser stuff has been a time killer). So there is actually, pretty good correspondence between what's shown in the video and the state of the software right now - except that the source code is now emerging well from from somewhat chaotic exploratory prototype work and taking shape as real software. (And see "Current Issues" blog post to see where it's going now.)

The robot simulator used during prototype work was very simple. It knows about the "two rooms" displayed in the browser. When a command reaches the robot simulator, it merely calculates a new position in response to the command, and sends it back. When the new position data reaches the browser, the circle (representing the robot) "jumps" to the new position. RE: "jumps", I've written about the graphics issue in an earlier blog post: "Why a Browser-Based GUI? - The Time Bandit". Microsoft is now reportedly supporting SVG and the next release of the robot demonstration should have smooth movements.

Interest in the robot application during prototyping went beyond the fact that prototyping was done in the context of a robotics software project. Two copies of HLL are used that communicate with one another. One copy operates as part of the robotics Command Center. The other is for the robot itself. Each associated HLL "application" suite is different. Each can be physically located in a different place. And there's the potential for a single Command Center to communicate with more than one robot - and for the robots to communicate (intelligently) with one another through HLL.

To get to the point of creating the first demonstration of a "smart" operation of multiple HLL, the (see Current Issues) configuration processing and XML plans needs to be completed (and although not necessary, it would be nice to have the rule-processor). I have been imagining this: The Command Center is the central facility for a many mobile robots at a logistics center. One of the mobile robots is called to join a team to unload a truck. This particular robot is either new or has been working on filling orders or some other task, and has never been involved in unloading trucks. It doesn't even know where "pier 6" is; so it doesn't know where to go to join the team. It doesn't recognize location "pier 6." All the information needed is available at the command center (or could actually be on another robot).

The Command Center issues the command to the robot; to go to pier 6 and help unload the truck. The robot recognizes that it does not know how to get to unload a truck and returns that message to the Command Center's HLL. Knowing whether or not a command is supported is one of the generic jobs of the HLL Executive. The Command Center is designed to help bring new robots into the operation and to support multiple use of robots. It fetches the software needed and returns it to the robot. (We were working on learning / adaptive robotics software, so in that context, this would even work if the only software available was not specifically designed for the type of robot being called into action.)

The robot knows how to go somewhere, but in implementation the manager finds it has insufficient information for the navigation expert to find pier 6. That information is also passed back to the Command Center, which returns an extension to the robot's map. The robot is then able to go to pier 6 and help unload the truck. {Note: This scenario is also a step toward real-time teamwork.)

OK, but that's not what you're going to see in the video. The video just provides a simple report given within the development group that gives evidence that the prototype software is running. It gives some trace information to the browser and the circle "jumps" around in the two rooms. Oh, and BTW - I did figure out why I was getting socket related error messages.

This is an asf video. It does work with Microsoft Media Player, but you might need to coax it to get it started - i.e. select Windows Media Player or open the file from within Windows Media Player. But you can try just clicking on the link and waiting for it to load. Here it is: 2007 robot and command center early prototype demonstration.

Tuesday, September 14, 2010

Current Issues

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

Once you've become familiar with what there is (btw: a quick start guide is in review), probably nothing tells you more about what you can expect in the near future than the project issues list. The Issues Tracker at, the project hosting site, currently has 11 issues logged. There are some that I do not believe will be particularly difficult to take care of, and at the same time will greatly benefit application developers. Issue #1 is a good example. XML Based Plans is critical to bringing the manager's role to what it minimally should be. FIPA compliance is quite simple, and then I'll want to apply it, even within the HLL Core (and it also makes for better applications). Rule-processing can be added by using an existing open-source package, but I'd also like to have a simple one specifically owned by and adapted to HLL.

Here's the list with short descriptions:

1. Configuration Files and Processing

Configuration files are quite important to the HLL architecture. In fact, I'd go so far as to say there should be applications built by configuring them rather than always writing new Java code for new application components. Applications should even be able to reconfigure on the fly, allowing them to add new capabilities or modify their processes and plans.

Although I've written code that handles configuration files in a pretty generic manner, I tended to define configuration files one at a time during prototype development as the need arose. The really crumby thing is that the HLL Core code explicitly looks for a particular set of configuration files on start-up. That means, that I'm carrying around a configuration file for the robot demonstration, for example, unless I change the source code so HLL doesn't look for it. That must change; and what I have planned is a master config file that tells HLL what the other config files are; and a flexible enough read and storage process to allow application developers to define their own configuration files.

2. FIPA Compliance

FIPA stands for Foundation for Intelligent Physical Agents and the FIPA organization has put forth a standard for agent messages, available here. If you thought much about the subject, a lot about it will just seem like common sense. The parts of a message include who sent it, where it's supposed to go, and other information allowing tracking of agent processing (and a message of course). The FIPA standard is well thought through and compliance provides the added advantage of facilitating communication with other agent systems.

This seems like a rather easy one at present. I just need to extend the current message object and assure that the elements are named according to the standard. The current version of the code is still small enough that necessary changes to the Java code that processes messages won't take long. Now is the time to do it.

3. Simple JSR-94 Rule Processor

There are a number of places in which rule-processing can increase the power of HLL significantly and simplify application building. The prototype uses server protocols to define the behavior of actors. Server protocols are not difficult to master. Just in case you've never written one, they tend to have if-then statements that direct processing when a message comes in to a server. A nice rule-processing system could turn this part of application building into tool-driven process. Alternatively, an open-source package like JBoss Rules (formerly DROOLS) would add a great deal of power with what is a powerful and straight-forward construction process.

But I'd still like to have at least a simple rule-processor that belongs to HLL. Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).

4. XML Based Plans

At present, an HLL manager can use resources. Resources in the form of java objects can contain plans, written in java. I want to bring at least part of this process out of coding and into XML files so that plans are easily configurable without changing source code. Note, this can also lead to an easy way of adding and modifying plans on the fly.

Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).

5. Code Review

All project members are invited to review all the source code.

6. Logging

In the prototype, most error handling consists of printing error messages to the console. When the GUI interface is involved, there is some logging supported by Tomcat. We need a better logging system.

7. HLL Server Protocol Modification

The initial issue was that the HLL Core server called an application specific protocol; which means that the Core server needed to be modified for each application. There's been a simple work-around; requiring a generically named server protocol at the top of the application's process: HLLServerThread class. I would prefer to replace that requirement with specification of the application's head server protocol named in a configuration file.

Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).

8. GUI Always Initialized

If I now tell you this has something to do with processing configuration files, you should be getting the message that configuration files are important.

9. Multicasting to browsers as option

Readers of this blog already know that I implemented Multicasting to browsers before changing to a URLConnection. Since I've already done it, this issue is assigned to me. I only need to hook it back up again, and (you may have guessed) handle whether it's used or not in configuration files.

10. General Browser GUI Issues List

This is where I'm listing issues for improving the GUI.

11. Security

Eventually, the HLL executive will need to start checking to see if messages received from the outside world come from an authorized source, and even handle encryption for some applications.

Sunday, September 12, 2010

Why a Browser-Based GUI? - The Time Bandit

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

Since the first experimental prototyping in 2007, HLL has had a browser-based GUI. It's been the most time-consuming part of development. One the one hand, there are lots of different devices out there, not just your desktop, but smart phones and PDAs and the like - in a variety of models from a variety of manufacturers with a variety of technology used. How many of those devices have browsers? Well - most. All that I own. So, I figure if I have a nice cross-browser GUI, it covers a lot of ground.

I've also done lots of interesting experimentation with SVG (Scalable Vector Graphics), which I think it great. SVG is a standard. Support is directly in the browser itself. You build SVG graphics using XML coding. Several browsers are getting close to implementing animation, which will simplify programming for (for example) the graphical robot tracking frame.

On the other hand, I must say it's been a bit painful. Especially when you're trying to do interesting things in the browser, cross-browser applications are not simple, especially if you're including MSIE. Each browser supports what its developers decide to support, and require programming applications to correspond with the functional support available. A working javascript function doesn't necessary work in all browsers. Sometimes you can discover just the right coding so that it will. Sometimes you are forced to detect browser type and support differently built functions depending on what the user is running. It's not like there's perfect up-to-date documentation for each either. Experimentation is required and sometimes you need to google around looking for someone who has posted about a similar problem and find a suggestion for solving it. (Although - if you've been around the block 20 times on all of this - I suspect it's easier.)

Microsoft hasn't been so good at supporting established public standards. It's full of exceptions. Everyone who, for example, has built a cross-browser AJAX function knows that. They are miles behind in support for SVG. There is a plug-in from Adobe that works, but it requires the plug-in to run, and Adobe no longer supports it - so it's apparently not destined to support things like animation. Microsoft has said they'll work on it themselves, but who knows?

(Turns out, somebody did know. MSIE support for SVG announced for the upcoming IE9. See comments below article for more information and links to SVG status charts for browsers.)

The SVG element is but one feature in a particular application. But I think it's an interesting one, and with care, the HLL GUI can provide out-of-the-box support that will help other applications get up and running nicely. I've implemented two different ways of pushing content to the browser and - among other things - that drives graphics animation (think of a circle moving around through "rooms" tracking the movement of a running robot). Microsoft's lack of support for animation seems a longer term problem (perhaps), while Firefox is closer to doing it. Opera is in the lead. To create smooth movement, I'm currently using dhtml. Perhaps something in that code might even turn out to be re-usable.

When I committed to open-sourcing HLL, I decided to move development from MSIE to Firefox as well as implementing a URLConnection push to the browser, replacing a very nice Multicasting version. The latter decision was based on two things. The multicasting version only worked within a LAN and required a policy and modification of the Java security file to implement the policy. Having some experience searching for open-source code myself, it seems to me that the first offering one encounters must be as simple to install and run as possible. Download - click run - not start fooling around with your Java security file. And I have no statistics on the percent of Java programmers who find it easy to create a new security policy. That could be a stopper for many. The URLConnection doesn't even require opening a port and it works from any machine anywhere without any installations or modifications or plug-ins on the client. It just works (although not as nicely as Multicasting at this point). (Note also: the Java EE version will likely use JMS.)

Firefox is of course, a very popular browser. But I also considered the state of their support for SVG. As mentioned, they are behind Opera. It seems to me that playing to the most advanced doesn't really help me build something that most browsers can run. Given that Opera is currently more advanced in their support for SVG, one can proceed with the idea that if it works on Firefox, it will probably work in Opera (even if it takes a little tinkering). Of course, then there's MSIE. Since I already have experience with MSIE, I'm familiar with the limitations of the Adobe plug-in. For MSIE, the application will need to detect browser and reload the frame with the customized MSIE page. Since I built first with MSIE, I'm just a hop, skip, and jump from completing that task when the time comes. (Will be great if I don't need to.) With tinkering, the dhtml smoothing function should work for MSIE as well.

Now here's the painful thing. I'm at the beginning of this project, coding everything myself, while getting the open-source project up and running and now - to keep my schedule - I need to start "marketing" the project and trying to draw some interest. There are now 11 issues posted in the issue tracking system, each of which will enhance HLL considerably on completion. This browser stuff has taken up a lot of my time for adaptations more than gains.

Of course there are frameworks. But I'm spread pretty thin. I've nothing against learning new frameworks - believe me. I'm asking people to learn about mine. It's partly just a matter of time, but also consideration for simplifying the original offering. "Just download and try my code. It's easy." instead of "download, install, learn to use 14 other different packages" kind of thing. (I'm thinking about how to handle this in the future - because there's a lot of good stuff out there that would be useful as add-ons ... I'll likely write about some of them in this blog later) As for time and using a cross-browser framework, no one person can know everything. I don't know at this point - perhaps in hindsight, the time might have been better spent learning a framework rather than doing everything myself ... but the results always seem just one more solution away.

Anyway - the Firefox version seems to be working now, for the most part. I still need to get the dhtml for smooth movement working in context. Then I can get back to enhancing the Java .... HLL itself ... which should produce gain much more quickly. Of course, now I do have a new list of things to do - since my schedule says the open-source project should be underway.

Planning a Tutorial

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

I have also started a Facebook group called "High Level Logic (HLL) Open Source Project." Eighteen people joined within the first 24 hours. Several appear to be Java programmers, or at least seriously interested in software. One asked if I could provide a very simple how to example so that he could see how exactly one goes about building an HLL application. Of course - that was a very smart question. There should be a simple "Hello World!" (or better) tutorial showing just what one does to build a working application.

A few Facebook messages later, and there's a general outline for a nice tutorial. I will work on it this coming week - but I still would like to tackle at least one of the issues on the current issues list before doing that. I'll report back on that later. Anyone who ventures far enough into the project to understand the code and review the issues on the list may want to know what's coming soon and how that will effect development.

Friday, September 10, 2010

First Post

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

This blog is being started for the High Level Logic (HLL) Open Source development project that is housed on Yes, for those of you who have not been there, there is a website named This is not an mistake in which I've accidentally mentioned Java programming resources for networking. If you're interested in open-source, you should sign up for a free account. Although they explain that the site hosts open-source projects involving development in many different languages - I still have the impression that it's Java oriented. Maybe people just got that impression from the name of the site - which is after all, Started by a small group of Sun employees, I'd guess their thought was to advertise the fact that the site technology itself is very Java oriented - but I am assured that they are willing to house non-java projects.

I'm rather new to the site myself, and to its resources, and was actually attracted to it because it's called High Level Logic (HLL), which I will be discussing in following posts, is written in pure Java. The first offering is a very light-weight prototype written entirely in Java SE (formerly known as J2SE). But there is already a description of an advanced version using Java EE (J2EE) and integration other open source assets.

Even though HLL is not described yet in this blog, I'll point you to an article that mentions the concept (happens to be about robot ethics, but HLL is a general purpose framework) and to the project website on

BTW: The company mentioned in the article, iRobis, no longer exists. Contact me directly if you have any interest in HLL or the robot learning software.

2BTW: To access a project on, you must first sign up for a account, then contact the project owner for permission to access the project.

Article: Brainstorm Responds to Robot Ethics Challenge
Open Source Project: High Level Logic (HLL)