Solving Business Problems and Remaining Hip -...

Copyright © 2003 by Drutt Corporation, all rights reserved. Oracle’s International User’s Group is permitted to use this document as described under the terms of OOW 2003. All others must obtain written permission to publish or distribute this document partially or in whole. All products or company names are used for identification purposes only, and may be trademarks of their respective owners.

Solving Business Problems and Remaining HipDeveloping best-of-breed software components

By Magnus Lönnroth and Peter Larsson

DRUTT SVENSKA AB BARNHUSGATAN 12, SE-111 23 STOCKHOLM, SWEDEN

PHONE +46 8 542 288 80 FAX +46 8 545 288 99 E-MAIL: [email protected] WWW.DRUTT.COM

Table of content

1 Introduction...................................................................................................................................3

2 Solving Business Problems.........................................................................................................42.1 Development Methodology..........................................................................................................4

2.1.1 Applied Extreme Programming.........................................................................................52.1.2 Summary and conclusions................................................................................................5

2.2 Common Systems Functionality..................................................................................................62.2.1 Drutt Framework...............................................................................................................62.2.2 Technical Highlights..........................................................................................................92.2.3 Summary and conclusions..............................................................................................15

2.3 Model Driven Development.......................................................................................................162.3.1 Drutt MGEN....................................................................................................................182.3.2 Technical Highlights........................................................................................................232.3.3 Summary and conclusions..............................................................................................27

2.4 Rendering..................................................................................................................................282.4.1 Drutt Rendering..............................................................................................................282.4.2 Oracle technologies used...............................................................................................292.4.3 Technical Highlights........................................................................................................302.4.4 Summary and Conclusions.............................................................................................31

2.5 Service Integration and Orchestration.......................................................................................322.5.1 Drutt 3PI..........................................................................................................................322.5.2 Oracle Technologies used..............................................................................................332.5.3 Technical Highlights........................................................................................................332.5.4 Summary and Conclusions.............................................................................................36

3 Remaining Hip.............................................................................................................................373.1 Summary and Conclusion.........................................................................................................37

© Drutt Corporation 2000, 2003 - All Rights Reserved

of 37

1 IntroductionThis paper presents some of the technical areas that should be of interest to anybody wishing to design and/or implement very high-volume middleware systems using Java.

We will provide an overview of the technical strategy and implementation tactics employed by Drutt Corporation for developing two main product lines for the Telco industry. We have been successful in the sense that we are a profitable software company in the mobile Internet segment, and our products are quite widely deployed and relatively unchallenged.

Since we have a marketing budget of zero, our success is largely due to engineering (and sales of course, something our CEO never tires of reminding us), but either way the purpose of this paper is to offer some insight into the mechanics of applied software development that really seem to work for us. Hopefully they can work for you too.

The following topics are of particular interest and will be covered individually: Development methodology. You may have heard of Extreme Programming, and to us

the most important aspect is incremental and frequent release cycles. This isn’t just a way of avoiding bloated code and dicey software projects (both worthwhile causes), but also important for maintaining a sound business.

Persistent objects. Yes, there’s an Oracle database at the heart of this, but quite a lot of logic is needed for optimization purposes. We’re constructing databases that have to support several millions of users. Drutt has developed a model generator that produces all persistent logic, and this along with the required runtime will be explained in detail.

Rendering. This is all about XML and XSLT, but again, although the Oracle XML parser provides essential core capabilities, designing a high-speed delivery pipe for millions of users is a challenge. Furthermore, one size does not fit all in this space, and we will discuss how to handle multiple content models and delivery channels efficiently.

Service integration and orchestration. This is all about interfaces and integration technology. This is a huge topic that includes favorites like CORBA, EJB, Web Services, etc. Drutt has chosen the narrow path here: keep it simple, make it fast, and make it very flexible.

Obviously, this paper will only scratch the surface of each topic, all of which individually merit substantial research.


of 37

2 Solving Business ProblemsAfter working 15+ years in the software industry, the number one insight we have gained is this: nothing beats solving a real business problem. To be a bit more explicit:

Developing awesome software that is not used for anything is no fun. What we mean here is that we have seen a lot of effort going into developing things that may be elegantly architected and well designed, but have no practical use.

Developing garbage that generates revenue is no fun. A common marketing axiom is that the best solution doesn’t always win, and this is often used as a pretext for throwing together a pathetic excuse for software and using a powerful marketing engine to sell it. Well, this may be a way of solving the problem "how do I maximize my short-term profits?", but it really has nothing to do with solving business problems for the customer, which is the theme of this paper.

Solving business problems means solving a real problem for a customer related to their business. We are software engineers, so we want to limit the number of problems (dramatically) by only considering the ones that have a reasonable chance of actually benefiting from involving a computer.

Well, in the rapid moving world of Internet technology, emphasizing the need of focusing on real customer problems doesn’t do much for your hip-factor. What it will do is keep your pay-checks coming. Starting out with that in mind, it may come as a surprise to learn that the technology involved in solving real problems can be pretty hip too. That’s what this paper is about.

