New Earswick Tag Rugby Tournement July 2009

winoes at York July 2009

Originally uploaded by Wertster

Our merry band of rugby-bandits descended onto the turf at our latest tag-rugby tournament in York on the 11th July, hosted by New Earswick RLFC. With a low turn-out we got to work and had a great time, winning out overall in what was a really good natured day. Hopefully we’ll get a bigger turn-out next year. Looks like our next stop is now the Winoes Tour to the Anglet Beach Rugby Festival in Biarritz on the 25th July, where we’ll joust with our French cousins in the shadow of what I hear is a well stocked beer tent.

The CI, TDD and OO Love Triangle

I would not describe myself as a purist in any aspect of my life, least of all my software engineering practices. I’ve been re-establishing myself as a coder after a long while in the more abstract realms of architecture and design, and on the return-path I’m seeing things in a somewhat different light, and I think it’s an interesting observation hence this post.

Object Orientation was an approach I previously adopted to partition my problem-space into a group of components – so I could start hacking, rather than putting on the ‘everything is an object and so is its mother’ spectacles. I never quite got my head around why colleagues and ‘real developers’ would sit for hours debating the 99th level of object decomposition and whether an object had to be so fine-grained it should actually contain no code?

My return journey to the world of software development has intersected with new (I say ‘new’ given I was a full-on hacker in the mid 90’s so this is new to me) and emerging trends around Continuous Integration and Test Driven Development and I have to say these intersections have made a huge impression on me to the extent that I’m now passionate about the benefit brought about by these techniques. Maybe I’m so pro-CI and pro-TDD because I lived through the appalling software engineering practices of the 80’s and early 90’s, or may be it’s just because it makes so…much…sense.

So to my point. Continuous Integration has a simple benefit. You know when your code-base has been tainted. The more frequently you get to know that the better. I’ll avoid quoting the scientists who waffle about cost exponentials for fixing defects today versus tomorrow blah. No – it just…makes….so….much….sense ! I didn’t need a PhD in chin rubbing to work that out.

Next Test-Driven Development. Right this one took time, just a little time to get my head around, even though I was convinced that CI was the way to go no questions asked. I found myself asking the stereotypical questions like “won’t I be 50% productive if I spend half my time writing tests for the code I am writing?”. Let me just pause while I give myself 10 lashes for being so narrow-minded. THWACK, THWACK, THWACK, THWACK, THWACK, THWACK, THWACK, THWACK, THWACK, THWACK…and one for luck THHHHHWACK!!  So it’s a natural inclination to feel like test-cases are just code that you’d traditionally throw into the code-base, but when you consider the fact that you’re actually building inherent certainty into the code-base at every step of the way the lightbulb goes on in a big way. When I sat back and appreciated that I wouldn’t have to run huge amounts of code to verify and exercise a small method I just changed it….just….makes….so…much….sense. All the regression testing scenarios I was carrying round in my head ! The lack of repeatability in my approach to testing !! The gradual feeling of dread that I’d become used-to, after deploying a stable version of code, in case I had to, god-forbid, change it at some point??! It all cries out for an inherent approach that means you lock-down every function you implement as you implement it – such that you can purge all that baggage from your poor little cranial-walnut. It….just….makes….so….much…sense. I was soon a TDD convert, but only at that point did it strike me like a bolt from the blue…finally my life made sense….finally I could truly embrace the love-triangle of CI->TDD->OO.

The effectiveness of my CI/TDD regime relied totally on the level of granularity I could descend to with my class definitions, and the simplification of each and every function to it’s thinnest possible form.  Real fundamental Object Orientation finally became the underpinning foundation – notice I place it in that underpinning role – as I’ve only now seen OO as an enabler for the ‘common-sense’ and ‘value-adding’ techniques of CI and TDD. I’m a little weird that way – but I found my way into rigorous OO not via the brain-washing from the chin-rubbing ranks of “my object is more objecty than yours” brigade, but instead through the simple realisation that I can squeeze ever more value from my CI/TDD framework if I force my test-cases into finer and finer levels of granularity (within reason of course, I aint lost my roots yet !! )

So there you have. CI drives me to TDD. TDD drives me to appreciate why OO should exist, NOT vice versa…

Ruby Code Quality and Metric_Fu

