- TeDMeT Scope v1
- TeDMeT Tutorial
- TeDMeT Download
- TeDMeT Workflow
- TeDMeT Path Code Completion Mockups
- TeDMeT Reality Based Scenario
Test-Driven Message Transformation (TeDMeT) is a research project that aims to provide a
limited message mapping facility in a Java editor in NetBeans.
It is based on the direct manipulation of DOM trees in Java through
calls on a runtime utility (DomUtil), using references to
automatically generated descriptors to represent paths in the DOM trees.
The references are generated from sample XML data to provide an initial
mapping method, so that the user has a working starting point for creating
a similar message from another DOM input tree. The use can use the
code completion facility in the Java editor to see a list of
references (also known as aliases or shortcuts) available in the
shortcut collection class generated for a DOM tree. The references
are generated with JavaDoc that will show up in the tooltip for the
reference, containing the full DOM path text and sample data (if any).
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
control system. The source has not been distributed yet, pending a more complete
The documentation will be provided on the wiki.openesb.org website.
Currently, the documentation is kept on the SOABI website, pending completion.
(Last meeting: 2008-07-30)
- Workflow Discussions
- Paper mockups and discussions about code completion
- Find more typical customer example. i.e. somewhere around 62 nodes and a decent java mapping
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.