Friday, May 26, 2006

AJAX and SOA at JavaOne: JackBe leading the charge

http://www.codefutures.com/weblog/

The three hottest topics at JavaOne seemed to be AJAX, SOA, and data persistence. Almost everyone I met at the conference was interested in at least one of those three technologies. So I went to the panel discussion on "Java Technology, AJAX, Web 2.0 and SOA". There were many sessions on AJAX, but the speakers at this included Deepak Alur and Dan Malks, who wrote the Core J2EE Design Patterns book on which FireStorm/DAO is based.

Dan Malks did a straw pole of attendees about why they came to the discussion that produced some interesting results. About half the developers were there were interested in AJAX and about half were interested in SOA. There seemed to be a bit of confusion around the term Web 2.0, perhaps given the developer-centric nature of this crowd and the term's marketing roots.

Since I did not know too much about AJAX before JavaOne, I decided to take a tour of the vendor pavilion to look at all the AJAX products available. Most of them were surprisingly primitive (I will not name the vendors - the list is available on the Sun site). They were just raw technology. What they were missing was a simple development environment to quickly and easily build top-end user interfaces.

The one exception was JackBe. The demo provided Jacob Derechin really blew me away. He was able to build stunning looking, highly interactive Web interfaces that better than I ever imagined possible.

What makes JackBe even more interesting is that they are not content to have the best AJAX technology and they are also combining AJAX with SOA-based back end technology to provide a full end-to-end offering using SOA standards and AJAX. That's completely unique in the marketplace.

I wonder if CodeFutures should provide an AJAX-based user interface for FireStorm/DAO and FireStorm/SDO?


PJ Murray
CodeFutures Software

Where Do the Benefits of Ajax Come From?

Where Do the Benefits of Ajax Come From?
Measuring the Benefits of Ajax
By Alexei White


Often, in business, decision makers are interested mainly in how information technology can reduce costs, or make better use of information assets. The benefits of Ajax seem to come more out of the cost-containment arena than the latter. The question becomes "Where do these cost savings come from and how can we quantify them?"
1. Potentially Measurable Benefits

These are benefits that can be measured and expressed in terms of dollars and cents without much difficulty. Regardless of the quality of your Ajax UI, you will look to these metrics to estimate value. They include:

1. Time spent waiting for data to be transmitted: Time is money. Over many repetitions, the time employees spend waiting for the page to load can add up to significant costs.
2. Time spent completing a particular task: Increased efficiency in the user interface can often mean that time is saved at the task level, offering opportunities for concrete cost savings there.
3. Bandwidth consumed for the entire task: The cost of bandwidth does not increase linearly, but does increase as the company invests in larger-capacity Internet connections and new hardware to accommodate greater server loads. A firm's cost structure for bandwidth depends on the scale of their operation and these capital investment needs. That being said, the cost of bandwidth can be measured if this cost structure is known. If repetitious tasks consume a lot of bandwidth, these costs can escalate dramatically. The amount of bandwidth consumed also has implications for time savings.

Tuesday, May 23, 2006

Ajax is the talk of JavaOne

By Rich Seeley, News Writer
22 May 2006 | SearchWebServices.com

SOUND OFF!Post your comments



San Francisco - Since Java is part of Ajax's middle name, it was not surprising that the rich user interface was a hot topic, perhaps even the hot topic at JavaOne in San Francisco this past week.


Ajax does give you the power to develop very bad user interfaces.
Tim Bray
Director of Web Technologies, Sun




All the major Java platform vendors at the show, Sun Microsystems Inc., BEA Systems Inc., IBM, JBoss Inc. and Oracle Corp., were touting new found Ajax capabilities. Three smaller Ajax tool vendors -- BackBase B.V., ICEsoft Technology Inc. and JackBe Corp. -- were hawking their wares on the show floor.

Some of the big vendors may partner or, in the Darwinian world of software, swallow up the little Ajax companies.

