- TeDMeT Scope v1
- TeDMeT Tutorial
- TeDMeT Download
- TeDMeT Workflow
- TeDMeT Path Code Completion Mockups
- TeDMeT Reality Based Scenario
This research initiative was kicked off by Frank Kieviet.
The "non-classic" side of CAPS 6.x does not currently have a message
mapping facility that is the equivalent of the classic CAPS JCE
(Java Collaboration Editor). This research project explores how we can
provide a low-cost addition to the non-classic side that does not rely on
proprietary representation formats or tools (JCDs, OTDs),
and does not preclude direct manipulation of DOM trees.
For more detailed scoping, look here.
The Test-Driven Message Transformation project is currently in a research state.
It is in flux, and may change over time as we evolve better understanding
of how to get the optimal user experience for the expected scenarios.
The sources will be distributed as open source using Mercurial as the source
The 0.1 version of the source has not been distributed yet, pending a more complete
The documentation will be provided on the wiki.open-esb.java.net website.
(Last meeting: 2008-09-23)
- Update OS dev wiki
- Get code into hg and running with current NB version
- Try out FK's new HL7-v3 sample
A step-by-step introduction is available here.
You can download the TeDMeT prototype here.
We're working on future developments. See more here.
- Scoping Document
- Workflow webpage needs to be elaborated further.
- Workflow discussion are ongoing.
- Where to maintain path types: alias class vs. XSD
- Code Completion discussion
- How to display a long alias list
- Search in alias list
- Display sample data in alias list?
- Search by sample data
- Tree display to generate new path?
- Show sample data in tree?
- Show type in tree?
- Highlight available path?
- Relative paths.
- Distill the complicated customer use case to mapping features.
- Upload the .nbm to the wiki page (future process?).
We analyzed a series of customer projects to extract a profile of real-life business case feature usage.
This gives us an idea of the types of structures and mapping that the user can expect in practice,
and for which our approach would need to provide a better solution, or at least not prove an impediment.
Some cases could not be processed because they required the extra installation of too many extra products
or external facilities to be feasible within the time scope, or proved to be outside the scope of our goal,
but we did manage to find and analyze a sufficient large (in our humble opinion) number of cases to give some depth
to the conclusions.
A caveat with this study is that we cannot say whether a potential feature was not used because:
(a) the user saw no business use-case for it, or
(b) the user would have liked to use it be could not because it was absent or too hard to use in the
current CAPS release.
Some features that we feel may have merit in the mapper (maybe not V1 but in the future)
- Templates for use in subroutines called from the main mapping function. This would tie in with "relative path" support.
- Option to generate for loops using the "Enhanced For-Loop" introduced in Java SE 5, using a "for (Path x: du.iter(Path))" notation. This would also eliminate the re-evaluation of du.count(Path) for the loop limit.
- Additional DomUtil implementation for use with bean trees so we are not bound to XML files.
- We notice a lot of logging going on in the customer projects. Most logging do expensive path evaluation calls and are not wrapped in a log-level check. Maybe provide something to make it easier to emit the Path/Value of a node so use doesn't have to construct such a string on every logging statement. Maybe this could be a new palette item?
- Ability to clone a subtree and set a subtree on a document without having to set each every node of the subtree. Cf. deep-copy library methods.
- Type conversion functions inside the DomUtil. Either built-in auto conversions or explicit type conversion utilties. Cf. the auto-conversion facilities in JCE/BPEL.
We looked at customer projects on the 513 repository on the link provided by Frank and we also imported some of the customer projects provided by Frank.
Among the customers were Alliantz, BCBSNC, Lockheed, Nike, BDP, BMW, Borders, GM, Hertz, INS, JCD2JCD, Kroger, Pfizer,
prjEmailJCD, Travelers, imLink2212.
Some of the customers did not use JCEs, others used small JCEs that did only very standard mappings,
and others did complex mappings.
From our analysis, we have seen the following:
- Customers use the unmarshal and marshal functions on OTDs. They can do something similar with our new mapper (XML to DOM serialization and parsing), but it involves a lot more code. It may be useful to offer them 2 functions in the DomUtil runtime utility class, similar to unmarshal and marshal, so they can achieve similar functionality with 1 simple function call instead of several lines of complicated Java code.
- Alliant1 and GE did unmarshal and marshal on non-root nodes of OTDs (something not generally supported across OTD types). This is something we may need to consider this capability on our DomUtil calls.
- Customers call static (i.e. non-messageable) OTDs. This can be done by calling the Java classes directly in the new mapper. The existence of static OTDs was an artefact of the JCE limitation to OTDs as parameters.
- Customers do a lot of try / catch handling. We may need to provide them a way to help them out with this in the new mapper. Undecided: should DomUtil methods use specialized exception classes, or use the general Java library ones?
- Customers do a lot of string concatenation and trimming of nodes.
- Single level repeating nodes is fairly common in the customer projects. Two level repeating nodes was also seen used by several customers. No repeating nodes deeper then 2 levels were seen in any of the customer projects examined.
- Optional nodes were common in the customer projects, usually in conjunction with repeating nodes. Sometimes the presence of repeating nodes was tested for with hasX() calls, sometimes with countX() > 0.
- Some customers cached intermediate nodes of OTDs for performance reasons. We can perhaps implement something similar with relative paths.
- Explicit data conversions were seen in the customer mappings. Typical data types used were String, int, double, boolean, DateTime.
- Travelers had JCE collaborations which explicitly instantiated OTD subnodes, instead of using getX()/letX(), something which we never expected to see.
- This customer project demostrate the simple mapping from input to output, concat the strings, check for optional node, and a single level of looping.
- This customer project demostrates 2 levels of looping,formatting string, optional node checking, and creation of the path node.