Why voice? Business communication is mostly about paperless paperwork, right? Computer workers like you and I stare intently at the computer screen for long hours, and by the end of the day are ready to kill the computer.

“A picture is better than a thousand words” applies only when it is not a picture of a thousand words that we read on our computer screens every day. Voice components bring some relief to our eyes and allow us to listen to text pages and even to talk back. (We talk more about speech recognition systems in Chapter 12.)

This chapter is about integration with voice components based on free, downloadable Java libraries. Voice components make even more sense in devices with small screens, or no screens at all.

The news watch is an example in which the voice component would be highly appreciated. Imagine a talking watch that delivers the news. Someone could use the screen option in a crowded place and the voice option in a better environment—for example, outdoors.

We add a voice component to the news watch at the end of this chapter. Right now, we take a closer look at synthesis technology.

WHAT IS THE BASE FOR CREATING A VOICE COMPONENT?

The free text-to-speech (FreeTTS) library was built by the Speech Integration Group of Sun Microsystems Laboratories as the first, though not complete, implementation of the Java speech application program interface (JSAPI) [1].

This chapter turns the smallest Java Virtual Machine (JVM) running on a smart card into a powerful key that can open all doors.

WHAT IS A SMART CARD?

Imagine a regular plastic card (often called “plastic”) with either a microprocessor and/or a memory chip embedded into the card. The microprocessor can manipulate information on the card, whereas a memory chip (e.g., the one in a prepaid phone card) can undertake only a predefined operation performed by a card reader.

Smart cards, unlike magnetic-stripe cards, do not require remote access at the time of the transaction; they can carry all the necessary functions and information right on the card. Today, there are three categories of smart cards: microprocessor, memory, and optical memory.

Microprocessor cards have an 8-bit processor, 16 KB of read-only memory, and 512 bytes of random access memory. Their processing power is similar to the first personal computers. These cards can perform cryptography algorithms and are used to access, hold, and otherwise manage digital money; provide secure access to computer and phone networks; secure set-top boxes; and perform other functions.

Memory cards, which can hold up to 1 to 4 KB of data, represent the bulk of the 600 million smart cards sold last year, primarily for prepaid, disposable card applications like prepaid phone cards. Card readers (also known as card-accepting devices) perform fixed operations (e.g., add, subtract, and delete) on memory cards.

Optical memory cards have a piece of (optical) compact disk glued on their surface. Up to 4 MB of data can be stored on the card, once and forever.

This chapter is about speech technologies and related APIs: VoiceXML, SALT, Java Speech API, and MS Speech SDK. It looks into unified scenarios with audio/video interface (AVI) definitions, considers design and code examples, and introduces important skills for a new world of wired and wireless speech applications.

WHAT IS A NATURAL USER INTERFACE?

Is a natural user interface (NUI) another set of tags and rules covered by a nice name? Absolutely not!

This time, end users—not a standards committee—make the determination on what they prefer for their methods of interaction. An NUI allows end users to give their preferences at the time of the service request, and to change them flexibly.

Are you a “computer” person?

My guess is that you are, because you are reading this book. “Computer literate” folks like you and me enjoy exploring the capacities of computer programs via traditional interfaces. Even so, there are times, such as when we are on vacation, on the go, and in the car, when we prefer “hands-free” conversation rather than using keyboards to access computerized services.

One person prefers handwriting, and someone else is comfortable with typing. One would like to forget keywords and use commonsense terminology instead. Can a computer understand that “find” is the same as “search,” and “Bob” is actually “Robert”? Can it understand that someone has chosen a foreign (non-English) language to interact with it?

“Write once and run everywhere” is one of the most important promises made by Java technology. Java Virtual Machines running on different platforms support this promise. With Microsoft's .NET initiative also you can write a program in C, C++, C#, Visual Basic, Perl, and so on. Then you can convert the program (with Visual Studio .NET) into the Microsoft intermediate language (MSIL) binary code that can be executed on any Windows platform by a virtual machine called the Common Language Runtime (CLR).

Unfortunately, the problem has many sides, and no technology by itself can help in every direction. Again, this is about the right development process coupled with the right technologies. What are the factors, other than language and compatibility problems, that prevent us from writing once?

When we try to use an existing service or application with a new environment, we find out that it does not fit. When business requires change and we want to adapt an existing product to that change, we find that there are no adaptation mechanisms in place. We realize that the basic properties, methods, and operations of the application are too specific to and too tight with the existing environment. The product has to be redone, often from scratch.