Bill Roth, vice president of the BEA Workshop Business Unit, said his company has been impressed with the Ajax development framework from BackBase. He said BEA is working together on some implementations in the Netherlands, where BackBase is based. Roth said the two companies are in preliminary discussions about partnering, so the BackBase Ajax development tools might soon be bundled with BEA Workshop.

Not everyone at JavaOne was wild for Ajax, however.

Tim Bray, XML pioneer and director of Web Technologies for Sun, said Ajax might be wielding a double-edge sword.

"The clamor around Ajax is about the richer user experience," he said. "That's kind of a two-edged sword. We used to have a richer user experience in the days before the Web with Visual Basic and people stampeded into the arms of a simpler user experience with the Web browser as soon as they got a chance."

Bray's concern is that the rich UI could become a techno-bauble heavy UI that might leave end users dazed and confused.

"Ajax does give you the power to develop very bad user interfaces," Bray cautioned.

On the plus side, he said Ajax can make Web applications run faster for the end user by eliminating the back and forth between the Web browser and the server.

"Obviously a user interface that is faster is categorically, unqualifiedly better," Bray said. "If that's the only contribution Ajax makes that would be plenty big enough."

Bringing desktop-like speed and responsiveness to Web applications is the selling point for all the Ajax vendors, but approaches vary.

In the relatively new world of Ajax technology, BackBase is one of the older vendors having opened for business in 2003 to create a richer UI with JavaScript, said Jouk Pleiter, co-founder and CEO. Recognizing that JavaScript was not the easiest scripting language to work with, the company developed tools that allow developers to create Ajax interfaces without getting into what he terms the JavaScript "plumbing issues."

"If you look at JavaScript in general, it's a very complicated language to program in. It is difficult to get it consistently behaving across multiple browsers and that is exactly why a company like BackBase exists," Pleiter said. "So, actually what we do is we say, JavaScript is great, you can create a very attractive interface with it. It's a rather complicated programming environment so we've tried to hide the complexity of JavaScript."

While some tools aim at the UI developers who work with scripting languages, ICESoft provides tools aimed at enterprise Java developers who work on the server side. In the ICEsoft booth at JavaOne, Ken Fyten, product manager for its ICEfaces tool, demonstrated its drag-and-drop capabilities working inside Sun's Java Studio Creator. Buttons and calculator objects can be moved into place with the code generated automatically, so there is a minimum of code writing and editing.

With the logic residing on the server, Robert Lepack, vice president, marketing at ICESoft said the ICEfaces approach avoids overloading the browser. "The Web services run on the server and only send snippets to the browser," he said. The server-centric approach extends to a feature ICEsoft calls "Server-Initiated Rendering," which automatically and asynchronously updates the browser when data, such as a stock price or an online auction bid, changes on the server.

The JackBe NQ Suite of tools takes an enterprise SOA approach to Ajax, said John Crupi, CTO, who came to JackBe from Sun where he had been working on SOA technology. The JackBe approach was to take lessons learned in SOA and apply them to extending SOA with Ajax as "an enabling technology."


For more information
How Ajax conquered the Web

Georgia maps future with Ajax




"One of the problems that SOA had was that initially people were building Web services in SOA architecture from the bottom up," he said. "So they took an inventory of everything they had and said, let's just make this a Web service and we're SOA. But guess what? It was never designed for that level of granularity. So, next round they got smart and started doing them more top-down and basically aligning with the business units and asking what does business need and what are the applications and that drives the definition architecture of your SOA backend."

In its short life Ajax has followed the same trajectory in the developer learning curve, in Crupi's view.

"You can build a page and sprinkle Ajax widgets, but if you're actually going to build a full-blown mission critical application for businesses, you have to think of the end-to-end architecture," he said. "So we just see Ajax as a natural extension and alignment to the backend enterprise, also highly aligned with SOA. It allows you to create applications, but it's purely just an enabling technology, Ajax, it's not a solution in and of itself."

Thursday, May 04, 2006

The SOA Killer App ZapFlash

By Jason Bloomberg
Document ID: ZAPFLASH-200653 | Document Type: ZapFlash

Back in 2003, when ZapThink wrote our SOA Tools and Best Practices report, we first encountered a problem that we hadn't seen when we wrote our Web Services Security, Service-Oriented Management, and XML Appliances reports. The problem we ran into with our SOA Tools report was that the market was so immature that there weren't any tools specific to Service-Oriented Architecture (SOA) available yet. In that report, we explored a number of related tools markets, to be sure, including modeling tools, rapid application development tools, integrated development environments (IDEs), business process modeling/management (BPM) suites, and more -- but no vendor had yet developed a tool specific to the tasks inherent in implementing SOA.
In the intervening three years, SOA tools have matured significantly. Tool vendors have made substantial progress building SOA-specific products, to be sure, but even now the SOA tools on the market are still limited in their capabilities. We've recently seen some model-driven declarative application tools, a healthy crop of policy management/governance tools, the recent emergence of Service-oriented business application (SOBA) composition tools, and even some SOA-specific testing products, to name a few. But the market has still not delivered a single product that brings together all of the capabilities we called for in our 2003 report into a single, Service-oriented tool.

We don't mean to fault any of the SOA tools vendors out there, because after all, the market is only now beginning to demand the SOA tool that we're calling for. If such a product had existed in the market in 2003, it would have been too far ahead of existing demand, and its vendor might have found itself lacking sufficient runway to continue development until customers were ready for such a product. Today, however, the demand for such a comprehensive tool is emerging, and the requirements and characteristics of this sort of tool are now becoming clearer.

Furthermore, by exploring the necessary capabilities for SOA tools, it's possible to get a better picture of what it means to be an application in the Service-oriented world. It's important to realize that the sort of tool companies require to build Service-oriented applications is not a simplistic extension of the concept of an IDE to the world of Web Services, such as Gartner's ill-fated "Integrated Service Environment" idea of a couple of years back. Instead, we're describing a new kind of tool that is itself a new kind of application -- a tool that promises to disrupt the current tools space and define a new market in the process. There's a term for such applications that so radically redefine their market -- a killer app. This ZapFlash, therefore, focuses on what we'll call the SOA Killer App.

SOA Killer App as Modeling Tool
The SOA Killer App must first and foremost be an architecture tool, naturally, since SOA is first and foremost architecture. The central architectural model of SOA is the Service model, which is an abstract representation of both the Services in production as well as the requirements for new or modified Services. The SOA infrastructure then actualizes the Service model with contract, policy, and other metadata that allow for the declarative configuration the Services over time.

The SOA Killer App must therefore be a modeling tool -- but not a typical design time modeling tool. Rather, in SOA, it's essential for architects to maintain the Service model at runtime and change time as well, and thus there must be a feedback loop that connects the management environment with the models in the tool. Enterprise architects, among others, will use the SOA Killer App during all phases of the Service lifecycle.

One reason the SOA Killer App is so elusive is that many people struggle with the concept of models, because models are abstract representations, but nobody says what that abstract representation is supposed to be. Should it be a flowchart in an application? A UML sequence diagram? A description written in a natural language? Maybe a set of rules? In fact, these representations are among many possibly appropriate representations, depending upon the person using the modeling tool and the particular task at hand. The SOA Killer App should be able to switch seamlessly among any such representations to afford the greatest flexibility to the greatest number of people within the organization.

SOA introduces another wrinkle to the traditional modeling tool concept. Since Service-oriented processes are composed of Services and exposed as Services, the SOA Killer App must also provide BPM capabilities, as well. It must handle well-defined orchestrations that consist of sequences of process steps with predefined flows, as well as more ad hoc processes defined as choreographies that only specify preconditions and postconditions for interaction in a non-programmatic manner. The SOA Killer App should support the declarative nature of the SOBAs it models, and it must automatically maintain an accurate representation of the processes in production, even as they undergo changes.

