Schizophrenic Attitude Amongst The Java Community

In the early days of Java a strong argument used by the proponents of the technology was standards compliance. Later on the community realized that the standardized technologies were not enough to meet common project requirements or the way they worked was not the most elegant.
That’s why frameworks like Struts or Spring appeared. Nowadays standards seem to be a kind of unneccessary luxury.
But they are not! Java standards allow to avoid the vendor lock-in that people were always complaining about especially in terms of Microsoft technologies. But in the context of open source this seems to be forgotten. A lot of developers a willing to use every cool non standardized open source framework that appears never asking whether it’s standard compliant or not. Examples are Struts, Spring, Beehive, etc.
I think as long as no standardized technology is available which meets certain requirements it’s perfectly fine to use non standardized technology. At least if it has a sound background for instance by a large vendor or large independent developer community.
I know there are other factors like existing codebase which might influence a technology decision.
But if one has to choose between standardized and non standardized software the choice should be clear.

What is your choice?

EJB3 or Spring?
Classic J2EE or Beehive?
JSF or Struts?

The Future of BEA Weblogic Workshop

BEA recently introduced it’s new Eclipse-based development environment after an acquisition of M7.
This immediately raises questions about the future of the BEA Weblogic Workshop 8.1 product which by now was the development environment from BEA. The BEA Workshop Studio 3.0 FAQ elucidates the subject.

Quote from the FAQ:
“There will initially be two developer tool products, the BEA Workshop Studio 3.0 and the WebLogic Workshop 8.1 IDE. BEA had previously announced that the next generation of the BEA WebLogic Workshop

New Workflow System

Microsoft announced Windows Workflow Foundation (WWF) on Sept. 14, 2005, as the programming model, engine and tools for quickly building workflow-enabled applications on Windows.
Seems to be an interesting technology, because nowadays a lot applications implement their own workflow engines. Moreover the support for human based workflow is often not very sophisticated amongst professional products like BEA Weblogic Integration or Biztalk Server.

Speaking in terms of Microsoft technology especially Biztalk Server and WWF overlap in a lot of areas.
The when to use what guidelines from Microsoft are:

Use Windows Workflow Foundation when:

An application will itself host workflows. Windows Workflow Foundation lets workflow be built into an application, allowing the workflow to be deployed and managed as a native part of the application. Because it’s focused on integrating diverse applications rather than providing a general workflow framework, BizTalk Server always runs orchestrations within the BizTalk Server process.

The business process being implemented requires human workflow. BizTalk Server addresses system workflow, and so it lacks Windows Workflow Foundation’s support for things such as state machine workflows and dynamic update. A scenario that requires both human workflow and more complex system integration services could be addressed by using Windows Workflow Foundation and BizTalk Server together, however. For example, the Office “12” support for document-centric workflows, based on Windows SharePoint Services, might be used for the human aspects of the problem, while BizTalk Server handles the system integration aspects. The two can interoperate using the BizTalk Server Adapter for SharePoint.
The workflow will execute on a client system. BizTalk Server is a server-focused product, and so it’s less well-suited to run on desktop machines.

Use BizTalk Server when:

Solving an EAI problem that requires communication with diverse applications on diverse platforms. Because of its focus on cross-platform integration, a large set of adapters is available for BizTalk Server that allows communication with a range of other software. Windows Workflow Foundation is focused solely on workflow, not EAI, and so it doesn’t provide these things.
B2B services are required. Windows Workflow Foundation doesn’t address this area, while BizTalk Server provides tools for working with trading partners, accelerators for RosettaNet, SWIFT, and other industry standards, and more.
BPM services, such as Business Activity Monitoring (BAM), are required. While the Windows Workflow Foundation tracking infrastructure can be used to create these services, BizTalk Server provides important extras, such as tools that let information workers define their own BAM views.
A complete management infrastructure and support for increased scalability are required. Unlike Windows Workflow Foundation, BizTalk Server includes a full set of tools for administering and scaling a production environment.

So in essence WWF is for Human Based Workflow, whereas BTS is for Enterprise Integration.
Seems to be a good idea not to use BTS Human Workflow Services but to wait for WWF until end of 2006.

Culminis Speakers Bureau

Recently I joined the Culminis Speakers Bureau.

Quotation:
“The Culminis Speakers Bureau, a service available exclusively to Culminis Member Organizations, and
provides top IT presenters including Microsoft speakers. Only presenters with top credentials are allowed in the Culminis Speakers Bureau, and after a speaker is utilized, Member Organizations are allowed to rate the speakers online, as well as view prior speaker ratings.”

Please check the August Newsletter to get more information about Culminis.

The Challenge of SOAD

A major challenge establishing service orient architectures (SOA) and applications is how to design the right services in order to make them reusable and sustainable. A lot of questions have to be answered. For instance:

What are the service candidates?
What is the right service granularity?
Is it better to use a top-down or bottom-up approach?
etc, etc, …

Apart from technical issues answering these kind of questions is very important for the quality of the resulting applications. Albeit the traditional OOAD approaches are helpful, SOA requires a different perspective on the subject. This perspective is party technical an partly business related as existing business processes have to be taken into account.

The article Elements of Service-Oriented Analysis and Design provides a good introduction into the subject.

Experience shows that it is a good approach to have mixed teams with experienced people from the technical and the business departments.
SOAD is neither a merely technical nor a merely business related task. It’s both. That’s the challenge.