2.1 Development MethodologyHere’s a great introduction to development methodology from "Extreme Programming – a Gentle Introduction" by Don Wells [http://www.extremeprogramming.org/light1.html]:

A software methodology is the set of rules and practices used to create computer programs. A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly. A lightweight methodology has only a few rules and practices or ones which are easy to follow.

In the late 1960s and early 1970s it was common practice for computer programmers to create software any way they could. Many programmers excelled at creating software too complex for anyone to understand. At that time it was a miracle if a program ran without any bugs. Making computers useful was considered a worthy quest and not unlike an adventure into the old west.

In 1968 Edsger Dijkstra wrote a letter to CACM entitled "GOTO Statement Considered Harmful". The central ideas of software engineering were being born. At that time we believed that bigger, more disciplined methodologies would help us create software with consistent quality and predictable costs. The lawless cowboy coders were being reined in.

The 1980s were good times for computer programmers. We had a few rules and practices to create software that was far superior in quality to what we were creating only a few years earlier. It seemed like if we could just create enough rules to cover the problems we encounter we could create perfect software and be on time. We added more and more rules and practices to cover all the potential problems.

Now in the 21st century we find these rules are hard to follow, procedures are complex and not well understood and the amount of documentation written in some abstract notation is way out of control. Trying to come up with a bigger and better methodology was like a California gold rush; everyone headed west only to be disappointed.


of 37

We created software to help us create software. But this quickly got out of control and dreadnought CASE tools were born. These tools, originally created to help us follow the rules, are too hard to use themselves. Computer programmers find it necessary to cut corners and skip important practices to stay on schedule. No one is actually following the heavy methodologies we have handcuffed ourselves with. The cowboys have returned and we find ourselves back at the OK Corral.

When programmers ignore the rules of their methodology they are instinctively moving away from heavyweight methodologies and back toward an earlier, simpler time of lightweight methodologies when a few rules were enough.

But we don't want to forget what we have learned. We can choose to keep the rules that help us create quality software and throw away those that hinder our progress. We can simplify those rules that seem too complex to follow correctly.

We don't want to return to the early days of cowboy coding when there were no rules at all. But instead let's stop at just enough rules to keep our software reliable and reasonably priced. Instead of cowboy coders we have software sheriffs; working together as a team, quick on the draw, armed with a few rules and practices that are light, concise, and effective.

Extreme Programming (XP) is one of several new lightweight methodologies. XP has a few rules and a modest number of practices, all of which are easy to follow. XP is a clean and concise environment developed by observing what makes software development go faster and what makes it move slower. It is an environment in which programmers feel free to be creative and productive but remain organized and focused.

2.1.1 Applied Extreme Programming

At Drutt, we are still trying to learn how to use the XP methodology. We have adopted the basic approach but are still cutting some corners. Our main focus to date has been on developing software incrementally with frequent releases: typically one major release per quarter plus one or two revisions per month.

In our view, XP encourages focusing on "solving business problems" very well. The first step in any XP project is to create a set of "user stories" that describe (in non-technical terms) how the system will be used. Functionally, this is similar to use-case analysis, but is much less formal and enables customers to participate actively.

Once the initial user stories are nailed, developers can start building test-cases that verify (the future) system’s behavior. This is a good approach for two reasons: first, it forces the developer into a state of mind where they have to focus on a (simple) solution rather than fancy technology, and second, it ensures that unit- and integration-testing can progress smoothly once the system is implemented, since the tests are already in place.

At this stage, coding can begin and enter the first of several short iterations towards a final release. One cycle is typically 3-4 weeks followed by a few days of testing and reviews (preferably with the customer).

2.1.2 Summary and conclusions

From a technical point of view, XP is a wonderful methodology that not only simplifies systems development greatly, but also tends to generate superior solutions (superior, because they are simple, lean, and to the point).

From a business perspective, our greatest difficulty is matching XP with market requirements for fixed-price consulting engagements. However, this can be managed by actually simulating a traditional project with detailed functional specifications. With detailed project specifications, a fixed price is easily negotiated.


of 37

So our conclusion, and this is somewhat counter-intuitive, is that XP is actually easier to implement in product development than in consulting, despite the fact that the benefits of using XP would seem greater in consulting.

Where to learn more about XP: http://www.extremeprogramming.org/ http://www.xprogramming.com/ http://www.xpdeveloper.com/ http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap http://www.xp123.com/xplor/

2.2 Common Systems FunctionalityAll software solutions have to deal with common systems functionality, and even if the Java platform has improved this functional area, there is still a gap to fill. Examples of common functional areas valid for each product component are:

1. Configuration2. Logging3. Persistence4. Error handling5. Version Tracking6. Monitoring and management

At Drutt we have an internal architecture to deal with these areas, and the software components are used in all of our product components.

2.2.1 Drutt Framework

The Drutt framework consists of well-known and verified design-patterns, and also of common implementations and APIs.

These components are not intended to be sales objects (i.e. "products") - their existence is simple motivated by a need to make Drutt software better and reduce the life-cycle cost of our products.

Everybody in the development organization is permitted to maintain and improve the framework, but only a couple of senior developers have the authority to approve changes and build new releases.

2.2.1.1 Configuration

A configuration manages a set of typed parameters, but there are also a couple of other aspects regarding systems functionality that need to be addressed. In Java there is no standardized pattern to manage configurations of components.

Even if J2EE has deployment descriptors, which can be used to configure components from a business point of view, this mechanism lacks the following important requirements:

Distinction between a locally defined and a default setting (fallback). Support of a "hot" re-configuration at runtime. A common factory pattern to plug-in different API implementations. Expression support to manage simple rules (transient closed). Support for different configuration locations: databases, files, URLs, etc.


of 37

http://www.xp123.com/xplor/

http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

http://www.xpdeveloper.com/

http://www.xprogramming.com/

http://www.extremeprogramming.org/

Therefore, J2EE descriptors are (by themselves) not suitable for configuration of dynamic business components.

Management of plug-ins is important since programmable logic needs to be supported from a configuration point of view, even if declarative parameters still are valid (see comparison between parameters and programmed logic below).

The diagram above illustrates the relative cost of one change with a specific complexity. As complexity increases, using parameters will make it harder and more expensive to maintain the functionality.

2.2.1.2 Logging

Logging functionality can be divided into the following areas:1. Activity log, compare to a Web Server CLF log.2. Error and/or debug log to be able to diagnose a malfunctioned component, compare to

Oracles process dump files.3. Trace, trace all systems activity.

All are of great importance, and common systems functionality can be utilized to manage different log destinations (database, file, syslog), but also to support creation of debug and trace logs.

For a developer, debugging tools are enough to really trace what’s going on in the system, but it’s always hard to connect an online debug tool to a production instance, and therefore it must be possible to dynamically activate debug and even trace logs for a limited amount of time.

Drutt has an internal log API (listener pattern), which can be highly customized according to customer requirements on format and messages, and also architectural support to create debug and trace logs (dynamically). The Java proxy pattern is used to generate a detailed trace of all method calls carried out by a component, and this proxy can be activated and deactivated dynamically by using the configuration pattern described above.

It’s also possible to plug-in existing implementations like Apache log4j (file logger) etc.


of 37

2.2.1.3 Persistence

Persistence is a functional area which is very suitable to encapsulate, and at Drutt we have selected the model-driven approach. See the section about Drutt MGEN for details.

Persistence is a bottle-neck in many systems. In fact, it’s probably the functional area containing most errors (sloppy programmers). Proper use of Oracle databases and standardized components such as JDBC can significantly improve the overall system behavior.

Important systems functionality:1. Optimized for the kind of transactions supported by the system.2. Batch all operations (read, write, update), i.e. piggy-back everything.3. Pool transactions and connections.4. Pool and re-use statements (cursors).5. Optimized sequence functionality.6. Robustness when database fails entirely.

Even if all of these areas are obvious, it remains a quite complex and error-prone area, and therefore all these functions shall be managed by the framework.

2.2.1.4 Error handling

The Java platform provides an excellent exception mechanism. The issue is whether to use checked exceptions or not. A lot of APIs use the checked exception approach, including J2EE, and the issue arises when linking in such components into an application: should the checked exceptions be propagated or not in the users API.

The simple conclusion is to not use checked exceptions (since at the top level all kinds of exceptions must be managed anyway). This rule is valid at least when the component is intended to be used by other components.

Typed exceptions are of course still valid, and all Drutt APIs throw a nested runtime exception to get rid of low-level checked exceptions, and an application exception of the type runtime is also declared to handle all known errors.

The Drutt framework also manages generation of error classes including an error code and a message with parameters.

2.2.1.5 Version Tracking

Although this seems to be a small issue, it’s essential when supporting the installed base.

Therefore the framework includes support to stamp versions during build time, and also report versions of all dependencies when executing the applications. The version is generated at build time and included both as a Java class in the actual JAR/WAR/EAR and also in the manifest file of the component.


of 37

2.2.1.6 Monitoring and management

Monitoring and management of application needs to be designed as well as other systems functionality. There are of course tools that can monitor an application at a macro and functional level, but to really be able to know what’s happening, the actual application must have knowledge about internal data structures.

The Drutt Virtual Network Management component includes;1. A customizable internal (embedded) agent.2. A proxy agent that connects several application agents to an external SNMP console

(Drutt MIB) or a Drutt Web console.3. Drutt Web console.

The agent samples information, and has built-in support to monitor health, transaction and state information including configuration. It’s also possible to manage the application and issue commands such as shutdown, reconfigure, enable/disable debug etc.

By using our own light-weight distributable objects, different kind of monitors can be defined by the client and these can be sent over to the application agent. The actual monitor listens (in-process) for the specific event and signal an event or SNMP trap back to the console when the condition has been met.

2.2.2 Technical Highlights

Configuration of a runtime component

Here is an example of a configurable component:

// Fragments...import com.drutt.util.*;import javax.xml.parsers.*;//public class ExampleImpl implements Example, Configurable { // config parameters static final String P_DB_FACTORY = "documentBuilderFactory.class"; static final String P_TIMEOUT = "timeout"; static final String R_XML = "xml"; static final String R_TRACE = "trace";

// configurable state. private DocumentBuilder documentBuilder; private int timeout; private boolean trace;

public void configure(Configuration config) {timeout = cpnfig.getInt(P_TIMEOUT);trace = config.getBoolean(P_TRACE);

// uses module xml, get config record Configuration c = config.getRecord(R_XML);

DocumentBuilderFactory df;df = (DocumentBuilderFactory) c.getFactory(P_DB_FACTORY).create(c);

// handle checked exception try { documentBuilder = df.newDocumentBuilder(); } catch (ParserConfigurationException e) {


of 37

throw new NestedException(e); }

// add to listener to receive configuration changes config.addListener(this); }}

The monitor tool view of a built-in VNM agent, used by SNMP proxy and other Drutt monitors:

import com.drutt.sdo.Distributable;

/** * VNM agent monitoring interface. <p> * * An agent is executed embedded into an application to be able * to externally monitor the application instance. It's possible to * bind several agents inside one Java VM, and all are identified * by an unique name. * * @author peter * @version $Revision: 1.10 $ */public interface Agent extends Distributable { /** * Returns the agent name. * * @return the unique agent name. */ String getName(); /** * Returns the hostname where this agent is executing. * * @return the agent hostname. */ String getHostName(); /** * Returns systems information. * * @return systems information. */ SystemInfo getSystemInfo(); /** * Returns request information. * * @return request information. */ RequestInfo getRequestInfo(); /** * Returns state information. * * @return state information. */ StateInfo getStateInfo(); /** * Pings the agent to check it's alive. <p> * * This method should be as fast as possible. */ void ping();


of 37

/** * Returns the agent uptime in millis. * * @return the agent/system uptime in millis. */ long uptime(); /** * Returns if this application is healthy. <p> * * It's up to the agent to implement the health check, and * the system is regarded as malfunction if the return code * not is equals to zero. <p> * * The health code is used as a specific trap value when * monitoring the agent by usage of SNMP. * * @return the health status code, 0 is the same as healthy. * an application must report a health code as a positive * integer larger than 20. The range 1..20 is reserved * for enterprise specific traps. */ int health(); /** * Schedules an application shutdown. * * @param seconds the seconds to wait until shutdown (>=1). * @param exitCode the exit code when terminating the application. * @return true if accepted, otherwise false. */ boolean scheduleShutdown(int seconds, int exitCode); /** * Returns if the debugging flag is set. * * @return true if debug flag is set, otherwise false. */ boolean isDebugging(); /** * Sets the debug flag. * * @param flag true to activate debugging, otherwise false. */ void setDebugging(boolean flag); /** * Returns if the system was successfully reconfigured. * * @return true if the system was reconfigured, otherwise false. */ boolean reconfigure(); /** * Adds an error request monitor. * * @param monitor the monitor. * @return true if accepted, otherwise false. */ boolean addErrorReqMonitor(CounterMonitor monitor); /** * Adds a notfound request monitor. * * @param monitor the monitor. * @return true if accepted, otherwise false. */ boolean addNotFoundReqMonitor(CounterMonitor monitor);


of 37

/** * Adds a processed request monitor. * * @param monitor the monitor. * @return true if accepted, otherwise false. */ boolean addProcessedReqMonitor(CounterMonitor monitor); /** * Adds an active request monitor. * * @param monitor the monitor. * @return true if accepted, otherwise false. */ boolean addActiveReqMonitor(CounterMonitor monitor); /** * Adds a session monitor. * * @param monitor the monitor. * @return true if accepted, otherwise false. */ boolean addActiveSessionMonitor(CounterMonitor monitor);}

The application (owner) view of a built-in VNM agent:

/** * Controls the VNM agent. <p> * * This API is intended to be internally used by the application, when * updating the actual agent state. * * @see SimpleAgent * * @author peter * @version $Revision: 1.1 $ */public interface AgentControl { /** Request success status. * * @see #requestEnd(int) */ int REQ_SUCCESS = 1; /** Request error status. * * @see #requestEnd(int) */ int REQ_ERROR = 2; /** Request not found status. * * @see #requestEnd(int) */ int REQ_NOTFOUND = 3; /** * Indicates that a session has been created. <p> * * This call must be followed by a <code>sessionEnd()</code> when appropriate. * * @see #sessionEnd() */ void sessionBegin(); /**


of 37

* Indicates that a session has terminated. * * @see #sessionBegin() */ void sessionEnd(); /** * Indicates that a request has begun. <p> * * This call must be followed by a <code>requestEnd()</code>. * * @see #requestEnd(int) */ void requestBegin(); /** * Indicates that the request has finished. * * @see #REQ_SUCCESS * @see #REQ_ERROR * @see #REQ_NOTFOUND * * @see #requestBegin() * * @param status the status of the request. */ void requestEnd(int status);}


of 37

Example of Web monitoring tool (main page):


of 37

Example of web monitoring tool (agent page):


Drutt software products share specific systems functionality by using a common framework, which really increases the overall quality of each component.

Even if the Java platform provides tons of "best of breed" components, there is still a lack of standards regarding common systems functionality.

Drutt´s framework has been designed to fill in this gap, and is valid for all classes of applications. It’s foundation is primarily a collection of systems functionality, and all members of staff participate in the maintenance process.

It creates a safe and stable foundation for our developers, since everybody knows exactly how an application is basically designed, and thus how it can be monitored and operated.


of 37

Its existence is motivated simply by the fact that it makes Drutt software better, and reduces the life-cycle cost.

2.3 Model Driven DevelopmentFor us old-timers that have spent considerable amounts of energy struggling with various proprietary database APIs such as Oracle’s OCI, JDBC represents a dangerous lure, because at first glance, it is obviously a much simpler and cleaner interface than OCI and also hides the gory details of the language-neutral database from a Java programmer.

It’s a dangerous lure, because if you think that the main challenge in database programming is understanding SQL and mastering a language-specific API (such as JDBC), you’re missing the point.

From the very start, even before relational database technology was invented, good programmers understood that separating application logic from data access was an essentially good practice. Whether this was actually done or not is of course a completely different question.

The database access layer encapsulates the database API and provides higher-level functionality.

Also, at the time most system being developed used a simple client-server architecture (where the server was in fact a database), and it was obviously better to implement business rules in a central database than in a multitude of clients. Hence referential integrity features and database programming languages such as Oracle’s PL/SQL were introduced in the database engine itself.

Two important things happened in the mid-90s: first, the web, and in this context the most important impact was that it signaled the start of the "middleware era" in software development, and second, Java as a programming language, object model, and runtime environment was introduced. Both had a profound impact on how software was to be developed, but of the two, moving towards a 3-tier runtime architecture was probably the most important step, at least in the context of model-driven development, because the most important aspect of using middleware is that business logic gets moved into the middle tier.

Why is it so? There are several reasons: first, middleware is needed in order to scale up beyond the capacity of a single database, and one thing we really want to avoid at runtime is having to access the database every single time a business rule needs to be checked or verified. Second, in an object-oriented application, database functions such as select, update, delete, and insert, are viewed as methods belonging to the inner workings of a persistent object. So instead of a single data-access layer used by each application, every single persistent object needs to contain its own "persistent implementation", i.e. database access.


of 37

Application ApplicationApplication

Database access layer

Database API

Now, there are several ways of implementing this. The clean object-oriented approach is to simply treat the entire object as a single binary BLOB, which can be serialized to a persistent storage (i.e. database). This is a trivial case and is standardized in Java Enterprise Beans. The main benefit of this approach is that it is simple to use (all responsibility for persistence is delegated to the EJB container). The main drawback is that the object is completely opaque – it can only be accessed by de-serializing it first and then invoking its public methods.

Another approach referred to as "object-relational" is to create a mapping between a persistent object and one or more tables and/or table-rows in a relational database. This can be done manually, or it can be done with a model and a code-generator. The latter is what we use at Drutt.

Unified Modeling Language (UML), a trademark of the Object Management Group (OMG), has become the standard for describing an object model. Or to quote IBM Rational: "The Unified Modeling Language™ (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, making a "blueprint" for construction."

Old-timers will often say "show me the table-design and I’ll tell you how the system works". Today, the same can be said about UML models.

After a somewhat lengthy introduction, we’ve finally reached the main topic of this section: model-driven development (MDD). Drutt MGEN is a code-generator that we have developed for use in all products that use persistent objects.

Commercial products are also starting to become available, and a standardization effort is happening in the OMG called MDA – Model-Driven Architecture. So why do we have our own? Here are the main reasons:

It allows us to fully optimize the code for the type of transactions that we want to prioritize, namely access data very, very fast.

It leaves us in full control of the data-access layer. This is only a valid reason if you’re very good at what you do. We think we are.

It minimizes risk. Yes, there are also emerging products such as OMG’s MDA and Oracle’s Toplink, but we’ve been doing this for years.


of 37

Persistent Object


Database API

Persistent Object


Database API

2.3.1 Drutt MGEN

Drutt MGEN is an embedded technology in all of our products. The first step is to design the persistent object model using a UML design tool such as Rational Rose or Nomagic’s Magic Draw. Here is a simple example in the spirit of Oracle’s age-old emp/dept sample:

As mentioned earlier, if you spend a few minutes studying the model, you can pretty much deduce exactly what this system is capable of doing – even if you’ve never seen an object model before.

This model can be exported in a standard format containing both the object model as well as the graphical layout of the model. It’s a very, very long XML file, so as an example, here’s a small excerpt that defines the surname attribute of the Employee object:

 <Foundation.Core.StructuralFeature.type> <Foundation.Core.Class xmi.idref="x_1050409103305_286993_447"/> </Foundation.Core.StructuralFeature.type></Foundation.Core.Attribute>

<Foundation.Core.Attribute xmi.id="x_1059482245435_335489_1288"> <Foundation.Core.ModelElement.name> surname </Foundation.Core.ModelElement.name> <Foundation.Core.ModelElement.visibility xmi.value="public"/> <Foundation.Core.Feature.ownerScope xmi.value="instance"/> <Foundation.Core.StructuralFeature.multiplicity> <Foundation.Data_Types.Multiplicity xmi.id="x_1059482953525_542930_1531"> <Foundation.Data_Types.Multiplicity.range> <Foundation.Data_Types.MultiplicityRange xmi.id="x_1059482953525_208735_1532"> <Foundation.Data_Types.MultiplicityRange.lower>

-1 </Foundation.Data_Types.MultiplicityRange.lower> <Foundation.Data_Types.MultiplicityRange.upper>

-1 </Foundation.Data_Types.MultiplicityRange.upper> </Foundation.Data_Types.MultiplicityRange> </Foundation.Data_Types.Multiplicity.range>


of 37

</Foundation.Data_Types.Multiplicity> </Foundation.Core.StructuralFeature.multiplicity> <Foundation.Core.StructuralFeature.changeability xmi.value="changeable"/> <Foundation.Core.StructuralFeature.targetScope xmi.value="instance"/> <Foundation.Core.StructuralFeature.ordering xmi.value="unordered"/> <Foundation.Core.Attribute.initialValue> <Foundation.Data_Types.Expression xmi.id="x_1059482953525_416345_1533"/> </Foundation.Core.Attribute.initialValue> <Foundation.Core.Feature.owner> <Foundation.Core.Class xmi.idref="x_1059481655720_696947_1060"/> </Foundation.Core.Feature.owner> 

This XML file is an XMI (XML Metadata Interchange) application, and before generating any code, Drutt MGEN generates an intermediate XML file that contains a relevant subset of the XMI definition. This intermediate file is much more compact – here’s an excerpt:

<interface name="Employee" stereotype="persistent" abstract="false">

<association id="x_1059482025007_377085_1221" name="Company" role="" type="S" interface="com.drutt.example.Company"/>

<association id="x_1059488500052_169436_238" name="boss" role="" type="S" interface="com.drutt.example.Manager"/>

<attribute name="firstname" public="true" read-only="false" write-only="false" type="java.lang.String"/>

<attribute name="surname" public="true" read-only="false" write-only="false" type="java.lang.String"/>

<attribute name="address" public="true" read-only="false" write-only="false" type="com.drutt.example.Address"/>

</interface>

This file is used to generate several files, including template factories and lookup classes. For each persistent object, 3 files are generated. For example, the 3 files for the Employee object are:

Employee.java, which is the public interface – this defines which methods and attributes are exposed.

EmployeeGen.java, which is an abstract class that implements the Employee interface and contains all the logic needed for persistence (i.e. database access).

EmployeeImpl.java, which is a skeleton implementation of the Employee object. It extends the abstract EmployeeGen class (and implicitly implements the Employee interface). This is where you have to actually write code that does whatever this object is supposed to do.

The class hierarchy is as follows (using O’Reilly’s "nutshell notation":


of 37

The generated code for the Employee interface is shown below.

//// Generated file at Tue Jul 29 16:51:21 CEST 2003 (lansler)//// MGEN Version: Drutt Model Generator 2.0.1 Tue Jun 17 09:39:00 WEST 2003// By: com.drutt.mgen.basic.IfVisitor// Source: core.xml// Target: Employee.java//// Copyright (c) 2002, 2003 Drutt Corporation, all rights reserved.//package com.drutt.example;

import com.drutt.mgen.arch.Persistent;

// No comment.public interface Employee extends Persistent {

// No comment. String getFirstname(); // No comment. void setFirstname(String firstname); // No comment. String getSurname(); // No comment. void setSurname(String surname); // No comment. Address getAddress(); // No comment. void setAddress(Address address); // No comment. Company getCompany(); // No comment. void setCompany(Company company); // No comment. Manager getBoss(); // No comment.


of 37

Employee

com.drutt.mgen.arch com.drutt.example

EmployeeImplEmployeeGenAbstractPersistent

Persistent

void setBoss(Manager boss);}

The interface contains set/get methods for all attributes of the persistent object. The implementation for all of these are in the EmployeeGen.java file. Additional methods can be added manually, and should be implemented in the EmployeeImpl.java file shown below.

//// Generated file at Tue Jul 29 16:51:21 CEST 2003 (lansler)//// MGEN Version: Drutt Model Generator 2.0.1 Tue Jun 17 09:39:00 WEST 2003// By: com.drutt.mgen.basic.ImplVisitor// Source: core.xml// Target: EmployeeImpl.java//// Copyright (c) 2002, 2003 Drutt Corporation, all rights reserved.//package com.drutt.example.impl;

//public class EmployeeImpl extends com.drutt.example.gen.EmployeeGen { // protected EmployeeImpl(com.drutt.mgen.arch.Manager mgr) { super(mgr); } // protected EmployeeImpl(com.drutt.mgen.arch.Manager mgr, com.drutt.mgen.arch.Id id ) { super(mgr, id); }}


of 37

In addition to the Employee interface, the Employee object also extends the MGEN AbstractPersistent class, providing methods such as delete(), lock(), save(), load(), etc.

Below are som sample code fragments showing how the generated interfaces and classes are actually used.

The first example shows how MGEN is bootstrapped. First, a configuration is created using standard Java properties (which can either be loaded from a configuration file or hard-coded elsewhere), and then a transaction-manager and factory for creating objects are created (these are also generated by MGEN by the way):

.

.

.// Bootstrap MGEN...Configuration conf = ConfigurationFactory.createConfiguration(props);

ExampleManager manager = new com.drutt.example.impl.ExampleManagerImpl();manager.configure(conf);ExampleFactory factory = manager.getExampleFactory();...

Once MGEN has been initialized, it’s fairly straightforward to use. The next example shows how a new instance of Company is created (and saved). Note that the transaction-manager is used to begin and end the transaction, and the factory is used to create the actual object.

.

.

.// start the MGEN transaction...manager.beginTransaction();

// Create a company (persistent DB type)Company drutt = factory.createCompany();drutt.setName("Drutt Corporation");drutt.setType(CompanyType.SOFTWARE);

// commit and end MGEN transactionmanager.endTransaction(true);...


of 37

The last example show how a pre-defined "query" is performed by using the factory:

.

.

.// a “poor” structured example

// start the MGEN transaction... manager.beginTransaction();

boolean rc = false;CompanyLookupService cls = manager.getCompanyLookupService();

// find all software companies...try {Company[] swCompanies = cls.getBranchCompanies(CompanyType.SOFTWARE);System.out.println("Available software companies: ");for (int i=0; i < swCompanies.length; i++) {

System.out.println(swCompanies[i].getName());}rc = true;

} catch(Exception e) {// exception occurred, do something useful

} // end and commit (if necessary) the MGEN transactionmanager.endTransaction(rc);...


