Author: Wolfgang

In the past the picture was clear.
On one hand there were “open” standards like the J2SE/J2EE maintained via the Java Community Process(JCP) and hosted by Sun Microsystems.
Other vendors participated and helped the standards evolve.
On the other hand were de facto standards, mainly set by Microsoft, for instance MFC or the .NET technology stack.

Currently the picture is changing.
In my perception the pace in the Java world has become slower. How long did it take to finish for instance the EJB2.1 specification ?
In the meantime Microsoft inceased their effort to elaborate their technologies.

Beside that new boards like WS-I to were founded to help establish the WS-* standards. If you have a look at the specifications you will notice that the key players are IBM, Microsoft and BEA.
In addition to that BEA and IBM work closely together to write Java Joint Specifications.

Quote from the announcement:
“In response to requests from customers and joint Independent Software Vendor (ISV) partners, BEA and IBM are collaborating on specifications for programming models and APIs for Java(tm) 2 Enterprise Edition (J2EE) application servers that provide programmers with simpler and more powerful ways of building portable server applications.”
Why not submitting proposals to the JCP first ?

Many of the upcoming standards are mainly driven by IBM, Microsoft and BEA.
In my opinion the benefit is, that it’s no more everyone against Microsoft but everyone for innovation.

What are the strengths of browser based applications ?

Sophisticated user interfaces ? No ! (slow server roundtrips)
Easy development ? No ! (a lot of scripts)
Offline capability ? No !

Easy deployment ? Yes !

The most important feature of browser based applications is the easy deployment.
You just have to update the server to update your clients as well.
But everything is based on the HTTP which is relatively simple and not suitable to support rich clients.

Sure there is Java Webstart and .NET Zero Touch Deployment which enables you to type something like

http://ww.pleus.net/MyRichClient.jnlp

or

http://ww.pleus.net/MyRichClient.exe

in your browser to start your managed application.

By using this approach it’s possible to enable rich user experience and user server based deployment.

But that’s not all…

During this years PDC Microsoft announced their next model for the development of user interfaces called Avalon.
This technology is based on XAML (XML Application Markup Language). This enables us to develop rich clients in a declarative way like HTML.
The following snippet is an example of how to write the HelloWorld application with XAML:

<TextPanel xmlns=”http://schemas.microsoft.com/2003/xaml” Background=”BlanchedAlmond” FontFamily=”Comic sans MS” FontSize=”36pt” HorizontalAlignment=”Center”>
Hello, world!
</TextPanel>

This document can be distributed over HTTP. The client uses it to create a UI which runs into the browser or standalone.
This is only a new version of HTML, you might say.
But in contrast to HTML it enables you to develop fully-fledged rich clients in a mostly declarative way.
That’s promising, I think.

Do you remember the times when C++ was the mainstream programming language in enterprise level projects ?
A popular approach was to simplify the code by defining a lot of macros.
Even Microsoft did that very extensively in their MFC implementation for instance in their ubiquitous messagemaps.
The benefit was an easy progamming model – just add a few macros and be happy.
On the other hand it was very difficult to understand what really happened in the background.
This was especially true for user defined macros which could only be used in the context of a certain project.

Later languages like Java and C# took over and macros became history (C# has a preprocessor but no macros). The nightmare was over.
Todays software systems aren’t easier than in the past. Therefore the language engineers considered it to be a good idea to support some metainformation facility in form of attributed programming.

In .NET you have attributes.

[WebMethod]
public string HelloWorld()
{
return “Hello, .World!”;
}

Java introduces the Language metadata facility (JSR175) which is currently a community draft. This approach is based on javadoc comments.

/**
* @common:operation
*/
public String HelloWorld()
{
return “Hello, World!”;
}

Looks somehow similar, right ?

But it’s not.

In .NET the attributes are stored in the assemblies metadata and therefore can be accessed at runtime.
They can be determined by reflection as shown in the following example:

class Test
{
static void Main(string[] args)
{
Type t = typeof (Test);
MemberInfo[] members = t.GetMember(“DoIt”);
object[] attrs = members[0].GetCustomAttributes(false);
Console.WriteLine(attrs[0].ToString());
}

[Cool()]
public static void DoIt()
{
}

[AttributeUsage(AttributeTargets.All)]
public class CoolAttribute : Attribute
{
}
}

In Java they merely serve to generate code at compile time.
Java supports reflection as well. But due to the fact that the attributes are not stored in the metadata they can’t be determined by reflection at runtime.

What’s the conclusion ?

On one hand both approaches are very useful to simplify the programming model for the developer.

On the other hand they are like C++ macros. A developer can define his/her own attributes which nobody outside a project might know.
This leads to applications which are hard to maintain.
In order to create maintainable software systems I think developers should define their own attributes/annotations as little as possible.
This will ease the job especially for new team members which join a project at a later time.

Today I would like to share some thoughts about the future of information technology.

If you look back in the history of information technology you will see one obvious trend.
What I mean is abstraction. The first important step was the object oriented paradigma which allows us to model the real world into code.
With this paradigma it was possible to implement persons instead of simple functions.

The next step was component technology which sits on top of oo. This model is more aligned to the real world, as it focuses on interfaces instead of internal implementations.
With that you just have to meet the person and know the language for communication. It’s not important whether the person has a pacemaker or not.

But we still had to develop on a very low technical level. This changed with the introduction of application platforms like J2EE and .NET. This brought abstract APIs for development.
With these application platforms we got rid of the error-prone system level coding. These new programming models are easier to handle than it predecessors like MFC, OWL, ect. (but they are very complex)
Because of this ease it’s possible to build more sophisticated distributed applications. But architecture and system design is much more important these days.
Nowadays you are no more limited to develop single persons, but worldwide distributed communities.

And the choice of the application platform is loosing importance (except for the vendor).
Most of the complex enterprise level applications have the same non functional requirements like availability, failover, security. Therefore providing powerful runtime environments, like EJB or Enterprise Services are a logical consequence.
And it finalises the good old separation of concerns paradigma.
That is the environment, e.g. air, accomodations, etc. where the community lives in.

That’s where we are today.

What comes next ?

If you open your eyes you can identify the upcoming levels of abstraction. One is the notion of shifting from coding to modeling. This trend has a popular three letter acronym.
It’s MDA or Model Driven Architecture which promises to generate most of the code from a model.
The other sign of abstraction is business orchestration. We see that in products like Microsofts Biztalk Server or BEAs Weblogic Integration.
The outcome could be that the applications which are generated from the model can interact with each other by connecting them with a drag and drop approach.
The foundation for this interoperability are the emerging Web Service standards.

How does that sound ? Do you like coding ? What will you do in the future ?

In my opinion coding will loose importance.
But without experienced people which are able to look behind the scenes and are able to cope with the complexity of these highly distributed systems it would be very hard to maintain them.
At the latest when a system does not work as expected. Moreover Enterprise Application Integration will raise to a new level.
That means there will be still much work to do for developers even if the way of application development will change. But that is business as usual, isn’t it ?