Peter Yared's Musings

Our engineering team has grown quite a bit, and I needed to better track our 1.0 release process. It has been a while since I have directly managed an engineering project, but I have done it before with Microsoft Project. So I order it and it arrives a couple of days later. I then had a very bizarre experience, almost like an archaelogical dig. It was a shrink wrapped box entitled "Microsoft Project 2003". 2003??? This code hadn't been touched in three years! I opened the box (yes, it is still a pain) and took out the CD and installed the software. I haven't installed software like this in years. I then entered everybody's tasks, task hierarchies, and such. Project was incredibly difficult to use, stuff that should have been obvious was very obtuse. Then I wanted to publish the Gantt chart in HTML for our intranet. Tried for hours. Couldn't do it. Finally I printed out the chart, taped six sheets of paper together, and posted it on the wall in our ...

One of the big drivers of Internet applications in the corporate world was the stark contrast of what people could do at home and at work: At Home: Buy books, buy movie tickets, look up the weather, etc. At Work: Call HR to change health plan, call factory floor to find out what happened to customer's order, call invoicing to find out what happened to a bill, etc. Well clearly something at work was wrong, and soon enough everything was online. :) Now look at the difference between home and work today: At Home: Web applications are using JavaScript and DHTML to enhance the user experience and decrease server interactions. Some random guy can combine Google Maps and Craigslist apartment listings in a useful way without talking to either Google or Craigslist ( http://www.paulrademacher.com/housing/ ). At Work: Everything has a Netscape 3 level of UI interactivity and nothing works with anything else. This difference in functionality and the increasing expectations of users will lea...

A couple of weeks ago I participated on an application server panel at Web Services Edge hosted by Anne Thomas Manes. There was quite a bit of discussion about WS-This and WS-That and WS-Foo and WS-Bar. Essentially, this Web Services thing has devolved into a huge unintelligible morass. The panel was covered today in LinuxWorld , which liked an ad-hoc term I used: WS-Nothing . Vendors Have Been Arguing for So Long That You Have to Send Text Files Around On the panel, I said that we vendors have lost sight of the fact that we have been bickering so long that the only way our products can talk to each other is to send text files around. We are now in the process of screwing even that up with all of these competing specifications about how to mark up self-describing text files. It is of no supprise that Web Services have not had a big uptake with customers; they don't even know where to start. The point of web services is interoperability, and if the Web Service produced by a particul...

In a world where applications are increasingly being defined by declarative XML like BPEL, XForms, XPath, it is becoming cumbersome and complicated to incorporate all of those definitions into procedural applications. But perhaps the tail has been wagging the dog. If the flow of an application, the interface points to external entities, its user interface, and its queries are all defined in XML, perhaps it is time to simply admit that the application is written primarily in XML and that logic must be integrated with the XML defined application, not the other way around! Of course the obvious integration point for such an architecture is web services, which clearly is not ideally suited for adding snippets of code or for having a bunch of internal methods that call each other and share the same dataset. What is needed is a method to have a web service that is treated like a local method call, much like in the CORBA days there was a way to do a local IIOP call. The concept of Local...

Web services are certainly the buzz de jour and have had quite a bit of sustaining power over the past couple of years. Many seem to think that this it is all very exciting, whilst newcomers seem very intimidated by it all. This is understandable, given: Web services are about the biggest alphabet soup of standards to date Open up most any XML file – enough said While in fact the point of web services is that they are very simple. In order to recognize this, it is important to take a historical perspective of the computer industry, namely “how we gonna get these here machines to talk to each other?” Phase 1 – Dig a Trench In the 1970s, the early days of computers, getting two computers to talk to each other was pretty straightforward. You laid a physical wire between the two machines, developed a proprietary protocol, messed around on either end for a while, and presto, the two machines could talk to each other! Needless to say, this was very expensive and cumbersome, and machi...

After my time at JRad, NetDynamics and Sun, I have been thinking about how application servers originated, what they were meant to do, and where they are going. Application Servers, 1995-1997 With the advent of the “Internet” age in 1995, all of a sudden corporate resources had to be available to HTML/HTTP clients. The HTML/HTTP clients were very different from previous clients in that they represented numerous intermittent connections, while in the previous client/server world there were generally a fixed number of clients with constant connections. For example, an internal HR system that was built to support 30 HR reps and perhaps scale to 50 HR reps over the next couple of years was going to crawl if it all of a sudden had to handle 100,000 employees doing employee self-service during 401K election time, with each connection building and then tearing down a connection to the database. Application servers were introduced to solve this problem. App servers would maintain a f...

A version of this post was also published in Dr. Dobb's. After almost 9 years of programming in Java, I have been thinking about where Java is going and how it fits into the continuum of programming languages in the enterprise. Evolution of Corporate Systems and Languages Java falls into the category of the corporate language – a computer language and system used by corporations to run their business. To understand how corporate languages evolve, it is important to match them to evolution of corporate computing platforms. Corporate platforms evolved from mainframes to minicomputers to client/server to Internet and now to Grid (parallel Linux white boxes). In each transition, a dominant player emerged, as shown in the following chart: As corporate computing platforms shifted, the corporate language of choice had a tendency to shift as well. The hey-day was during the client/server era, when there were numerous popular languages, including Visual BASIC, Delphi (a Pascal derivative),...