Simple modeling approach (OOD)

Just declare the interfaces with information and additional methods to be implemented by the application programmer. It’s possible to model even more than the persistent part, since the generator just processes "known" stereotypes.

Distinction between generated and architectural code

Even if the code is completely generated it still relies on a specific architecture. The generated and architectural part are separated by a well defined and internal API. Architectural code includes all the tricky stuff and optimizations, and can be maintained and patched separately from the generated code (as long as the API is stable).

Pluggable generator

As an example, the implementation can easily be migrated to standardized EJB session and entity beans, but currently EJB is not a subject to be used by our internal architecture.

The generator is pluggable (using the visitor pattern), and it’s possible to override the default, and create other specialized code generators. As an example, a JSP taglib generator exists to list and manipulate model information in JSP pages. See JSP example of usage of a generated taglib below:


of 37

// Fragments (Use generated taglib code for listing of a model object)...

<%@ taglib uri="/WEB-INF/example.tld" prefix="model" %>

<% String nameExpr = request.getParameter(“ne”); %>

<model:transaction commit='false'> <h2>Employees</h2> <table> <tr> <td>Firstname</td> <td>Lastname</td> <td>City</td> </tr> <model:ListEmployees instance='r' firstname=’<%= nameExpr %>’> <tr> <td><%= r.getFirstname() %></td> <td><%= r.getLastname() %></td> <td><%= r.getAddress().getCity() %></td> </tr> </model:ListEmployees> </table></model:transaction>

Generates everything

SQL Schema, binaries, javadoc, and default implementation JARs, which can easily be included in an IDE tool.

$ java –jar mgen.jar

Drutt Model Generator 2.0.2 Thu Aug 14 14:41:42 WEST 2003usage: java –jar mgen.jar [ options ] gen1, ..., genNoptions:-m: model definition (XML: <model/> or <XMI/>), mandatory-d: output directory, default is ./mgenout, optional-c: compile & build JAR archive, optional-o: alternate output archive basename (no extension), default is <model>,

optional-x: extended classpath, optional-f: manifest file, optional-v: verbose, optional

Each generator is added as a fully qualified Java class name

$ java –jar mgen.jar -m ../model/mgen_example_model_md.xml -cv -o model \ com.drutt.mgen.basic.BasicVisitor

Parsing Model (..\model\mgen_example_model_md.xml).Generating Source Code (.\mgenout).Build archive (model).Collecting source files done.Compiling sources done.Building archive (model.jar) done.Generating java docs done.Building docs (model_doc.jar) done.Building implementation source (model_src.jar) done.

Successfully completed.


of 37

Override/customize everywhere and anything

It’s possible to change implementations everywhere in an object hierarchy, and all generated components for a module including manager, factory, service, persistent, and complex datatype objects can be extended and overridden by the implementation project.