Soup to Nuts SOA Lifecycle
The SOA Killer App is far more than a modeling tool, however. It must provide flexible, diverse capabilities for all members of the SOA lifecycle team, including Service-oriented (enterprise) architects, technical architects, business analysts, Service developers, Service consumer developers, information and data architects, quality assurance personnel, the operations team, as well as the support staff. Each of these roles has different responsibilities and expectations for the tools they use, and the SOA Killer App must provide the appropriate capabilities for each person on the team.

With such a diverse and powerful set of capabilities, however, comes the increased risk of people really mucking things up, either accidentally or intentionally. To mitigate such risks, the SOA Killer App must also provide core governance capabilities. Governance, in fact, is one of the hot button issues in SOA today. Comprehensive governance capabilities include the creation and communication of corporate policies, as well as tools for following and enforcing those policies, gaining visibility into the levels of policy compliance, as well as an approach to mitigating any deviations from policy. For the SOA Killer App to provide broad capabilities for a diverse team with varied responsibilities, the tool must support the policy creation, management, and enforcement that today's SOA governance tools provide. In the Service-oriented context, companies will want to handle governance declaratively, just as they want to handle business process and Service configuration. The SOA Killer App must therefore provide the capabilities that policy managers require, and must even allow for the creation of meta-policies -- the policies in an organization that apply to the creation, communication, and enforcement of policies.

The Mother of all Dashboards
the visibility into policy compliance companies require for effective governance is only one small part of the visibility requirement that companies have today. As companies adopt SOA as their enterprise architecture, all forms of visibility into the data in the organization as well as the workings of all parts of the IT environment will fall under the core Service abstraction that underlies SOA. The SOA Killer App will therefore roll together all of today's various dashboards, including system management dashboards, business intelligence applications, information technology service management (ITSM) and business service management (BSM) tools, identity and access management (IAM) dashboards, and more.

Today, the word "service" has different meanings in different contexts, but as SOA becomes prevalent, these various definitions of service will converge. No longer will the various dashboards in the organization present siloed data in a siloed manner. The SOA Killer App will bring them together, provide new approaches for combining the knowledge each one provides, and enable various people within the organization to take action on the information they glean from this improved dashboard. In fact, the SOA Killer App will replace the traditional, inflexible portal altogether over time.

The Universal Service Consumer
Browser interfaces like those of today's portals are only one example of the wide variety of Service consumer applications people are using to leverage the capabilities of Services. As today's software vendors increasingly leverage the power of SOA in their consumer products, however, it will become clear that many of today's diverse applications are examples of a single, broad class of consuming application, including desktop applications like spreadsheets, business process tools, and Rich Internet Applications (RIAs). What, after all, makes a desktop app different from a RIA? Today's desktop apps almost universally access the Internet, and the RIAs people are now building with technologies like asynchronous JavaScript and XML (AJAX) and Flash can do everything a desktop app can do. A glimpse into the inner workings of Windows Vista shows how blurred the distinction between desktop apps and RIAs is becoming, and the Java and open source worlds are keeping pace. Soon there will be no salient difference.

There is something much more fundamental going on here than the rise of AJAX and other technologies for building a wider variety of applications. Remember, in the Service-oriented world, applications are compositions of Services built declaratively using tools like the SOA Killer App. The fact that technologies like AJAX, Flash, and Java Server Faces allow us to leverage a page metaphor, a streaming media metaphor, or a rich application metaphor whenever appropriate breaks down the walls between one application and another, and even makes it impossible to count the number of applications in any situation. If every Web page is an application, and stringing several Web pages together is also an application, then what is an application, and how many applications do you have?

