“Defining Message Formats” is the title of a message posted on the Service Oriented Architecture mailing list [1] which attracted a lot of attention. The post summarizes the dilemma faced by solution architects when they have to define a service interface:

1. Base the internal message format on the external message standard (MISMO for this industry). This message set is bloated, but is mature, supports most areas of the business, and is extensible for attributes specific to this company and its processes.
2. Create an XML-based message set based on the company’s enterprise data model, which the company has invested a great amount of money into, and includes a very high percentage of all attributes needed in the business. In a nutshell, we’ve generated an XML Schema from ER Studio, and will tinker with that construct types that define the payloads for messages.
3. Use MISMO mainly for its entity definitions, but simplify the structure to improve usability. We benefit from the common vocabulary, but would ultimately define dozens of transactions over the coming years that MISMO has already defined.

This article argues in favor of a variant of option 2 and provides details of how it can be implemented.

(Continue reading …)

The idea for this article came after reading an article in CACM about what SysAdmins would want from IT vendors (http://cacm.acm.org/magazines/2011/2/104373-a-plea-from-sysadmins-to-software-vendors/fulltext). It made me thinking, What would the environment support team want? This question has many aspects one being the support for automated monitoring and more specifically:

• Application monitoring at the business services level – not hardware, OS, networking, not even application container (JMX)
• Not one application but an environment made of many (hundreds) of components
• Multiple (tens) of environments – most of them for functional and performance testing, not production
• Most components are implemented on a Web-Services/J2EE platform
• Priority is on the availability of the environment – not performance or root-cause analysis.

Here are some of guidelines …

(Continue reading …)

This article is about terminology used in System Analysis and Design activities. It started from the never-really-answered question: “What is SOA?” which lead to even harder questions like “What is Software Architecture?” To answer I relied on three sources: Roy Fielding’s Ph. D Thesis, UML Specification and SoaML Specification.

Roy Thomas Fielding’s Ph. D Thesis[1] is well-known because introduced REST to the world, but has a much broader scope, including a categorization in the software architecture domain. Fielding defines the following terms:

software architecture – an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture

software architecture elements – components, connectors, and data–constrained in their relationships in order to achieve a desired set of architectural properties.

component – an abstract unit of software instructions and internal state that provides a transformation of data via its interface.

(Continue reading …)

I am working on a medium-size Java application with a test harness consisting of 180 tests grouped in 6 packages. Most of the automated tests read one or more input files and create multiple output files which are compared with “control” files. This approach provides an easy way to add more tests without coding. Over a period of three years this lead to the creation of around 350 input files and 600 control files taking 167MB. But as tests change, not all the test data is used anymore, which raise the question is: How can I find the test data files that are still used in my regression testing suite? The search for an answer lead to exploring Java 7, Spring AOP and Aspect J.

(Continue reading …)