Execute immediate

The generated code is ready to be executed immediately. If a method which has not yet been implemented is called, an exception is thrown to inform about the condition.

In this manner the application logic can be incrementally implemented and tested.

Typed architecture

A typed architecture makes the APIs more clear, and it’s almost impossible for application programmers to introduce elementary errors.

One benefit using code generators is to maintain typed architecture. When implementing such a pattern manually a typed architecture often ends-up in a lot of "copy & paste" programming.

Supports database referential integrity

If required, the database information can be secured by usage of referential integrity.

Supports Opaque datatypes (BLOBS)

The architecture include it’s own Opaque datatype, which is a portable BLOB concept hiding the JDBC complexity. Though, Opaque is not applicable for streaming of very large binary data.

Individual configuration of modules

Each module has an entry point, Manager, locating the factory and default find operations.

Each module/package can be separately configured/tuned even if they are running in the same process space, and shares the same database.

// Fragments...

import com.drutt.example.*;import com.drutt.util.*;

public class EnvironmentImpl {private ExampleManager mgr;

//void configure(Configuration cfg) {

// instansiate and configure the example managerConfiguration exc = cfg.getRecord(“ex”);mgr = (ExampleManager) exc.getFactory("manager.class").create(exc);

}...


of 37

Example of using configuration parameters to configure and control a persistent module:

