CodeFutures News & Industry Commentary Blog

The well respected industry analyst Dana Gardner has published an interesting article on The Soul of SOA that provides the highlights of a discussion between Steve Garone, Joe McKendrick, Tony Baer, and Jim Kobielus.

As usual, Joe McKendrick has come out with something original that makes a lot of sense when you think about it in the context of real world examples you might happen to know:

The companies that are most likely implementing, or are implementing, SOA are probably the companies that don't really need SOA as much. The companies that really could use SOA in their operations are likely not to be the ones implementing. It's kind of a paradox.

The reason (for) that is the companies that have the management vision, the support to roll out and move an SOA project forward -- providing top management support, for example -- are likely to have (a) lot of other initiatives on the table. They're likely to be very forward-looking with their management.

So the good IT departments, that probably have things under control anyway, are the ones that are proceeding with SOA. The poorer IT departments, that could probably get a higher ROI from SOA efforts, are not well organized enough to implement SOA.

PJ Murray
CodeFutures Software

If you work in the IT industry, the new Windows update is mixed news. The product launch date was driven by commercial realities rather than product completeness. So that means there are features that were rushed and features that should have been included but were not. Despite the honest and best efforts of Microsoft, there will be security holes.

All of these problems are fixable - Service Pack 1 will fix a lot of the problems and the product will probably be fairly stable by Service Pack 2.

Intel, of course, says that new hardware is required:

Intel spokesman Greg Bryant, vice president of the Business Client Group, for example, flat out recommends new hardware for Vista, citing specific improvements in its new embedded graphics subsystems, allowing new notebooks, especially value-class machines, to run Vista’s full graphic experience. Intel’s new Core 2 Duo CPUs also contain specific improvements for Vista and Office 2007, with Intel citing an increase of as much as 300 percent in the speed of an Excel calculation.

So it's a really bad idea to upgrade existing hardware.

That leaves the problem of what operating system to choose when buying new hardware before the first few Service Packs are ready.

It probably depends on what the hardware is going to be used for:
-development - it's probably OK to move over to Vista
-deployment - it's definitely far too early to move over to Vista - come back in 2008

PJ Murray
CodeFutures Software

In an article called "Multithreading invites string of nasty bugs, paper argues" in Electronic Engineering Times, Jeff Bier that summarizes academic research: "multithreaded application programming, as commonly practiced, is a flawed methodology that invites a range of nasty, hard-to-identify bugs."

The key problem is summarized as:

thread-based programming has worked reasonably well so far because it has been applied in fairly limited ways and has typically been used on single-core processors, which offer limited parallelism. But as engineers implement more-aggressive multithreading on highly parallel processors, they can expect severe bugs to show up with alarming frequency

Not only do developers need to learn how to take advantage of multicore processors, they need to do it in a Service Oriented Architectures.

PJ Murray
CodeFutures Software

David Linthicum seems to have just realized the significance of Service Component Architecture and Service Data Objects and the OSOA.

David Linthincum does a good job of describing Service Data Objects and also recognizes that using databases in SOA will be one of the most significant use cases:

SDO is looking to provide a consistent way of handling data in applications, whatever its source or format may be. Okay, that would be data abstraction. Moreover, SDO provides a way to unify data handling for databases and services.

It's clear that SDO is designed to unify the way in which SOA applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web Services, and enterprise information systems.

SDO is based on the concept of disconnected data graphs or a collection of tree-structured or graph-structured data objects. Under a disconnected data graphs architecture, a client retrieves a data graph from a data source, mutates the data graph, and then applies the data graph changes back to the data source.

Databases are connected to the applications by data mediator services. Client applications query a data mediator service and get a data graph in response. Client applications send an updated data graph to a data mediator service to have the updates applied to the original data source, and this architecture allows applications to deal principally with data graphs and data objects.

'Data mediator services' are now called Data Access Services, but otherwise David Linthincum provides a great overview.

The one thing he does not point out - the SDO API is the only industry standard for data access in SOA.

PJ Murray
CodeFutures Software

How do you publish and promote a software engineering methodology? The question has come up today in InforWorld.

It is particularly important for SOA, because the industry is so focussed on specifications and end users just don't know how to use them. It's different for Java, where there are Core J2EE Design Patterns.

The industry standards organizations promote specifications, not methodologies. So the OSOA promotes Service Data Objects but does not have anything on how to use the SDO API.

Also, a methodology is closer to a design pattern. So it evolves over time based on best practices. That means interaction with methodology users and a feedback loop.

The WIKI model already demonstrates how this can be done, so it only requires a Web site, some methodologies, and of course, users to provide feedback.

PJ Murray
CodeFutures Software

John Crupi has written an article on AJAX and SOA in Java Developers Journal.

PJ Murray
CodeFutures Software