This chapter reveals the dependencies between a natural user interface (NUI) and knowledge technologies; discusses architecture, design, and code samples that integrate knowledge technologies into enterprise applications; and gives the keys to a new breed of software— “Softology,” a mix of software and ontological engineering.

We talked about NUIs in the previous chapter and agreed that they are not a trivial pursuit. We discussed at length a small part of an NUI—current speech technologies—and ended up with the conclusion that they can do a decent job when using machine-directed dialogs with multiple choices but are not quite ready to understand natural language spoken by a person.

We face similar difficulties with machine translation from foreign languages. I worked with multiple language translation programs that produced nonsense text filled with the right words.

WHY ARE COMPUTERS STUPID? WHAT IS MISSING?

Can tasks such as machine vision, speech recognition, and foreign language translation, which all seem very different, have a common solution?

The first common denominator is easy to find: all these tasks belong to the field of data interpretation. The next move is to find common steps for all three activities. What do people do when they are engaged in image or speech recognition, when they translate text from Hebrew to English? Why can't we build a program to perform similar steps?

The very first step is to recognize a business (social) domain area in which the data belong.

SOFTWARE ARCHITECTURE—THE CENTER PLACE OF SOFTWARE DEVELOPMENT

Software architecture is the highest level of a software system definition that can include subsystems with their own architectures. The main question is how deep one should go into the nested abstractions to define software architecture. The general answer is to stop right before implementation details that can be considered “private” parts of the design. More visible and exposed “public” containers, components, and connectors of the system with their run-time behavior and relationships comprise software architecture.

Software architecture has its own worlds of “what,” “why,” and “how”. The what world is mostly inhabited by industry standards, tools, and modules. The how world is about development process, design patterns, and architectural styles. The why world is a map between requirements criteria and the worlds of what and how. Design patterns [1, 2] and architectural styles [3] are very close by their nature but different in their scope and manners. Both are symbol names and concepts that describe approaches to common development problems.

Multiple architectural views work as light projectors helping us to see the systems from different sides by eyes of different parties interested in the product.

ARCHITECTURAL ELEMENTS, STYLES, VIEWS, AND LANGUAGES

Most of today's enterprise applications are built with object-oriented architecture, in which system components encapsulate data and behavior and communicate via messages.

Components, containers, and connectors are basic elements of the architecture.

In this appendix, you will find practical examples of how to:

• Start a collaborative service

• Read/write geographical data

• Use Java Naming and Directory Interface (JNDI) for multiple types of data sources, including domain name servers

• Share a screen with multiple users (great for troubleshooting and demos!)

• Use Java Media Framework (JMF) and Java Message Service (JMS)

• Create speech recognition and text-to-speech (TTS) applications in C#

• Spam and Spam Killers

• Improving efficiency and reliability of your email server

• Create a distributed knowledge systema and join educational/knowledge alliances.

These are the main targets, but the list can go on and on. You will find basic source examples in this appendix, and you can download more from this book's support Web sites at Cambridge University Press (www.cup.org/titles/ 0521525837.htm) and ITSchool, Inc.(www.JavaSchool.com).

GETTING INTO COLLABORATIVE SERVICES

Ben was always good with computers; some cosmic adventure games even followed him in his dreams. He was also very open to sharing or (using the impressive word) “collaboration.” He opened his first collaborative Web site when he was very young. He often had to stay home sick, and the site helped him to keep in touch with his kindergarten class. All his teachers and friends received his invitation-links to the site, except for Peter, a boy who never shared his piece of cake with anyone.

This appendix is a reference to Java, including the JDK1.5 and C# languages. In previous chapters, we discussed integration-ready and knowledge-connected environments that allow for writing application scenarios. In spite of the fact that most examples that support this method are made in Java, similar environments can be created with other languages. Life outside of Java is not as much fun, but it is still possible.

This appendix provides examples in which the same function is implemented not in Java but in its easiest replacement—the C# language.

This lucky child inherited good manners, elegance, style, and even some clothing from its stepfather while enjoying its mother's care and her rich, vast NETwork.

Java and C# are similar in their language structure, functionality, and ideology. Learning from each other and growing stronger in the healthy competition the siblings perfectly serve the software world.