# module managers (entry point)

# example module, exex.manager.class = com.drutt.example.impl.ExampleManagerImpl

# architectural stuff for module "ex"

# plug-ins (use defaults)ex.arch.connectionFactory.class = com.drutt.arch.impl.DefaultConnectionFactoryex.march.transactionFactory.class = com.drutt.arch.impl.DefaultTransactionFactoryex.march.sequence.class = com.drutt.arch.impl.DefaultSequence

# enable a lot of trace#ex.march.trace = true

# enable db connection check (handle server failures)#ex.march.validateDbConnection = false

# pool size, set to -1 to use on external thread poolex.march.transactionPool.optimalSize = 10

# jdbcex.march.jdbc.driver = oracle.jdbc.driver.OracleDriverex.march.jdbc.connect = jdbc:oracle:thin:peter/peter@aries:1521:cdev


of 37

Type and model safe query language

MGEN includes a type and model safe query language, syntax control at compile time.

// Fragments...

import com.drutt.mgen.arch.*:import com.drutt.example.*;

//Employee[] findEmplyeesByCityExpr(String cityExpr) {Query query = MetaModel.EMPLOYEE.createQuery();

query.likeIgnoreCase(MetaModel.EMPLOYEE.ADDRESS.CITY, cityExpr);query.orderBy(MetaModel.EMPLOYEE.NAME);

// manager instance is kept somewhere in app environment.ExampleManager mgr = Env.getInstance().getManager();

return mgr.findEmployees(query);}...


If an organization builds a general class of business applications, a model driven approach combined with a code generator significantly increases the productivity. As a matter of fact at Drutt the return of investment was immediate (first project). Drutt has also tremendously increased the overall systems quality, systems performance and development speed.

However, it’s much harder to find or create the one and only tool (golden hammer), suitable for all classes of applications.


of 37

2.4 RenderingSeparating presentation from application logic is probably one of the oldest patterns in the book. There are numerous ways of achieving this in Java, for example by using the model-view-controller pattern, typically implemented by using a combination of Java Server Pages (JSP), Java Servlets, and backend components, e.g. Enterprise Java Beans or CORBA objects.

In our case, we almost never have control over the complete application, but instead typically are asked to extend existing systems with "smarter" rendering technology, that will enable application interfaces to be presented optimally on a large range of devices, ranging from very small, memory-constrained cell phones to high-end PDAs with high-resolution displays and full keyboard and mouse support.

Our prerequisite for this is that one or more XML-based content models are used to represent presentation data. This enables us to use XSL transformations (XSLT) to dynamically generate the user-interface on demand.

It’s not rocket-science, but there are a couple of surprises awaiting anybody that attempts to do this: There is no standard content model. There is no standard client.

2.4.1 Drutt Rendering

