0

I have been given the task of redeveloping an "in house" solution to make it expandable and easier to maintain and administer.

The original solution had been hashed together over time using PHP as more requirements were added, and the need to expand is expected into the foreseeable future.

The solution, gathers many different files such as word documents and varying structures of XML document, from different "locations" and converts each into a specifically structured XML documents which get sent on via a web service. To add to the mix, some of the original XML files are retrieved from the same "location" but have varying levels of processing that are required depending on where they are from before that (identified by a "customer" field in the XML)

My intention is to make the new solution as modular as possible so that processing can be suspended at the individual "customer" or "location" level without affecting anything else.

While I have many puzzles to overcome and questions to answer, the question that is keeping me up at night at the moment is "Where should the processing to the structured XML be done?" At present it is done per "customer" but as you can imagine, it leads to a lot of duplicated code. Maybe it is unavoidable, due to the "customer" specific processing required sometimes but sanity tells me there must be a better way.

1

My advice would be to invest in learning XSLT (I found a decent tutorial from the perspective of a PHP programmer here). While it's true you could probably accomplish the same thing using only PHP, it could get quite messy.

To describe XSLT briefly, in XSLT you define a list of rules which are activated according to the specificity of the XPath used to describe which nodes are affected (very specific nodes described by the xpath have higher priority over more generic rules). It allows you to transform XML into anything, including XML which, you guessed it, means you can perform separate operations if you wish. You can also define rules which activate only when certain nodes are available so for example, if you wanted to apply transform using the customer or location, you simply wouldn't provide information pertaining to anything else, and the corresponding rule does not activate.

If you wanted to move the logic to the web service, XSLT is supported in virtually any language that supports XML itself. In any case, this should offer a clean solution that allows you to use a proper technology for handling these types of situations.

  • Good point, but where should the XSLT be called from? – FrustratedWithFormsDesigner Jun 11 '13 at 18:44
  • I think the point is that XSLT can be performed in a web service or in PHP where the request is made. It offers the flexibility to work in either case. If the web service is there merely for performing this operation, you could do away with it and concentrate on using XSLT in PHP directly instead. – Neil Jun 12 '13 at 10:11
  • I guess I understood the question more as a higher-level architecture one, as in: "In which of these systems does it make the most sense to do the transformation (whether it is in code or XSL)?" – FrustratedWithFormsDesigner Jun 12 '13 at 13:56
0

You mention that all of this XML goes to a common web service, so one option would be to have the processing happen there. Of course, this would require changes to your web service as it would have to accept the new XML structures, but since it's going to transform and process it immediately, that might not be a problem.

  • Unfortunately changing the web service is not an option. We are basically acting as a "middle man" to process incoming assignments in varying formats before passing to the destination that will ultimately deal with those assignments. – David Jun 11 '13 at 15:49
  • @David: Could you add a new webservice that is responsible for taking in the old XML, running an XSL transformation on it, and then returning the transformed XML back to the client, who then sends it to the original web service? I realize that adding another webservice call might not be a great way to go, but if you can't modify the existing webservice, it might be something to consider... – FrustratedWithFormsDesigner Jun 11 '13 at 15:52
  • Also, when you say you can't change the web service: I should have been more clear. I meant that you could add new operations (similar to the existing ones) that will do this new transformation work, and leave the original operations untouched for backwards compatibility. Is the webservice in you control or not? – FrustratedWithFormsDesigner Jun 11 '13 at 15:53
  • No - not in our control. The extra "web services" or "new operations" you discuss are what we currently do. – David Jun 11 '13 at 15:57
  • @David: Well, if you are only in control of the client applications and "extra" web services, it seems there are two places to do this transformation: the client or an "extra" web service. You could build a single common API for the clients that does all of the extra work of calling the appropriate operation in the new/enhanced web service... – FrustratedWithFormsDesigner Jun 11 '13 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.