JAVA VIRTUAL MACHINE AND COMMON LANGUAGE RUN-TIME

Java compilation produces a binary code according to the Java language specification. This binary code is performed on any platform in which a Java Virtual Machine (JVM) is implemented. The JVM interprets this binary code at run-time, translating the code into specific platform instructions.

C# compilation (through Visual Studio.NET) can produce the binary code in Common Intermediate Language (CIL) and save it in a portable execution (PE) file that can then be managed and executed by the Common Language Runtime (CLR).

Collaborative engineering is an important subject that is currently missing in schools, although some courses include a few of its aspects. I doubt I can cover it all at once, but I will try my best to integrate development technology and the development process under one roof, where integration-ready systems can be created.

Technology tends to fragment: to focus on pieces and omit the glue. The development philosophy that I associate with the terms of collaborative engineering helps keep a better balance between a narrow focus on particular components and their multiple connections to the rest of the world. The practice of collaborative engineering also assists in establishing a repeatable—yet flexible and constantly improving—development process. This is the foundation for integration-ready systems development.

What is collaborative engineering all about? It is about the development process in its organization, management, and methodology, integrated with innovative development technologies. I have had the privilege of teaching corporate developers and architects in the United States and overseas. Many times, I have had the amazing feeling that some of my brightest students, experienced developers, knew all the pieces of the puzzle and still could not start putting them together.

For example, almost every programmer knows one of the main design rules: Separate business from presentation logic. However, there are still more cases that break this rule than cases that follow it. One of the hardest questions is how to apply the rule properly.

One might think that the software industry is performing very well because it is armed with object-oriented approaches, Web services, Java and NET technologies, and so forth. Unfortunately, this is not true.

There may be something wrong with the way we write programs. The process has not changed much during the past twenty years, except that applications and tools are getting bigger. Yet are they better and more scalable? Do they require any common sense? Can they be reused in different circumstances?

If these things were true, I do not think we would be rewriting the address book, schedule, order, and inventory applications over and over again instead of moving to new, untouched tasks. We would be able to accumulate the professional knowledge gained by millions of knowledge workers (everyone who manages information flow on a daily basis) instead of routinely losing it, as we do today. We would also not be facing the current IT crisis.

We could even have had more precise and direct access to the market's supply and demand, which would have reduced the glaring inefficiencies of the software marketplace of the 1990s. A big change is required to return investors' confidence to IT, and, hopefully, the change is coming.

Yes, technology can help economic stability if applied with precision. Sometimes I wonder why big companies are constantly growing bigger while small ones tend to disappear.

This chapter is about existing and upcoming client–server paradigms in communications, the distribution of computing power, and effective programming with reusable code that can be run on both sides of the client–server pair.

The past decade of client–server development turned to the server part of this happily married couple. The biggest software giants are in a hurry to translate desktop applications into Web services leased or sold on a pay-per-use basis.

This work, begun several years ago, was based on several assumptions:

1. Client networks will improve/upgrade faster and more cheaply than client computers.

2. HTTP-based Web technology will be able to provide all or most of the requested services.

3. Centralized data and services will benefit clients and service providers.

Unfortunately, not all of these assumptions happen to be true.

1. Computers and PDAs are much more capable and cheap today than they were several years ago, whereas digital subscriber line (DSL) and cable modems are still the same price, with no miracles to show for it.

2. One of the biggest requests for Internet services, streaming data, requires protocols other than HTTP and lies outside of Web technology. (This is just one example; applications with asynchronous natures are also not comfortable with HTTP limitations.)

3. Groups of clients are unhappy with the centralized service concept. For security reasons, they prefer peer-to-peer or similar communications.

4. […]

Ontology is a controlled, hierarchical vocabulary for describing a knowledge system or knowledge-handling methods.

This chapter is an introduction to a development paradigm in which software and knowledge engineering are integrated. As always happens on the other side of an economic crisis, a new set of skills will be required. A growing number of developers will actively use the knowledge technologies reviewed in this chapter.

The chapter starts by talking about fundamental standards that currently bridge ontology and engineering: the Resource Description Framework (RDF), the Semantic Web language DAML+OIL (DARPA Agent Markup Language + Ontology Inference Layer), Topic Maps concepts, and their XML Topic Maps (XTM) standard knowledge exchange format.