It is reasonable to consider Drutt Rendering as the world’s leading rendering platform based on any of the following metrics: license revenue, deployed production sites, or number of users. Runner-ups include companies like Volantis, Mobile Aware, and Apache Cocoon, and we are happy to participate in any head-to-head comparison of both technical and financial aspects.

Drutt Rendering consists of three major components, which in turn may be deployed individually or combined. They all use standard interfaces and are easily integrated with existing service-delivery platforms. The components are:

Drutt Device Server, a HTTP request proxy and XSLT engine designed to seamlessly front-end any application or content-management system.

Drutt Image Server, a HTTP and/or SOAP server providing transcoding services for binary content such as pictures, photos, and other media-clips.

Drutt Device Repository, a database of device profiles defining rendering directives to be used for example during XSLT transformations. Directives can certainly be based on UAProf, but there is an important distinction between considering what a device is capable of doing, and what you actually want it to do. Drutt subscribes to the latter approach.

All three components are implemented as light-weight Java servers and can be deployed either standalone or wrapped in J2EE containers. Due to smart caching, pre-fetching, and other optimization techniques, Drutt Rendering can often service loads in the order of ~500 requests per second per CPU, but for sizing purposes, we recommend using a conservative estimate based on pessimistic cache hit-ratios around 50 requests per second per CPU. These metrics are based on real customer applications in production environments.

Rendering includes a lot of features in the following main areas. (an excerpt); Proxy

o Device specific cookie/session management.

o Device specific redirect handling.

o Service control.


of 37

o Delivery confirmation (ticket based charging).

o Access control.

o Device specific chunking, large results divided into smaller pieces with intra navigation.

o Pre-fetch and caching of binary content.

Images. Video clips. Applets. Sound.

o Caching.

Markup content. Binary content.

Transformation.o XSL access to the rendering API containing templates and parameters. An

example is the device profile of the actual request.o Manages several fine-tuned processing chains depending on the calling device and

the content type to process.o Bundles all applicable DTDs.

o Device specific image processing.

o Device specific declarative control in XSL by access to the profile of the requesting device.

o Has specific functionality to manage the following target formats.

WML. XHTML. Multi-part application/vnd.wap.multipart.mixed.

2.4.2 Oracle technologies used

Oracle XML Parser is central and essential to the functionality of Drutt Rendering. It was chosen because it is the best XML parser (and XSLT processor) on the market.

Oracle iAS is used as J2EE infrastructure whenever possible. One problem that we have faced is that the customer almost always considers the choice of J2EE infrastructure as a decision for them to make, which has resulted in numerous deployments on other (competing) platforms (Apache Tomcat, BEA WebLogic Server, etc.)

Oracle RDBMS (any version) is optionally used in configurations that require persistent sessions (this is uncommon).


of 37


XSL API

The XSL API provides rendering functionality to the XSL programmer.

Example of how to access a device profile property. Declarative control XSL of logic.

<!— Device profile properties are retrieved by usage of the DR variable provided by the rendering engine. --> <xsl:if test="not(Boolean($DR/Browser/Back))"> <template> <do type="prev" label="{$DR/Caption/Back}"><prev/></do> </template></xsl:if>

Example of how usage to adapt an image with device profile parameters retrieved from the device repository.

<xsl:template match="Image"> <img alt="{@alt}"> <xsl:attribute name="src"> <xsl:call-template name="D-RewriteImageURL"> <xsl:with-param name="src" select="@target"/> <xsl:with-param name="commands" select="$DR/ImageCmd"/> </xsl:call-template> </xsl:attribute> </img></xsl:template>


of 37

Device Repository

Administrate device profiles by usage of a graphical user interface.

Develop with best-of-breed third-party tools

Rendering can be hooked into XMPLSY™ by Altova, which is an excellent IDE tool to develop XML and XSL (plug-in).

The YOSPACE™ emulator is another commonly used development tool, used to emulate handsets.

2.4.4 Summary and Conclusions

Drutt rendering is the best-of-breed rendering engine with a proven installed base.

It’s primarily targeted for large telcos with focus on brand and delivery of handset services.

XML and especially Oracle XML/XSL technology has played an important role to achieve the current position on the market.

Drutt rendering is easy to integrate. The engine is placed in front of the content management system, and uses HTTP as the main back-end access protocol. Alternative deployment configurations like a servlet filter also can be configured.


of 37

2.5 Service Integration and OrchestrationService Integration is a subset of a much broader topic called "application integration" or EAI (Enterprise Application Integration). It's a subset because "services" in the context of the mobile internet are still very small and simple compared to what we have come to expect in enterprise computing and e-commerce applications. Here are two examples of services:

A "normal" service: a user requests a weather forecast by issuing a WAP request from a cellphone. The forecast is delivered as a WAP deck containing text and links to images.

A "complex" service: a user requests a ring-tone by issuing a WAP request. The ringtone is transmitted as a binary-encoded SMS and the user is charged via the billing system.

As you can see, this is nowhere near the complexity of for example creating purchase orders in business-to-business scenarios, where technologies like EDI are still essential.

Instead of focusing on technologies that have been at the core of EAI for years, such as persistent queuing, guaranteed delivery, distributed transactions, etc., we have taken a more "extreme programming" type of approach to service integration, i.e. we have focused on addressing the actual problems encountered by service providers (telcos) and content providers (business partners with services that need to be integrated).

There are of course a lot of obvious things that need to be taken care of by a service integration layer, for example basic proxy capabilities and also lots of administrative routines for managing partners and their services. But somewhat surprisingly, the number one business problem that we have addressed is this: can a service provider avoid managing a large content management system on behalf of partners?

This is surprising, because it's how we usually imagine how things are done. There's even a name for it: content aggregation, which implies that content is aggregated from multiple sources and then presented in a uniform manner to the end-user.

Well, it just so happens that it's very complex and expensive to aggregate content, and if it can be avoided, that's a good thing. So that's what we've chosen to focus on. Therefore, to us, service integration is further constrained to mean "real-time, synchronous application integration" using a standard proxy-pattern.

That is not rocket-science.

2.5.1 Drutt 3PI

Drutt Third Party Integration (3PI) provides ONE seamless integration point for all kinds of services - regardless of the application, regardless of the input format, regardless of the delivery channel or output format. It is a well proven and mature product, used by the world's largest operators.

Drutt 3PI is based on the concept of mobile operators and content partners sticking to their core: the mobile operator authenticates a user, displays the service, add capabilities like billing and location and grants its optimal presentation in every kind of device. The partner executes the service on each request. Hence, the operator does not have to take responsibility for the application data and logic, the partner does not have to become a mobile expert.

