The first topic was Web Services and XML standards. Even though Web Services today don't yet have well-established standards for transactions, security, etc., they are being developed and being adopted by the major vendors. They are being used to develop remote services such as e-commerce systems that submit transactions to main frame applications. Also, there are many standards being developed around XML.

There are two points of view about Web Services services: a) it's all hype, just a crippled CORBA, without security, without true transactions, and texted-based; b) it's more that hype because it's simple to implement, it's got cross-vendor support (MicroSoft, IBM, and many applications are getting behind it), and it provides an integration mechanism which is sorely needed.

The prevalent view seems to be that it is more than hype: a lot of vendors are opening up their applications by defining SOAP XML interfaces, which has a huge impact on developers. It means you can easily call these from a web application server, for example, to request a transaction to be done on the main frame accounting system. This avoids having to learn the custom API for each application, and the problems of trying to go from one kind of machine to another through the custom APIs. But there is a higher risk because if one of the service providers needed by an application is down, then the application won't work. Messaging can be used instead of synchronous protocols if you are sure that a currently unavailable service will be available later, and if you don't care about the timeliness of the function, but it does create additional dependencies in your application.

A recent survey shows that few companies are actually using it. Most (70%) are in the early stages or not doing anything (e.g., doing nothing, thinking about it, piloting, incremental rollout). About 30% are actually using Web Services, and most of those are only using them within the organization. Only 9% are using them outside of the organization, despite early predictions about the development of hubs and everyone communicating with everyone. In reality, implementations are beginning as internal and slowly expanding to external, although the pace is picking up. For example, WalMart will tell their suppliers in November that they will have to adhere to RFID and to the WalMart Web Services standard. WalMart represents such a huge slice of retail in the US that this has a huge impact on suppliers. The suppliers will have 14 months to implement; if they don't comply, they won't be part of the WalMart supply chain.

A question from the audience asked about bandwidth and load factor effects in the pilots and incremental rollouts. XML is a bandwidth hog and it can have a significant impact on load factors. Some applications will have to compress the data being transferred or they will have to work around the transfer of large amounts of information. But this is a problem we have always had: designing the application so that the appropriate amount of information is coming across in reasonable sized chunks. Theoretically, bandwidth is increasing and this is becoming less of an issue. However, most applications he has seen don't actually pass that much data around.

Another reason for people to believe this is more than hype is the membership in the Web Services Interoperability Organization: major technology vendors (Borland, Rational, IBM, HP, MicroSoft, etc.), but also companies with huge supply chain issues (Chrysler, Ford, etc.) who need real time supply chain information so they don't have to store any of the parts.

Amazon has opened up their entire back end as a series of Web Services, from which you could create a custom-looking book store which could use their search, browse, and matching capabilities (other customers who bought the book you are buying also bought these others). Any kind of business can use their transaction services.

Google is another Web Services provider. TechEmpower has an application that searches for new mentions of TechEmpower on Google's indexes, so Tony can see what people are saying about the company. You can also track trends. A big company, for example, could track bursts of activity vs. mention of company name.

There is an incredible amount of stuff going on with XML standards: HL7 for healthcare providers for exchanging health care info and procedures; RosettaNet for describing parts and transactions around parts; Human Resources; Business Reporting; Accounting, etc. Because there are so many standards, standards of standards are now arising: i.e., this is how you describe a person, address, etc. Since it's pretty easy to transform from one description to another, there are companies getting involved in this business of transforming the data. This is a threat to proprietary formats.

Analysts predict huge adoption of Web Services, but that's their business. Here are the things they point out: cheaper (easy to implement); faster to implement (but slower to transfer information because it's text-based); very simple application integration.

Today's challenges: a) no security definition for many of these services, but it's coming; b) no transaction definition so if you want transaction capability, you have to build your own on top of your application; c) Toyota has 100's to 1000's of applications, so how do they know what web services each one is providing and how changes to one application API affect other applications.

Thus, there is a need for capabilities on top of Web Services to provide robustness. Analysts call these additional capabilities Service Oriented Architectures and propose that they will be loosely coupled, coarse-grained, asynchronous, i.e., messaging-based. In an e-commerce application, for example, you would queue up a bunch of requests to your accounting package, and get a receipt later when the accounting package has processed them. There are a number of companies that have a lot of experience with messaging systems and they have a lot of capabilities built on top of it. So they see Web Services going in this direction. Also, there will be tools to manage the different layers and tools to keep track of all the different Web Services that are available.

A question from the audience was "Why is this better than CORBA?" Because more than a few people are using it. Technologically, CORBA is much better: more efficient, more robust (security, transactions), but nobody used it. CORBA was so complex that different implementations couldn't talk to each other because of different interpretations of the standards. Because Web Services is so much simpler, there is less of that, but it still does occur.

