Enterprise SOA, Continuous Integration and DXSI

Creating an approach to CI’ing large scale enterprise SOA initiatives has unearthed a potentially significant efficiency gain in the semantic layer. Semantics relate to instance data – and specifically in the context of re-usable, extensible service interfaces the semantic challenge eclipses that of achieving syntactical alignment between consumer and provider.

Evidence shows that the vast proportion of integration failures picked up in testing environments (having taken the hit to mobilise a complex deployment of a range of components) are related to data/semantics, not syntax.

As such I’ve been focusing on how to front-end the verification of a consumer ‘understanding’ the provider structurally and semantically from day 1 of the design process. The CI framework I’m putting together makes use of a traditional set of artifact presence/quality assessment, but significantly introduces the concept of the Semantic Mock (SMOCK) – which is an executable component based on the service contract with the addition of a set of evolving semantic expressions and constraints.

This SMOCKartifact allows a service provider to incrementally evolve the detail of the SMOCK whilst having the CI framework automatically acquiring consumer artifacts such as static instance docs or dynamic harnesses (both manifesting earlier in the delivery process than the final service implementation (and I mean on day 1 or 2 of a 90 day cycle as opposed to being identified through fall-out in formal test-environments or worse than that – in production environments for example).

Over time as both consumer and provider evolve through and beyond the SMOCK phase, the level of confidence in design integrity is exponentially improved – simply based on the fact that we’ve had continuous automated verification (and hence integration) of consumer and provider ‘contractal bindings’ for weeks or months. This ultimately leads to a more effective use of formal testing resource and time in adding value as opposed to fire-fighting and kicking back avoidable broken interfaces.

The tool I’m using to protoype ths SMOCK is Progress DXSI. This semantic integration capability occupies a significant niche by focusing on the semantic or data contract associated with all but the most trivial service interfaces. DXSI allows a provider domain-expert to enrich base artifacts (WSDL/XSD) and export runnable SMOCK components which can then be automatically acquired, hosted and exercised (by my CI environment) to verify consumer artifacts published by prospective consumers of the service. Best of all kicking back compliance reports based on the semantic constraints being exercised in each ‘test case’ such that my ‘CI Build Report’ includes a definition of why ‘your’ understanding of ‘my’ semantic contract is flawed…

Beyond SMOCK verification – DXSI also allows me to make a seamless transition into a production runtime too but that’s another story…

Powered by Qumana

Advertisements

3 Responses to Enterprise SOA, Continuous Integration and DXSI

  1. Codecentric’s Fridaymeeting…

    A few days ago I saw the entry on the codecentric blog about their recent Fridaymeeting. It was great to see more folks being introduced to a common model based approach to integration, and how that can simplify complex integration projects and the ado…

  2. smartrics says:

    Stew, I would object that integration issues are just around data, Especially in systems where business transactions spawn across different interface calls. Unless you envisage such transaction incapsulated in a single call the workflow plays an important part on increasing the level of complexity

  3. Stew Welbourne says:

    Sure you make a valid point. Workflow and aggregation of functionality does increase the complexity of an integration solution along with the inherent testing scheme but my primary focus in this context is the semantic contract within ‘a service’ invocation. This is at the point of transition of a representation of data between two system boundaries through a service interface.

    The semantic contract is generally the poor relation to the syntactical contract in terms of visibility and tooling support, but is often far more complex when more complicatedschemas are in use. Validating the permutations of execution in the workflow scenario is slightly separate to the goal I’m trying to achieve here but just as valid in terms of the overall level of confidence you’d want to gain through CI.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: