Friday, October 31, 2003
BT Exact > White papers
The future looks ever more exciting each year. Technology development is still accelerating and an increasing number of new fields are being created and exploding new ideas onto the market.
The future is a hard to predict but here, at BTexact, we have always believed that inventing the future is the best way to create it. One thing is certain in the distant future - the world will be a very different place. One tool we produce to help alleviate uncertainty about the future is our BTexact technology timeline.
The timeline is produced mainly to give BT researchers and managers a view of what the operating environment is likely to contain at any future date, so that our products and services can be better targeted to the needs of the customer. But we have also found that many people outside the company find it useful too, so we always try to make it as free of technical jargon as possible. What must be remembered by anyone preparing for the future is that technology change isn't very important in itself. What matters is what this change enables or destroys.
The intention of the timeline is to illustrate the potential lying ahead for beneficial technologies. Not all will be successful in the marketplace. Some won't ever be implemented at all, but as the rest come on stream, our lives will improve in many ways. We will have more variety of entertainment, better health, greater wealth, and probably better social well-being. We will have more time saving devices and ultra-smart computers will do most of our admin, but the future world will offer so much more opportunity to be productively and socially busy that we will have even less free time than today! If we think of this as living life to the full rather than in terms of stress, then the future looks good.
We hope you enjoy reading our timeline as much as we enjoyed producing it.
View the full white paper (PDF)
Tuesday, October 28, 2003
MDA code generator framework XCoder is now open source
(originally posted By: Constantin Szallies on October 24, 2003 @ 04:54 PM)
XCoder is an extensible model transformation and code generation framework. The framework is itself modelled with UML and generated using the standard UML to Java model transformation included in the distribution.
Currently supported input meta models: UML via XMI
Currently supported output meta models: Java, C# and C++
The distribution also includes a standard transformation from the UML to an EJB meta model.
The source is available open source under http://sourceforge.net/projects/xcoder, whitepapers are available under http://www.liantis.com/Downloads/index.html
XML and Java technologies: Data binding with Castor
A look at XML data binding for Java using the open source Castor project
XML data binding for Java is a powerful alternative to XML document models for applications concerned mainly with the data content of documents. In this article, enterprise Java expert Dennis Sosnoski introduces data binding and discusses what makes it so appealing. He then shows readers how to handle increasingly complex documents using the open source Castor framework for Java data binding. If your application cares more about XML as data than as documents, you'll want to find out about this easy and efficient way of handling XML and Java technologies.
XML and Java technologies: Data binding, Part 1: Code generation approaches -- JAXB and more
Generating data classes from DTDs or schemas
Enterprise Java expert Dennis Sosnoski looks at several XML data binding approaches using code generation from W3C XML Schema or DTD grammars for XML documents. He starts out with the long-awaited JAXB standard now nearing release through the Java Community Process (JCP), then summarizes some of the other frameworks that are currently available. Finally, he discusses how and when you can best apply code generation from a grammar in your applications.
XML and Java technologies: Data binding, Part 2: Performance
After kicking the tires in Part 1, take data binding frameworks out for a test drive
Enterprise Java expert Dennis Sosnoski checks out the speed and memory usage of several frameworks for XML data binding in Java. These include all the code generation approaches discussed in Part 1, the Castor mapped binding approach discussed in an earlier article, and a surprise new entry in the race. If you're working with XML in your Java applications you'll want to learn how these data binding approaches stack up!
XML and Java technologies: Data binding Part 3: JiBX architecture
Tests in Part 2 showed JiBX delivers great performance -- here's how!
Enterprise Java technology expert Dennis Sosnoski gives a guided tour of his JiBX framework for XML data binding in Java applications. After introducing the current frameworks in Part 1 and comparing performance in Part 2, he now delves into the details of the JiBX design that led to both great performance and extreme flexibility for mapping between XML and Java objects. How does JiBX do it? The keys are in the internal structure...
XML and Java technologies: Data Binding Part 4: JiBX Usage
Part 3 described the JiBX internal structure -- now find out how you actually use JiBX for flexible binding of Java objects to XML
JiBX lead developer Dennis Sosnoski shows you how to work with his new framework for XML data binding in Java applications. With the binding definitions used by JiBX, you control virtually all aspects of marshalling and unmarshalling, including handling structural differences between your XML documents.
Wednesday, October 22, 2003
Creative Science Systems Schema2Java Compiler
Schema2Java™ Compiler generates XML Schemas into Java classes, which can then be used by developers in applications that process XML documents. Schema2Java™ Compiler enables XML processing with the convenience and ease of Java objects. Schema2Java™ Compiler not only makes XML processing simple and easy, it increased the productivity of Web Services development by as much as 80%. Why? Because XML document processing is an integral aspect of Web Services.
Schema2Java™ Compiler enables fast, error-free, and efficient development of Web Services applications.
Friday, October 17, 2003
Martin Fowler Bliki: EnterpriseArchitecture
Just recently I've picked up a couple of bad reviews on Amazon for P of EAA because there is nothing in the book about enterprise architecture. Of course there's a good reason for that - the book is about enterprise application architecture, that is how to design enterprise applications. Enterprise architecture is a different topic, how to organize multiple applications in an enterprise into a coherent whole.
As it turns out, I can get pretty cynical about enterprise architecture. This cynicism comes from what seems to be the common life-cycle of enterprise architecture initiatives. Usually they begin in a blaze of glory and attention as the IT group launches a major initiative that will be bring synergy, reuse, and all the other benefits that can come by breaking down the stovepipes of application islands (and other suitable analogies). Two or three years later, not much has been done and the enterprise architecture group isn't getting their phone calls returned. A year or two after that and the initiative quietly dies, but soon enough another one starts and the boom and bust cycle begins again.
So why does this cycle happen with such regularity? I think that most people involved in these initiatives would say the reason they fail is primarily due to politics - but what they often miss is that those political forces are inevitable. To succeed in these things means first recognizing the strength of those political forces.
The problem for central architecture groups is that they are driven by IT management, but the applications they are looking to organize are driven by business needs. If an application team is told to do work that doesn't benefit their application directly, but makes it easier to fit in the architecture, there's a natural reluctance to do it. Furthermore they have the ace card - the business sponsor. If the business sponsor is told the application will ship four months late in order to conform to the enterprise architectural plans, then they are motivated to back up the application team when they say no (spelled "we'll get around to it later"). Since the application is directly connected to providing business value, and the central architectural team isn't, the application team wins. These wins cause the enterprise architecture initiative to bust.
To avoid this the enterprise architecture initiative has to recognize and submit to the political realities.
Understand what the business value of any enterprise architectural initiative is.
Make sure that any work is supported by incremental short term gains in business value.
Minimize costs to the applications
A good way to think about this is that these initiatives should less about building an overarching plan for applications, and more about coming up with techniques to integrate applications in whatever way they are put together. (After all ApplicationBoundaries are primarily social constructs and they aren't likely to conform to anyone's forward plans.) This integration architecture should work with the minimum impact to application teams, so that teams can provide small pieces of functionality as the business value justifies it. I think you also need to focus on approaches that minimize coupling between applications, even if such approaches are less efficient than a more tightly coupled approach might be.
These reasons tend to lead me toward a messaging approach to integration. While it has its faults, it's something that can be applied with minimal impact to existing applications.
By the way, enterprise application architecture can have a big impact upon enterprise integration. Applications that are nicely layered, particularly with a good PresentationDomainSeparation, are much easier to stitch together because you can more easily expose the applications functionality through services. This isn't a cost to the application, because good layering makes the application easier to maintain as well. However too few application developers understand how to do PresentationDomainSeparation. One of the best things an integration group can do is to support education and training to help them to do this (an approach that's best supported if act like Architectus Oryzus rather than Architectus Reloadus). So in that sense my book has a lot to do with enterprise architecture.
Sunday, October 12, 2003
XML Beans: relaxing the JDK 1.4 requirement
> -----Original Message-----
> From: Maurice_E_Sherman@Keane.Com
> Sent: Wednesday, October 08, 2003 7:42 AM
> To: firstname.lastname@example.org
> Subject: relaxing the JDK 1.4 requirement
> XMLBeans seems ideal for my project, but I'm constrained to
> using a 1.3.1 JDK in deployment, but not in development.
> Anyone have any advice on the feasibility of using XMLBeans
> in a JDK 1.3.1 deployment environment.