Tony then moved on to his next topic of the evening: Model Driven Development. Today we are still doing mostly procedural programming. It hasn't changed that much since the 1960's. So procedural programming is well understood and can be taught relatively easily. It will migrate continuously to lower and lower cost providers. India has been the low cost provider in the past, but now China is becoming the low cost provider. But you don't save as much as you would think, only about 20-30%, even though the off-shore programmers work for a tenth of what programmers here cost. This is because development is a minority of the effort.

What has changed? One change is Packaged Applications, such as accounting. You purchase an accounting application from companies like Oracle, Siebold, or SAP, and then parameterize it to suit your own business. This is something different from traditional programming. It is configuring and tweaking. And as time goes by, the customized tweaking is being incorporated into the standard packages and becoming configuration options.

The other big change is Model Driven Development. The theory is that you create a model of your system using UML or Rational Unified Process (RUP). This is a great way for an analyst to define system behavior using visual modeling tools. Then the visual model is transformed into the code which implements the model. In the 70s and 80s this was called CASE. But then, if something needed changing, you changed the code, not the model. The model never got updated.

The new paradigm is that you stick with modifying the visual model, or perhaps the transformation from the model to the code, but never directly modify the code itself.

There are some emerging standards: a) UML2 to clarify semantics of implementations; b) Metaobject facility to describe the transformations; c) Interchange definition to create models that can be shared. Shared models are important to someone who creates a bunch of web services and exposes them to others to incorporate them into their overall systems file; i.e., reuse is built-in.

Lots of tools are coming out in this space, from point solutions to big suites (RUP). Toyota just adopted RUP for its 3000 programmers. And there are a lot of free tools.

What's the job of the programmer / analyst? Analysts are good at capturing the brains of the business users and turning them into natural language definitions of requirements. But most are not very good at coming up with programming level models of what the system has to do. So they are going to have to become super analysts, able to transform the natural language requirements into a higher level programming model. Programmers no longer write the underlying code; they now write transformations, more like compiler writers. So the roles are quite different in this development model.

Is this just hype? Some say Yes. It's just RAD or CASE. We've seen it before. It's failed before. It'll fail again. We are on the beginning of the hype cycle, but it will peak out in about 2 years.

Others say No, it's not hype. We are standardizing on this. Vendors are developing models that can be shared across vendors because they are based on the standards. And it's more important to do this because of Web Services. And we will see some real productivity gains. There seems to be a level commitment from major companies that we haven't seen before.

Tony thinks it's being overhyped, but with so many big vendors behind it means we will see more and more of it, and universities will be producing graduates who understand UML. But, it will take a long time to really have an impact. For well-known domains this will work well, but for unknown domains it will be used as a tool for an analyst to describe to programmers in India what needs to be built procedurally. Ultimately, in a few years we will all still be procedurally programming.

The next topic was Software Quality improvement tools. We are really bad at what we do. It's estimated that there are 5 to 15 flaws per 1000 lines of code and Tony thinks it's probably actually higher. It takes $30,000 to fix the bugs in those 1000 lines of code. Downtime due to software failures costs the economy $60 billion, which is 0.6% of the GDP. If we did a better job we could save $22 billion. At least 40% of unplanned downtime is due to application failure and it is probably even higher. Web Services which are so dependent on multiple systems is even more prone to failure.

Many interesting tools are emerging to improve software quality. Application testing tools are a pain to use, and difficult to maintain because many of them are screen based. The tool has to be modified if the output of the application changes. These are very expensive and will probably end up being shipped to India or other low cost providers.

Parasoft have a tool set that examines code and applies about 300 industry metrics against the quality of the code. The tool can be incorporated into the source code control tool so that each time the code is checked in, the tool analyses it and provides a quality report. Over time, the rules can be improved as you discover problems that escaped the previous set of rules. This tool provides automated code reviews, which seems more palatable to programmers than having a co-worker examine their code.

Another interesting tool is called PAM. A distributed Java application can be instrumented such that it reports method level calls back to the server. If the activity is normal the reporting service shuts itself off and when the activity becomes abnormal then it starts reporting. This helps you pin down where the real problem is coming from.

The final topic was the impact that alternate computing platforms are having on application development. Alternate platforms are things like tablet PCs, PDAs, cell phone+Palm combos, etc. Also wireless is becoming more and more prevalent. So now applications have to be able to work with or without internet connection. And applications have to work on these multiple device types. Device-independent applications are easier to develop if they are web-based.

The presentation was very interactive, and lots of questions and discussions from the audience kept the presentation very lively.

This was the second meeting of the LA Chapter year and was attended by 30 persons.
Cheri Kaylor for Mike Walsh, LA ACM Secretary