Strong data typing in Integration Server

[reamon]

Wanted to gather thoughts about strong data typing in the “integration tool” context – advisable or not?

Programming principles state that strong data typing in the language can help avoid runtime errors by flagging data type mismatches at compile time.

Different languages have differing data type enforcement. And there are a couple of compelling schools of thought around strong vs weak typing.

Integration Server, and the FLOW services defined and used within, use weak typing for the most part. Everything is a string. When arithmetic is needed, conversions are done behind the scenes. For example, all the services in pub.math use string parameters, not integers, longs, etc.

For integration components, where the primary function is to get a payload from point A to point B (or points B, C and D) strong typing usually is not useful. Indeed, more often than not, it gets in the way. Because the “in the middle” components don’t really need to validate the data, they just need to move it along.

Of course there are areas in IS where strong typing has been introduced. The JSON services. The so-called REST Application Descriptors (RAD). These and other components automatically convert string representations (a number in JSON is a string, not a binary number) to their equivalent Java types (integer, float, etc.)

IMO, that’s a mistake for middleware. There are other ways to enforce data constraints when/if needed. Indeed, the support for XML shows one way – the data is in string variables but can be checked against XSD constraints.

Soliciting input from the community – what are your thoughts on strong data typing in IS? Should it do more by default? Or do weak typing with support for validation/conversion as desired by a developer?

[John_Carter4 (John Carter)]

My opinion is don’t do it.

Strongly typed values are only useful when used in conjunction with compilation, it offers no advantage to coding in flow and in fact creates lots of overhead i.e. conversion from input and output formats, especially pointless as most external entities will be text based i.e. json or xml text received over HTTP or via text files.

Also most public services in webMethods assume string input/outputs even for math.
The one outlier is jsonStringToDocument, which unfortunately attempts to type number values and which as a result has issues with very large values as we don’t currently support big decimal. In the next version we will add an input to match behaviour with xmlStringToDocument i.e. assume all values will be strings in the document.

The only exception to this is date type i.e. I always use java date objects when reading or writing to databases via the JDBC adapter. This is to avoid relying on the data pattern implied by the database which can be different from one DB instance to another (I hate external dependencies, they always bite you in the end).
regards,
John.

[reamon]

@John_Carter4

I always use java date objects when reading or writing to databases via the JDBC adapter

We (try to) do the same always. Then when placing the date into a publishable doc, we convert it to a string representation as defined by the W3C profile for ISO 8601 as described at Date and Time Formats

That is good news on the jsonStringToDocument service.

[Venkata_Kasi_Viswanath_Mugada1 (Kasi Mugada)]

I side with John on this.

I’d rather have a standard data type and handle conversions to/fro when needed, or unless the target system warrants it (dates across databases are a perfect example, as John says). This is especially considering that middleware integrates with tens and hundreds of disparate systems if not more, and strong data-typing will easily increase the (rather unnecessary) overhead multi-fold and nullify any potential benefits by miles.

KM

[reamon]

Three advocates for “weak typing” and no one advocating for strong. Hoped for a bit more discussion from different viewpoints but ah well.

Feedback item on the forums: Not every post is a “problem” that needs an “Accepted Answer / Solution”. Would be nice if the forum would stop pestering me to mark a response as accepted.