The ZapThink Take
If tomorrow's application is basically an enterprise mashup, which is a flexible composition of Services in the context of a governance framework, then what about the SOA Killer App itself? Yes, it's an enterprise mashup as well. There will never be just one SOA Killer App, since after all, the idea of having a any particular number of applications is no longer a relevant concept. We spoke of the SOA Killer App as containing modeling and development capabilities, a wide range of dashboards, and the capabilities of every Service consumer under the sun. But that doesn't mean that you'd expect to buy such a thing as a shrink-wrapped package from a single vendor. Instead, the SOA Killer App enables the creation and evolution of itself as a composition of Services -- an enterprise mashup tool that is itself an enterprise mashup.

This profoundly bootstrapped nature of the SOA Killer App is perhaps the deeper reason we haven't seen one on the market yet. After all, the first one cannot be built with itself, but rather with more traditional tools. Once the first SOA Killer App hits the market, however, then companies will be able to use it to evolve what it means to be a SOA Killer App. At that point, the tool will truly be a killer app, in that it will transform the market it participates in, along with what it means to be an application.

Wednesday, May 03, 2006

Yahoo Launches Soul-Search Engine

The Onion, April 7, 2004 | Issue 40•14

SUNNYVALE, CA—Hoping it will push them to the top of an increasingly competitive market, Internet portal Yahoo has added soul-search capabilities to its expanding line of search tools, company executives announced Monday.

"Capable of navigating the billions of thoughts, experiences, and emotions that make up the human psyche, the new Yahoo soul-search engine helps users find what's deep inside them quickly and easily," Yahoo CEO Terry Semel said. "All those long, difficult nights of pondering your place in this world are a thing of the past."

Yahoo's main competitor recently introduced two new advanced search functions: Google Local, which highlights search results from a specific geographic area, and Google Personalized Search, which allows users to create a profile of their interests to influence search results. But Semel called Yahoo's new search function "vastly more precise."

"As the amount of information on the web increases, individuals want a search engine to provide them with results that are personally meaningful," Semel said. "Enter the Yahoo Soul Search—a powerful new tool that reveals what's deep inside your heart, using the user-friendly interface already familiar to Yahoo fans."

In the past, a soul search was a labor-intensive and time-consuming process, Semel said.

"A soul search often required backpacking trips across Europe, disastrous long-term relationships with incompatible lovers, and years of expensive therapy," Semel said. "Worse, the search process often included depression, lowered self-worth, and intense doubt."

Semel called the old way of seeking clarity "a logistical nightmare."

"Each question you asked yourself seemed to have a thousand possible answers," Semel said. "That's why we designed a way to order returns by relevance and separate them into categories like 'religion' and 'sexuality.' After using the Yahoo soul-search engine, conducting the self-examination process without a computer will seem as ridiculous as doing accounting in old-fashioned ledger books."

The new search function is even customizable. Users can set their search to plumb their souls at varying depths, to make shallow discoveries or life-changing ones. They can also adjust their security preferences to protect themselves from the dangers of baring their naked souls to the world, and parental controls can be enabled in order to prevent children from looking inside themselves.

The new service is also hot-linked to the pre-existing Yahoo network—instantly leading the soul-searcher to pertinent information on HotJobs, Yahoo! Shopping, and Yahoo! Travel—making it possible for users to reconfigure their entire lives with one easy soul search.

Although soul searching online personal ads is not presently an option, Yahoo is developing a search engine which will allow its estimated 300 million users to find their one true soulmate.

Semel admits that the soul, while eminently searchable, is far from easy to navigate. There are still dangers in the form of self-deception, the soul-to-soul transmittable "D-spair" virus, and the numerous pop-up ads offering quick-fix solutions to the user's problems.

"There are bound to be some bugs, but we're not too worried," Semel said. "We at Yahoo have a lot of experience in helping people navigate an environment full of falsehoods, random useless information, and truly horrifying pornography. I don't think the human soul will hold any real surprises for us."

Early reviews from consumers have been overwhelmingly positive.

"I was skeptical, I'll admit," said former Boston-area investment banker Royce Creighton. "But after two minutes on Yahoo Soul Search, I found that being born into a family of bankers didn't mean I had to be a banker. Half an hour of advanced soul-searching helped me find a buyer for my house, an alpaca farm for sale in Wyoming, and a highly recommended acupuncturist in Cheyenne. I've never been happier... and I found all this inside myself through Yahoo!"

Tuesday, May 02, 2006

AJAX and the Desktop

In my view, AJAX will likely not replace desktop applications; but it will give birth to a new breed of enterprise AJAX grade software applications as services or better know as (SaaS). Most will be productivity tools, collaboration and business portals. Some will no longer be seen on the desktop at all. I think this next evolutionary phase in software will be less of an all-out exodus from the desktop than a moderate realignment, with applications thriving in the environments that best suit their purpose.

AJAX-faced web applications can follow you, like all web applications can. Most of us have at least one friend who traveled around the world and kept in touch via email with hotmail or yahoo e-mail accounts. In fact, these browser-based email interfaces helped drive the adoption of email for personal use. These days, using a more traditional html interface for business class e-mail use isn't really practical anymore. Outlook Web Access (OWA) (although it had a great AJAX interface) didn't really catch on for some reason, but Gmail and Zimbra are seeing uptake and Zimbra is aimed at replacing Outlook and Exchange altogether; and delivering all the UI through the browser. To Microsoft's credit, its Live.com initiative is giving birth to a new AJAX-enabled email client that will likely be much nicer to use than Hotmail if it's anything like OWA. If you look at the CRM world it seems that web apps have already taken over, Salesforce.com is an obvious example that has been delivered through a web browser for years.

AJAX-based web apps are the logical choice in applications where up to date and shared information is absolutely critical such as in logistics, accounting and CRM systems. Timely business data is a key component of modern businesses and web applications are data centric by their very nature. AJAX just puts face on the service orientated architecture application that does not cause tears of boredom as users wait for pages to refresh between mouse clicks.

Applications that rely on web services and disparate data sources such as mapping, or to a greater extent GIS, that combine multiple enormous data sources to remain relevant and useful. Also, many Service Oriented Architecture (SOA) based enterprise systems are perfect candidates for the distribution and usability benefits of AJAX apps.

Obviously all the benefits of software on demand, SaaS, and ASPs still apply, because the application is still delivered over the web and in a web browser. It would be silly to waste time going over the benefits of browser based apps; however, it's important to note that AJAX makes browser based apps more usable. These usability benefits can be measured in terms of time savings when interacting with faster user interfaces.

The world of desktop applications will benefit greatly from the use of web services and SOA. We will continue to see more integration of these two worlds. Already we are seeing desktop apps consuming rich content facilitated by the Internet such as iTunes, and desktop apps that will integrate with online with AJAX-based services like Live.com and MS Office.

In terms of penetration and adoption rates for new apps (web based), AJAX takes the cake. No other technology has entry barriers as low - all you need is a browser and an Internet connection. Furthermore, many AJAX applications will experience the benefits of network effects far faster than client apps since adoption can take place that much quicker.

Look at Google maps - no user could have all the mapping, images, and business/address listing data on their local desktop. Further the concept of mashups, which is a website or web application that seamlessly combines content from more than one source into an integrated experience, would not work if users had to install a plug-in or something every time they want to combine different data sets. Even if a client application had the data they couldn't keep it as up to date nearly as easily as web-centric app.

Collaboration will be incorporated into applications like never seen before. Systems like Writely, once adoption picks up, will change the way we think about office type applications. From the start all applications have a common platform, the browser, and speak common languages (XML, HTML, etc.) this means that as these small applications evolve it will be much easier to integrate them. Currently MS Office integrates well with itself and if you use SharePoint it works pretty well for collaboration. However, this depends on massive amounts of software to be installed on each client and pretty intensive server infrastructure to boot. But web apps should improve this experience and AJAX will make those web apps usable.

Using the power of the data services on the web combined with the power of the rich AJAX UI’s and real-time collaboration applications will change forever. Documents and data sets will seem much like leaving evolving content than a static view or piece of paper.