We'll continue with a brief overview of data-mining methods with coming Java support and eventually discuss the challenging topic of generic knowledge, not just knowledge of a specific business domain, expressed in natural language. The final part of the chapter describes OpenCyc, probably the most exciting knowledge instrument today, and provides examples of using the CycL language and OpenCyc engine in distributed knowledge systems.

I hope this chapter does not take you, my reader, by surprise. Integration-ready systems and collaborative engineering need and help create knowledge technologies, which create a very healthy cycle.

A customer with a computer and computer skills is still the main target for computerized services today.

Even when searching Google.com for a specific topic, you need to know the specific terms of the industry this topic belongs to.

This chapter introduces Wireless Markup Language (WML) and provides examples of programming wireless applications using presentation factories.

Wireless Application Protocol (WAP) devices include WML browsers that can display some content described in WML and WMLScript, which is part of the WAP specification. WMLScript can be used to add programming support to the client. It is similar to JavaScript and can be used in a similar manner. You can use WMLScript to validate user input, but most importantly, you can use it to generate messages and dialogs locally, so error messages and confirmations can be viewed faster.

It is also possible to access facilities of the user agent; for example, WMLScript allows the programmer to make phone calls, access the SIM (subscriber identity module) card, or configure the user agent after it has been deployed. (Keep in mind that data and voice are separate.)

Memory and CPU resources are limited and often prohibit the use of WMLScript, although WMLScript may be necessary to program proprietary telephony features for specific devices. For example, some devices allow your program to:

• Send DTMF (Dual Tone Multi-Frequency. The technical term describing Touch Tone dialing with combination of two tones, one low frequency and one high frequency.) tones

• Modify the device's phone book

• Use the phone book to start voice call or reject a call

Note that such programs would hardly work for a variety of models. The compatibility problem is one of the serious problems WAP developers face.

This chapter is a brief overview of the basic principles and standards driving the world of wireless applications.

Unmatched opportunities in the mobile and wireless areas are attracting the attention of business and development. Wireless markets, including personal area networks (WPAN), local area networks (WLAN), and wideband local-area networks (WWLAN), have an estimated value today of several billion dollars according to the Gartner Group (http://www.gartner.com/5 about/pressreleases/pr11mar2003a.jsp)

According to Gartner, increasing focus on teleworking and corporate mobility to improve enterprise performance, and trends such as the move toward the real-time enterprise, will not merely exploit mobility but will demand it. At the same time, the relentless push by vendors, virtually giving away wireless capabilities with significant price/performance improvements, is fueling demand for wireless technology in the corporate marketplace. United States federal regulators are expanding the radio spectrum for wireless internet users to help bring broadband connections to rural areas.

The number of wireless devices on the Internet is growing fast. The stock of IP addresses is now almost exhausted, so it is about time to extend the Internet with Internet 2, which replaces the current IPv4 protocol with the latest IPv6 protocol and drastically increases Internet capacity and improves Internet security.

A great competition for multiple markets, running different wireless technologies, has just begun. The winners will be those wireless Internet service providers (WISPs) and wireless application service providers (WASPs) that can offer connection and content services and optimize development solutions with a unified approach across multiple client devices.

Who Should Read This Book?

Integration-Ready Architecture and Design strives for a union of theory and practice. Teaching the latest wired and wireless software technologies, the book is probably the first entry into “the next big thing,” a new world of integrated knowledge and software engineering. Written by a software architect and experienced trainer, this book is for:

• Software architects, designers, and developers

• Internet and wireless service providers

• IT managers and other IT professionals, as well as amateurs

• Subject matter experts who will directly participate in a new development process of integrated software and knowledge engineering

• Students and educators, who will find up-to-date materials for the following courses:

1. Software Architecture,

2. Software Engineering,

3. Programming Concepts,

4. Information Technologies,

5. Smart Card and JavaCard Technologies,

6. Wireless Technologies,

7. J2ME and Wireless Messaging,

8. XML Technologies,

9. Speech Technologies,

10. Java Language and Technology,

11. C# and Net Technology,

12. Integration Technologies,

13. Business Communications and Collaborative Engineering,

14. Web Technologies,

15. Introduction of Ontology, and

16. Integrated Software and Knowledge Engineering (introduced in the book)

• Peers: students, instructors, consultants, and corporate team players who might start using a peer-to-peer educational tool offered in the book as their entrance to the distributed knowledge marketplace

• All of the above who want to know how things work, should work, and will work in the IT world.