Don’t repeat yourself – this is one of the oldest principles in information technology.  The inventions of subroutines, classes, and modules are all related to reuse, which means avoiding duplicating things over and over again. If you do duplicate programming language code in a 3GL, something might be wrong with your design. If you do duplicate XML fragments or files in your SOA, something might be wrong with your design, too. Unfortunately, this is sometimes exactly the thing you have to do.

Why is that? BPEL processes don’t support inheritance or aspect weaving (yet). This way, similar process will look very similar, and you will end up with lots of duplicated XML code. The same is true in OSB Proxy Services (until Oracle gives us a template or inheritance mechanism). Another example are configuration files like SOA Suite configuration plans. If you have one such configuration plan per composite, chances are they look very similar. Generally speaking, it is harder to follow the DRY principle in an XML world. There are no generic modularization and reuse concepts, not even a generic “include” mechanism for XML files. You can use an XSLT transformation to combine common XML code with specific XML code. But you would have to edit the separate XML files manually since graphical editors can only write single files.

Think again

Whenever you have the feeling you are copying files or XML fragments over and over again, think again. Is it really necessary? What are the implications for maintainability? Can you avoid it? If you can’t avoid copying things, at least try to automate this process. This will save you some time, and even more important, makes the intent of having the content in multiple locations clear.