Write-ups for next conf call.

[johnspy@glintech.com]

Hello Group,

As promised during our conf call, I was to do two write-ups 'WS Services in Australia' and 'Systinet Registry metrics'

==========

Web Services in Australia

 

Giving my personal insight into Web Services in Australia, I have found that they have been slower to proliferate in organizations than how they are hyped in the media. I place Organisational web services into two categories, generated and crafted:

 

          I.      Generated: these take pre-existing functionality and map a web service interface to them. Any number of these stove-pipe services exists within a given organisation (as they are typically easy to create).

        II.      Crafted: these web-services, are synonymous with Service Oriented Architecture, they are purpose built for reuse and extensibility (they would typically have a modelling stage in which architects explicitly define these services). In any given large organisation (i.e. an Australian bank), we could typically expect to find anywhere from 20  100+ of these web services. 

 

The shift to Web Services, has had a number of impediments, such as 

         sunk costs into systems infrastructure, 

         set agenda to enterprise architecture, 

         vendor technology alignments. 

 

In the last few years however, this pattern has begun to change, my observation is that architecture groups are fuelling the growth of crafted web services. Vendors are also pushing for web services, MS .Net, Apache Axis, webMethods are some of the enabling technologies I have dealt with that offer a web services SOAP platforms. Some consistencies I have noticed in our accounts, regarding web services include:

 

They are used as cheap interfaces: providing an interface into systems using web services has the appeal of offering a standard, supportable infrastructure for interoperability. The fact that licensing costs are not an issue for web services (unlike other technologies like MQ), makes them an appealing option in providing interfaces to systems. 

They typically employ SOAP messaging: most web services encountered utilise SOAP messaging (document not RPC) specification. These are generally implemented as asynchronous messages. 

They are used for communication amongst departments: Given that Web Services are open standards and interoperable, we typically find that crafted services are built for reusability. This allows for any number of departments to use them, when they are applied in such a reusable fashion. 

Large implementations are beginning to have problems with governance: Sites with many web services, have expressed to us problems with versioning, librarianship and statistics (this ties in with our relationship to Systinet). The conventional alternative to using a UDDI registry, is to capture such information in a spreadsheet, repository or custom-built web app.
 

 

 
===========
 

Table of Metrics for the Systinet 6.0 UDDI Registry

 
avg-byte: Average sum of incoming and outgoing message length
 
avg-byte-input : Average input message length per hour
 
avg-byte-output : Average output message length

  
avg-hits : Average message hits per hour

  
avg-response-time : Average response time in milliseconds

 
Errors : Count of application failures in the last hour
 
Hits : Count of hits in the last hour

median-byte :  Median sum of incoming and outgoing message lengths
 
median-byte-input : Median value of incoming message lengths
 
median-byte-output : Median output message length

median-response-time : Median response time in milliseconds

policy-violations : Count of policy violations in the last hour

============
 
Kind Regards,
John Spyridopoulos