In summary, Drutt 3PI offers the following functionality: One point of integration for all services and delivery channels. Support for multiple partner content formats (e.g. XML, WML, cHTML etc). Distribution of multiple media formats (images, sounds, clips, streams, device

applications).


of 37

Access to multiple interactive distribution channels (WAP, WEB). Full messaging support over a multitude of channels (e.g. SMS, MMS, WAP-Push). Push and pull services, subscription services. Authentication of users. Access to value added services (billing, device dependent rendering, personalization

information, location etc). Consistent look-and-feel of all services, based on a defined layout model. Co-branding, revenue share. Service configuration, testing and development.

2.5.2 Oracle Technologies used

Oracle XML Parser is central and essential to the functionality of Drutt 3PI. It was chosen because it is the best XML parser (and XSLT processor) on the market.

Oracle iAS is used as J2EE infrastructure whenever possible. One problem that we have faced is that the customer almost always considers the choice of J2EE infrastructure as a decision for them to make, which has resulted in numerous deployments on other (competing) platforms (Apache Tomcat, BEA WebLogic Server, etc.)

Oracle RDBMS (any version) is used for managing all persistent objects (see the section model-driven development).


Service Orchestration

The internal orchestration is based on a generic filter engine similar the J2EE servlet filtering mechanism, and even more similar to the Apache Struts concept, but the APIs and filter-chain management is designed to fit the context of the 3PI business logic, rather than the more technical request/response pattern. Also the final application can be used in several kinds of technical deployment configurations.

The actual processing pipeline, filter chain, can be created statically and/or dynamically controlled by business logic. Of course it’s possible to assign specific filter-chains to different kinds of third-party services.

Note: Any of the filter components may have the task to actually invoke the third-party service by usage of an appropriate protocol.


of 37

Filter API

/** * A class implements the <code>Filter</code> interface to indicate * that it may filter a {@link com.drutt.dfe.Context} object. <br> * Initialization of the implementation instance is done by usage of * the configurable pattern. <p> * * Filter complexity may vary, but should have definable bounds, * predictable behavior, and preferably a bounded execution time. <p> * * Example: * <ul> * <li>Log Request</li> * <li>Fetch content via HTTP</li> * <li>Transform XML</li> * </ul> * * @author rlindsjo * @version $Revision: 1.3 $ */public interface Filter { /** * Apply this filter to the context. * * @param context to filter */ void filter(Context context); /** * Shutdowns the filter. * * Signal stat this filter instance will no longer be used. Suitable to * teardown logic. */ void shutdown();}


of 37

Example of a database/model transaction application filter:

// Fragments...

public class ExampleTransactionFilter extends AbstractFilter implements ContextListener, Configurable { /** Commit upon successful transaction (config). */ private boolean commit;/** Persistent manager of the application. */private ExampleManager mgr = Env.getInstance().getExampleManager();

// DB transactions cannot be done until this filter has been executed. public void filter(Context ctx) { mgr.beginTransaction(); ctx.addContextListener(this); }

// Called when a context is closed (goes out of scope). public void closed(Context ctx, boolean error) { mgr.endTransaction(!error && commit); }

// public void configure(Configuration config) { this.commit = config.getBoolean("commit"); }}

Administration and third party self-management tool

PC Web application to manage third party service providers and their services; work-flows, deployment, and testing. The main actors are the systems administrator (named portal owner), and the third-party service administrators (named providers)).


of 37

2.5.4 Summary and Conclusions

Drutt 3Pi is a fairly narrow interpretation of "application integration", but although it lacks many of the "standard" functions and interfaces found in commercial middleware, it has enjoyed tremendous success throughout our customer base. The main reason for this is of course that the whole internal architecture is extremely flexible and can very quickly be adapted to the exact needs of every customer.

Having said that, the one thing that we feel speaks for itself is the installed user base - our largest customer alone has hooked up over 600 content providers via Drutt 3PI (over the public Internet), and it accounts for over 60% of all traffic.


of 37

3 Remaining HipThe word "hip" is of course completely subjective, and we used it in this paper as a bit of a joke - partly to grab attention, but also to illustrate that just about any software projects can be viewed as being "hip" - at least by somebody. Well, having said that, we will just put a stake in the ground right now and tell you what we think is hip about the way we're solving business problems for customers. You are of course free to completely disagree!

Java is hip. XML is hip. XSL is hip. Model-driven development is hip. Persistent objects are hip. Pluggable components are hip.

The funny thing is that if we had developed our solutions in COBOL on a mainframe, that would probably have been hip too. So although you may be nodding your head to the list above, agreeing that these are indeed hip technologies, the truth may very well be that the "hipness" lies elsewhere.

Perhaps it's just the simple but often overlooked fact that building useful software that actually works really well just doesn't happen very often. The fact of the matter is this: we didn't "choose" to use any of these "hip" technologies - rather, they were simply a natural choice for solving specific business problems.

3.1 Summary and ConclusionDuring the past 3 years at Drutt, we have had the opportunity to develop several solutions for large operators and service providers. A key point is that we have remained focused on solving their business problems as opposed to attempting to invent clever shrink-wrapped products. Well, we've tried to do that too, but it's been a secondary objective.

Surprisingly, by taking customer requirements very seriously and focusing on "just" solving the problems, we have gradually evolved a very hip infrastructure and some pretty cool products. Note that this has been secondary - we never sat down and did a detailed market-analysis, long-term product-planning, or anything like that. Instead, our products have evolved gradually and incrementally according to the Extreme Programming methodology.

We think this is the key point today: Extreme Programming. It not only forces us to focus on solving customer problems, but almost more importantly prohibits us from introducing additional technology (and thus complexity) when it is not needed. This is absolutely essential.

A good example is Web Services. Yes, the technology and standardization efforts surrounding Web Services are beautiful, but on the list of business problems that we need to solve in the area of service integration, introducing a vendor-neutral and standardized interface for remote services is just not at the top of the list. We have 600 companies delivering services via Drutt 3PI today - proof that we have solved a real business problem, and although we actually have gone ahead and wrapped 3PI in a Web Services interface, there's simply no real demand for it (yet). That will probably change over time.

So at the end of the day, perhaps the best definition of "remaining hip" is "keeping it simple". Simple solutions are inherently elegant, and Extreme Programming seems to promote them.

In retrospect, this paper could just as well have been named after the famous acronym "KISS - keep it simple, stupid".


of 37

Solving Business Problems and Remaining Hip -...

Documents

Transcript of Solving Business Problems and Remaining Hip -...