I’ve been putting together a continuous integration framework for my Ruby projects and was very pleased to find the great work by Jake Scruggs (http://metric-fu.rubyforge.org/ ) by the name of Metric_Fu. On the whole this aggregation of tools covers all the key ‘quality’ bases and generates some elegant graphical reports that can be simply published alongside other build artifacts in CruiseControl.rb for example. On the whole the installation is very simple, but I hit some issues with the code and had to apply some class method overrides to get it to work.

My base environment is OSX 10.5.7, Ruby 1.8.6, Gem 1.3.3. I installed the gems jscruggs-metric_fu (1.1.1), rcov (0.8.1.2.0), flog (2.1.2), flay (1.3.0), reek (1.1.3), roodi (1.4.0) and Saikuro (1.1.0). Following the instructions at http://metric-fu.rubyforge.org/ I was complete in short order, and ran the rake task as per the example.

The first problem I hit was a method naming issue where the a Flog#flog_files method was being called which didn’t exist in the versions I was using. I ended up with a quick-n-dirty fix which involved amending the /gems/flog-2.1.2/bin/flog script to remove the call to flog_files, replacing it with the correct method name flog:

...
flogger = Flog.new options
flogger.flog ARGV
flogger.report
...

Second problem I hit was some floating point and divide-by-zero issue in the MetricFu::Generator#round_to_tenths method. I don’t profess to understand the core issue here, but the value of ‘NaN’ was appearing in the calculation – so I added a ‘very’ primitve override to filter this condition (elegance is not my middle name I you hadn’t realised already):

module MetricFu
  class Generator
    def round_to_tenths(decimal)
      decimal=0.0 if decimal.to_s.eql?('NaN')
      (decimal.to_i * 10).round / 10.0
    end
  end
end

Next I hit an issue with rcov not returning any results into the dashboard? I checked this out and located an error in the rcov.txt file generated as part of the execution. This simply informed me that the rcov commandline generated within the metric_fu rcov generator class was incorrect. After a little experimentation I worked out that the –include-file parameter was the issue…so I again redefined the problematic class method in my Rakefile to remove this issue:

Module MetricFu
  class Rcov
    def emit
      begin
        FileUtils.rm_rf(MetricFu::Rcov.metric_directory, :verbose => false)
        Dir.mkdir(MetricFu::Rcov.metric_directory)
        test_files = FileList[*MetricFu.rcov[:test_files]].join(' ')
        rcov_opts = MetricFu.rcov[:rcov_opts].join(' ')
        output = ">> #{MetricFu::Rcov.metric_directory}/rcov.txt"
        #PROBLEM: `rcov --include-file #{test_files}  #{rcov_opts} #{output}`
        `rcov #{test_files}  #{rcov_opts} #{output}`
      rescue LoadError
        if RUBY_PLATFORM =~ /java/
          puts 'running in jruby - rcov tasks not available'
        else
          puts 'sudo gem install rcov # if you want the rcov tasks'
        end
      end
    end
  end
end

Next I hit a problem when modifying my declared MetricFu::Configuration object to change the location of the outputs of the analysis, to reduce the pollution in my project folder hierarchy (yep…I probably do have some deeper issues). I had added the following lines to the sample provide by Jake:

MetricFu::Configuration.run do |config|
  config.base_directory = ENV['CC_BUILD_ARTIFACTS'] || 'quality'
  config.scratch_directory = File.join(config.base_directory, 'scratch')
  config.output_directory = File.join(config.base_directory, 'output')
  config.data_directory = File.join(config.base_directory, '_data')
  etc

With this new folder structure I also had to add a tweek to the Saikuro configuration entry in the same sample, to make sure the Saikuro outputs are picked up by the report aggregator. Without this tweek I was just getting a blank Saikuro template page offered by Metric_Fu:

(Ignore the space between the colon and the ‘o’ – it’s giving me smilies for some reason)

config.saikuro  = { : output_directory =>
                              File.join(config.scratch_directory, 'saikuro'),

This change caused a failure in the MetricFu::Graph#generate method – which on closer inspection appeared to be hardwired in expecting a depth of 3 folders in the locations specified for these outputs? So again I re-declared this class in my Rakefile to make the specific change necessary to support any level of nesting. This fixed the problem and my folder feng-shui returned to equilibrium…mmmmmmm.

Module MetricFu
  class Graph
    def generate
      puts "Generating graphs"
      Dir[File.join(MetricFu.data_directory, '*.yml')].sort.each do |metric_file|
        puts "Generating graphs for #{metric_file}"
        #PROBLEM: date = metric_file.split('/')[3].split('.')[0]
        date = metric_file.split('/').last.split('.')[0]
        metrics = YAML::load(File.open(metric_file))
        self.clazz.each do |grapher|
          grapher.get_metrics(metrics, date)
        end
      end
      self.clazz.each do |grapher|
        grapher.graph!
      end
    end
  end
end

So my installation of metric_fu works perfectly now and I’m very impressed with the output it’s providing so long as I don’t dwell too much on the fact that it’s telling me my code quality is somewhere between criminal and insane !!!

I hope these notes may help others experiencing similar frustration in trying to get the install working…and again my thanks to Jake Scruggs for this piece of goodness.

Cheers all !

Bridlington Beach Rugby 2009

 

Post tournament Winoes

Originally uploaded by Wertster

Our veteran team of ex-ex players, affectionately known as the Leeds Winoes, made another showing at the Brid beach-tag tournament on the 27th June. We made a close 3rd place behind West Leeds (2nd) and Bridlington-A (1st) in a great competition. Next stop is our first ‘international’ in Biarritz, France on the 25th July when we take on the best of the European circuit. Might have recovered by then.

VMWare Fusion XP VM Losing DNS !

I’ve been running OSX Vmware Fusion 1.x and XP SP2 & SP3 for over a year and it’s been ROCK SOLID ! I run a web-connected OSX host, and a XP VM VPN’d into a corporate network all day, every day and I have not had a single problem. Until this week…when my calm seas were interrupted…

Out of the blue I notice witin the XP SP3 VM was failing to resolve DNS queries. OK. Why? I basically ran a number of diagonstics, checked driver versions and everything checked out in terms of VM integrity.No idea. The worst kind of problem…

I checked out the net and located numerous threads deliberating over the XP “Unable to flush DNS cache” type of errors, with long and elaborate threads falling into the detail of comparing router firmware versions and other such infinate variables. Eject..Eject…

It was only when I ran the VMWare packet sniffer on the OSX host I could see that the XP VM was requesting DNS, and the resoponses from the OSX host were being dispatched. From my understanding of low level IP it appeared that all was performing as expected. However I then started thinking about reasons why UDP packets were being neglected by the XP VM’s IP stack….BINGO !

I then checked out the Windows XP Event Viewer under the Security event list, and there I see all my DNS responses (from the OS X host) arriving back at my XP VM as UDP packets, all being summarily discarded by my failed/corrupted firewall. Couple of minutes later, having run the ’support’ utility from the firewall supplier, the flood-gates openend and UDP/DNS was back in business.

Symptoms I encountered in XP:

1. DNS resolution (i.e. ping www.xyz.com) within XP VM failing but direct direct addressing worked ok (i.e. ping 123.123.123.123)
2. nslookup in the console returned ‘no response from server’ errors in response to queries.
3. Right-clicking on the network connection icon in XP, and executing Repair proceeded through all steps apart from the final DNS cache at which point Unable to repair connection was returned.
4. ipconfig /registerdns failed with a non-specific error

In hindsight the symptoms all point to UDP return-path and firewall but verifying the request path with the OSX VMWare vmnet-sniffer utility (located in /Library/Application Support/VMWare Fusion folder) made this a whole lot simpler.

Where a Semantic Contract Fits…

I’ve been posting about the rise of the informal semantic contract relating to web-services and the deficiencies of XML Schema in adequately communicating the capability of anything other than a trivial service. Formalising a semantic contract by enriching a baseline structural contact (WSDL/XSD) with semantic or content-based constraints, effectively creates a smaller window of well-formedness, through which a consumer must navigate the well-formedness of their payload in issuing a request. Other factors such as incremental implementation of a complex business service ‘behind’ the generalised service interface compound the need for a semantic contract.

To clarify the relationship between structural and semantic, I happened upon a great picture which I’ve annotated…

Validating XML with Schema in Ruby

I posted a long time back about my troubles in finding a way of performing schema validation in ruby (see Ruby and Xml Schema). At that time I was using REXML and only able to perform well-formedness checks based on basic structural integrity, but had no way to take an XSD and validate an instance document.

I’m pleased to say that there is a way to do this now, namely libxml-ruby. It’s available as a gem (gem install libxml-ruby) and the process is pretty simple:

  document = LibXML::XML::Document.file(@xml_filename)
  schema = LibXML::XML::Schema.new(@xsd_filename)
  result = document.validate_schema(schema) do |message,flag|
    log.debug(message)
    puts message
  end

I’ve found this to be a very neat piece of code for dealing with the kind of schema integrity checking I’m looking for, and as I blend this with a number of other java-based parses using the Ruby Java Bridge I get a pretty good, consistent perspective on validity.

The Rise of the Semantic Contract

This is my stake in the ground for now. SOA in the market-place places total emphasis on 2 things. Web Services as a basis for communication and Re-use as a basis for convincing the boss to put some cash into your middleware bunker..no…play-pen…err…seat of learning.

In addition the militant splinter-groups of the new-wave of RESTafarians (of whom I am an empathising skeptic on this specific point about service specification) call for the death of WSDL and the reliance on (WSDL-lite) WADL in the case of the less extremist, but plain-old inference from sample instance documents in the case of the hard-core….

I am finding myself sailing down the no-mans land between these two polarised viewpoints, and see the need for specification in the more complex end of the interface spectrum, but similarly don’t see how specifications help when decoding the specification is harder than inferring from samples when interface contracts are relatively intuitive. So there we have a basic mental picture of my map of  the universe.

Now I’m getting to the point.

I’m now convinced that SOA’s push for re-use established through WSDL everywhere, but equally the more recent RESTafarian voices relating to unspecification both have flaws when we are attempting to open up a generalised interface into a service endpoint capable of dealing with a range of entity variants (say product types for example).

My view here is that in the SOA landscape, the static and limited semantic capability of XMLSchema, and in the RESTian lanscape, the inability of humans to infer correctness without a large number of complex instance document snapshots, leads me to the conclusion that there is a vast, yawning, gaping, chasm of understanding in what constitutes an effective contract in locking down the permissible value permutations – aka the semantic contract.

I’ve seen MS-Word. I’ve seen MS-Excel. I’ve seen bleeding-eyes-on-5-hour-conference-calls-relating-to-who-means-what-when-we-say-customer, and best of all I’ve seen hardwired logic constructed in stove-pipes behind re-usable interfaces, aka lipstick on the pig.

I reckon the semantic contract – the contract locking down the permissible instances is far more important than the outer structural contract who’s value decays as the level of re-use and inherent complexity of the interface increases. In addition there are likely to be multiple iterations/increments of a semantic contract within the context of a structural contract as service functionality is incremented over successive iterations – adding product support incrementally to an ordering service of example. This leads to to the notion of the cable cross-section:

In the SOA context…WSDL drives tooling to abstract me from the structural contract. But the formation of the semantic contract as the expression of what the provider is willing to service via that re-usable and loose structural contract is the key to effective integration.

If we don’t pay this enough respect we’ll be using our system testing to mop-up the simple, avoidable instance-data related problems that could be easily avoided if we’d formalised the semantic contract earlier in the development lifecycle…

Powered by Qumana

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

Ruby Wrapper for WS-I Analyzer tools

I’ve been developing some scripting to enable me to assess the integrity of integration artifacts created across a range of development teams in large scale SOA integration programmes. One of the most basic forms of assessment is the WS-Interoperability (WS-I) analysis of WSDL, to identify any specific non-compliances at grass-roots. (I can hear the RESTian hordes tooling up to brow-beat me into submission as I type this….and YES I understand, YOU don’t like WSDL, nor do I, but they DO exist so I’m gonna analyse em ! Right – now that’s out of the way on with the WSDL baiting…).

There’s a set of java/c# tools out there from the clever folk over at WS-I (http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools) which are already used informally within our organisation, and I’ve created a ruby-based wrapper for this. It’s not mature enough to be packaged as a Ruby Gem, and it does rely on an installation of the java tools in some folder on your machine – but the following ruby source does allow you to spin up objects in your Ruby code and kick it to analyse your WSDL artifacts without being exposed to java code. In line with my usual train-of-thought programming style and my few months of Ruby exposure, it’s not pretty but it works well enough to be parked for a while… Usage is pretty simple. The analyzer object can be initialised once and used thereafter to manage the analysis of many discrete WSDL resources. With each call to WSIAnalyser.analyze_wsdl() the first parameter is a file: or http: URI to a WSDL, and the second is a path/folder into which the outputs from this analysis will be placed. In any given WSDL the analyzer iterates through every <definitions/services> node, creating a report for each node. The outputs (in the output folder) are:

1. A copy of the WSDL source
2. A copy of the WS-I Tools configuration file generated by this script, one per <definitions/service> element in the source
3. A WS-I analysis report generated by the underlying WS-I tool – one per <definitions/service> element in the source WSDL

a=WSITools::WSIAnalyzer.new
a.analyze("http://www.domain.com/someservice.wsdl", "c:/dev/wsdloutputs")
a.reports.each_pair do |r,s|
puts "WSDL [#{a.wsdl_uri}] Report [#{r}] Status [#{s}]"
end

The source:

WSI_ANALYZER_CONFIG_TEMPLAGE = %{<?xml version="1.0" encoding="UTF-8"?>
<wsi-analyzerConfig:configuration name="WS-I Basic Profile Analyzer Configuration" xmlns:wsi-analyzerConfig="http://www.ws-i.org/testing/2004/07/analyzerConfig/">
<wsi-analyzerConfig:description />
<wsi-analyzerConfig:verbose>
false
</wsi-analyzerConfig:verbose>
<wsi-analyzerConfig:assertionResults type="all" messageEntry="true" failureMessage="true"/>
<wsi-analyzerConfig:reportFile replace="true" location="xxxxxxxx">
<wsi-analyzerConfig:addStyleSheet href="" type="text/xsl"/>
</wsi-analyzerConfig:reportFile>
<wsi-analyzerConfig:testAssertionsFile />
<wsi-analyzerConfig:wsdlReference>
<wsi-analyzerConfig:wsdlElement type="port" parentElementName="" namespace="" />
<wsi-analyzerConfig:wsdlURI />
</wsi-analyzerConfig:wsdlReference>
</wsi-analyzerConfig:configuration>
}

#As we are modifying the path environment variable, we need to ensure that the correct delimiter is used
UNIX_PATH_DELIMITER=":"
WIN_PATH_DELIMITER=";"

#This must be changed to point to the physical root of the wsi-installation
WSI_HOME_TAG = "WSI_HOME"
WSI_HOME_VAL = "c:/dev/wsi-test-tools"
WSI_JAVA_HOME_TAG = "WSI_JAVA_HOME"
WSI_JAVA_HOME_VAL = "#{WSI_HOME_VAL}/java"
WSI_JAVA_OPTS_TAG = "WSI_JAVA_OPTS"
WSI_JAVA_OPTS_VAL = " -Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser"
WSI_CLASSPATH_TAG = "WSI_CP"
WSI_TEST_ASSERTIONS_FILE = "#{WSI_HOME_VAL}/common/profiles/SSBP10_BP11_TAD.xml"
WSI_STYLESHEET_FILE = "#{WSI_HOME_VAL}/common/xsl/report.xsl"
WSI_EXECUTION_COMMAND = "#{WSI_JAVA_HOME_VAL}/bin/Analyzer.bat -config "

WSIClasspath=[
"#{WSI_JAVA_HOME_VAL}/lib/wsi-test-tools.jar",
"#{WSI_JAVA_HOME_VAL}/lib",
"#{WSI_JAVA_HOME_VAL}/lib/xercesImpl.jar",
"#{WSI_JAVA_HOME_VAL}/lib/xmlParserAPIs.jar",
"#{WSI_JAVA_HOME_VAL}/lib/wsdl4j.jar",
"#{WSI_JAVA_HOME_VAL}/lib/uddi4j.jar",
"#{WSI_JAVA_HOME_VAL}/lib/axis.jar",
"#{WSI_JAVA_HOME_VAL}/lib/jaxrpc.jar",
"#{WSI_JAVA_HOME_VAL}/lib/saaj.jar",
"#{WSI_JAVA_HOME_VAL}/lib/commons-discovery.jar",
"#{WSI_JAVA_HOME_VAL}/lib/commons-logging.jar"
]

class WSIAnalyzer
VERSION = "1.0.0"

attr_reader :wsdl_uri
attr_reader :wsdl_name
attr_reader :wsdl_source
attr_reader :analyzer_config_uri
attr_reader :analyzer_config_source
attr_reader :wsdl_namespace
attr_reader :wsdl_service_name
attr_reader :wsdl_port_name
attr_reader :workspace
attr_reader :report_filename
attr_reader :wsi_approved
attr_reader :wsdl_service_declarations
attr_reader :reports
attr_reader :errors

def initialize
begin
@log=Logger.new("analyzer.log")
@log.progname="WsiAnalyzer"
@log.level = Logger::DEBUG
@wsdl_uri=nil
@wsdl_name=nil
@wsdl_source=nil
@analyzer_config_uri=nil
@analyzer_config_source=nil
@wsdl_namespace=nil
@wsdl_service_name=nil
@wsdl_port_name=nil
@workspace=nil
@report_filename=nil
@wsdl_service_declarations={}
@reports={}
@errors=[]
#Check the installation location to ensure the wsi-test-tools are installed on the host
if not File.exists?(WSI_HOME_VAL)
@log.fatal("Unable to locate WSI-Test-Tools installation at [#{WSI_HOME_VAL}]")
return nil
end
#Ensure environment variables are in place
if(ENV[WSI_HOME_TAG].nil?)
@log.warn("No WSI-Test-Tools environment variables present [#{WSI_HOME_TAG}]")
configure_environment
end
rescue => ex
@log.error("Unable to initialise WSIAnalyzer: Ex #{ex.message}\n"+ex.backtrace.join("\n"))
return nil
end
end

def analyze_wsdl(wsdl_uri, workspace)
begin
@wsdl_uri=wsdl_uri
@workspace=workspace
segments=@wsdl_uri.split('/')
@wsdl_name=segments.last
segments=@wsdl_name.split('.')
@wsdl_name=segments.first
@log.info("Analyzing WSDL[#{@wsdl_name}] from URI[#{@wsdl_uri}] in workspace [#{@workspace}]")
#obtain the wsdl source
acquire_wsdl
#obtain key wsdl attributes required to create ws-i configuration
extract_target_elements
#There may be more than one pass to make here so iterate
@wsdl_service_declarations.each_pair do |svc, port|
#create dynamic ws-i configuration
@log.info("Excuting WS-I analysis for WSDL [#{@wsdl_name}] Service[#{svc}] Port[#{port}]")
@report_filename="#{@workspace}/ws-i-report-for-wsdl-#{@wsdl_name}-svc-#{svc}-port-#{port}.xml"
create_dynamic_wsi_config(svc, port)
#execute the analysis
execute_wsi_analyzer
end
rescue => ex
@log.error("Unable to analyze WSDL [#{@wsdl_uri}]: Ex #{ex.message}\n"+ex.backtrace.join("\n"))
return false
end
end

private

def execute_wsi_analyzer
begin
#Now kick the external WSI script to generate a report
commandline="#{WSI_EXECUTION_COMMAND} #{@analyzer_config_uri}"
@log.info("Execution WS-I Analyzer with shell [#{commandline}]")
@reports={}
@errors=[]
system(commandline)
#Verify if a report has been created
if(not File.exists?(@report_filename))
@log.warn("No report file [#{@report_filename}] produced by WS-I Analyzer")
else
@log.info("Scanning for WS-I summary status...")
begin
dom=REXML::Document.new File.new(@report_filename)
if dom.elements["report/summary"].nil?
if not dom.elements["report/analyzerFailure"].nil?
#A failure code has been identified in the report doccument
msg=dom.elements["report/analyzerFailure/failureDetail"]
@log.warn("WSDL [#{@wsdl_name}] WS-I Failure Report [#{msg}] ")
@errors << msg
status="failed"
end
else
#Summary status is passed (not sure if summary can be failed/error
status=dom.elements["report/summary"].attributes["result"].to_s
end
@log.info("WS-I Approval Status [#{status}] for WSDL [#{@wsdl_uri}]")
#Add a report summary to the list of reports
@reports[@report_filename]=status
end
end
rescue => ex
#Unable to acquire status - treat report as invalid/missing
@log.error("Unable to complete WS-I Analysis of [#{@wsdl_name}]: Ex #{ex.message}\n"+ex.backtrace.join("\n"))
raise
end
end

def create_dynamic_wsi_config(svc, port)
begin
cdom=REXML::Document.new(WSI_ANALYZER_CONFIG_TEMPLAGE)
#cdom.elements.each do |e|
# puts e.inspect
#end
@log.info("WS-I configured to report to [#{@report_filename}]")
cdom.elements["wsi-analyzerConfig:configuration/wsi-analyzerConfig:reportFile"].attributes["location"]=@report_filename
cdom.elements["wsi-analyzerConfig:configuration/wsi-analyzerConfig:reportFile/wsi-analyzerConfig:addStyleSheet"].attributes["href"]=WSI_STYLESHEET_FILE
cdom.elements["wsi-analyzerConfig:configuration/wsi-analyzerConfig:testAssertionsFile"].text=WSI_TEST_ASSERTIONS_FILE
cdom.elements["wsi-analyzerConfig:configuration/wsi-analyzerConfig:wsdlReference/wsi-analyzerConfig:wsdlElement"].attributes["namespace"]=@wsdl_namespace
cdom.elements["wsi-analyzerConfig:configuration/wsi-analyzerConfig:wsdlReference/wsi-analyzerConfig:wsdlElement"].attributes["parentElementName"]=svc
cdom.elements["wsi-analyzerConfig:configuration/wsi-analyzerConfig:wsdlReference/wsi-analyzerConfig:wsdlElement"].text=port
cdom.elements["wsi-analyzerConfig:configuration/wsi-analyzerConfig:wsdlReference/wsi-analyzerConfig:wsdlURI"].text=@wsdl_uri
#Now write the configuration file into the workspace of the artifact
#@log.debug(cdom.to_s)
@analyzer_config_source=cdom.to_s
@analyzer_config_uri="#{@workspace}/wsiAnalyzerConfig-svc-#{svc}-port-#{port}.xml"
open("#{@analyzer_config_uri}",'w'){ |f| f << cdom.to_s}
@log.info("Written dynamic WS-I config into [#{@analyzer_config_uri}]")
rescue => ex
@log.error("Unable to generate dynamic config for WS-I: Ex #{ex.message}\n"+ex.backtrace.join("\n"))
raise
end
end

def extract_target_elements
#Need the servicename, portname and other stuff from the wsdl
#Get the DEFINITIONS.TARGETNAMESPACE attribute
#Get the DEFINITIONS/SERVICE.NAME attribute
#Get the DEFINITIONS/SERVICE/PORT.name attribute
dom=REXML::Document.new(@wsdl_source)
begin
#TODO: Need to ensure I can handle a WSDL with multiple SERVICE/PORT combinations
@wsdl_namespace=dom.elements["definitions"].attributes["targetNamespace"]
#@wsdl_service_name=dom.elements["definitions/service"].attributes["name"]
@wsdl_service_declarations={}
dom.elements.each("definitions/service") do |servicenode|
svc=servicenode.attributes["name"]
port=servicenode.elements[port].attributes["name"]
@wsdl_service_declarations[svc]=port
end
#@wsdl_port_name=dom.elements["definitions/service/port"].attributes["name"]
@log.info("Extracted Namespace[#{@wsdl_namespace}] Services[#{@wsdl_service_declarations.inspect}] from WSDL")
if @wsdl_service_declarations.size<1
raise "No Service elements [definitions/service] detected in WSDL [#{@wsdl_name}]"
end
rescue => ex
@log.error("Unable to extract WSDL markers for WS-I: Ex #{ex.message}\n"+ex.backtrace.join("\n"))
raise
end
end

def acquire_wsdl
begin
@wsdl_source = open(@wsdl_uri).read
@log.info "Acquired WSDL [#{@wsdl_uri}] [#{@wsdl_source.length}] bytes of WSDL"
rescue => ex
@log.error("Unable to acquire WSDL [#{@wsdl_uri}]: Ex #{ex.message}\n"+ex.backtrace.join("\n"))
raise
end
end

def configure_environment

#display WSI environment variables
path_delim=UNIX_PATH_DELIMITER
unless ENV["OS"].nil?
unless ENV["OS"].downcase.index("windows").nil?
path_delim=WIN_PATH_DELIMITER
end
end
ENV[WSI_HOME_TAG]=WSI_HOME_VAL
ENV[WSI_JAVA_HOME_TAG]=WSI_JAVA_HOME_VAL
ENV[WSI_JAVA_OPTS_TAG]=WSI_JAVA_OPTS_VAL
#Now add the path segments
WSIClasspath.each do |val|
if(ENV[WSI_CLASSPATH_TAG].nil?)
ENV[WSI_CLASSPATH_TAG]="#{val}"
else
ENV[WSI_CLASSPATH_TAG]="#{ENV[WSI_CLASSPATH_TAG]}#{path_delim}#{val}"
end
end
end
end
end


Powered by Qumana