INDEX
Software Technology
Web Services Adoption in Review
Advanced Specifications of Web Services
Web Services Enhancements (WSE)
Security Specifications
Messaging Specifications
Metadata Specifications
Extensibility-Web Services Enhancements
Extending and Increasing Business
Real-time Business Collaboration Activities
An intuitive assumption

Software Technology

The Technology world has never been surrounded with so many buzzwords, acronyms, ideologies, concepts, blueprints and roadmaps like what we see today. Amidst this entire information overload, businesses and organisations will be hard-pressed to make any sense of all these new technologies and concepts without knowing or understanding at least what and where their business goals, objectives and targets are.

 In case one should forget lessons learnt from the rather recent dotcom bust, technologies that succeed are those that not only can generate the most business revenue, but also create the most value to businesses or consumers. Therefore, technologies conceptualised with the businesses in mind tend to last longer and be more successful than others. These technologies are created to solve the business problems of today and enhance the business values. 

In my opinion, the most recent successful concept that has created the most value in business sense is the introduction of the Mark-up Language. Few variations have been built but none is as successful as the Hypertext Mark-up Language (HTML) and its hugely successful and adopted extensible big brother, the extensible Mark-up Language (XML). Simply put, XML, unlike HTML, allows designers to create their own customised tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organisations. 

XML has evolved tremendously to become one of, if not the main, communication protocol pillar which all IT systems, platforms, applications, and solutions are built on. This big accomplishment says a lot for a technological concept whose roots started only in 1996. With its huge extensible capability, further Mark-ups are created on top of XML to solve specific problems and also to complement XML. Complementing technologies include the XML Schema Definition (XSD) and the extensible Style Language (XSL). 

One of the most common problems that businesses face today is that of integration. There are basically two types of integration issues. The most basic one that almost all businesses face is data integration. This happens when two different data sources, which have implemented varying data structures or schemas, must come together to serve a common need. If a business is of a certain size or scale, another integration headache will arise in the form of application integration. This happens when an application needs to communicate with another by sending messages or data to each other. To make matters worse, in these days of distributed businesses and application computing where boundaries between business units and departments are blurred, the internet has virtually shrunk the whole world and eliminated time zones. Applications must send messages and data to each other over the internet with internet-standardised communication protocols such as Hypertext Transfer Protocol HTTP). As the internet is virtually a De-Militarised Zone, security must be enforced at end-points in the form of a firewall to filter out unwanted input. Even if messages can get past a firewall, the real problem lies when the application you need to communicate with fails to understand what you are trying to say. 

Given all these constraints of integration, further XML-related technologies were brought in under a common technology umbrella called “web services”. A few technology providers created it and vendors to solve the urgent needs of business and thus were built with the businesses in mind. What each of these technologies solves were specific business integration problems: 

• Simple Object Access Protocol (SOAP) specifies a common way to structure the messages sent between machines and business applications.

• Web Service Description Language (WSDL) specifies what the message should look like so that any messages sent can be understood and processed by the publishing machine.

• Universal Description, Discovery, Integration (UDDI) specifies a common way to publish the registered web services of service providers globally and makes it possible for service requesters to find the business and service information efficiently.

In an attempt to standardise web services and accelerate the specifications, a group of experts from these technology providers and vendors gathered together and designed an open specification which was later submitted to a standards body for ratification. These open specifications became actual standards and are widely adopted across a multitude of industry segments. This was done with businesses in mind so as to minimise lost revenues and opportunities resulting from unresolved integration issues.  

As you may have guessed, all these web services messages are zipping across all directions over the internet in XML format. Since these messages are HTTP-friendly, they can pass through firewalls without a hitch. 

The calls of these businesses to solve their problems were further heeded when major system and technology providers and vendors began to rapidly develop and push their solutions and platforms that have web services baked into them and are web services ready in accordance with the industry web services specifications. This goes a long way in solving one of the holy grails of distributed computing in which heterogeneous systems and solutions can talk to one another without worrying about the underlying implemented platform technology. In other words, XML is the common language amongst platform-agnostic systems and solutions. 

Web Services Adoption in Review                                                                                                             ^TOP

 Let us retrace what was just discussed above. I have described how web services of today can solve data and integration problems by having a common standard to structure the messages between applications (SOAP) and using a language to describe and specify how messages should look like when you send it to another application (WSDL) so that it can be processed. So we can envision this scenario where applications are communicating and sending messages and data across the network. If these messages are adhering to common published standards, both data and application integration can happen without a hitch. 

Is this happening in today’s business environments? While analysts in different research houses and think-tanks are reporting different figures, it is apparent that businesses are optimistic about what web services can do for them and that its adoption rate is on an uptrend. There is a positive correlation rate between companies, which have or are adopting some level of web services with regards to their revenue. In other words, the larger the companies, the more adoption activities for web services are in place in these organisations. If we take a closer look into industry adoption patterns, according to Forrester, the financial services are leaders with more than half of banking firms implementing web services into some of their business processes. Insurance, healthcare and eCommerce firms are also investing heavily into web services activities. 

One area that deserves a closer look is that of external adoption of web services. While there is a reported positive uptrend in the internal adoption and use of web services, the same cannot be said for the external use and deployment of web services. While some companies are slowly building a framework and enabling an environment for external adoption to happen, quite a number of other companies remain very questioning and wary of revealing their organisation’s inner workings to the outside world. Chief amongst the reasons for that are concerns about security and trust. Other issue includes messaging delivery reliability. 

This should be hardly surprising. One thing we have to accept is that the external adoption of web services will always lag behind those which happen behind the corporate firewall. It is only natural that businesses want to get it right internally, before they expose their web services externally. After all, a business will always have a stronger image and presence to uphold to its customers and partners than to its internal staff. 

The issue of trust and security is definitely a key concern and major stumbling block to the external adoption of web services. Depending on the soundness of your internal IT security policy, applications and data within a corporate network can and should be able to trust, communicate, and integrate with each other. Alternatively, things are very different outside the firewall. However, business trust can be established with partners and customers with drafting up of Service Level Agreements (SLA), Memorandum of Understandings (MOU) and the likes. Then you have to consider the intermediary World Wide Web Path to get to your customers. Before your message reaches your customers, it has to travel through the De-Militarised Zone. If you are sending confidential account information or receiving the same, this could be potentially dangerous as that information is fair game for anyone sitting in between the end-points. 

In my consulting role with a Systems Integrator which has strong domain presence in the e-Governmental and other business spaces, all governmental organisations and units that I have dealt with place utmost importance on security and trust. Solutions that work must allow them to do their work and serve the country’s needs in a secure and safe manner. It is therefore not uncommon to see security guidelines occupying more than half of the project tender requirements. We are talking about almost every aspect of security such as Authentication, Authorisation, Business and Domain Trust, Confidentiality, Non-Repudiation, Policy Adherence, Data Integrity and Validation, Federation, etc. 

Since web services architectures are based on a computable and modular design based entirely on XML, they are fundamentally extensible to new changes and specifications. However, this flexibility introduces the problem of ensuring that the participants of a web services interaction are using the same set of additional, compatible technologies and specifications. 

 Advanced Specifications of Web Services                                                                                                  ^TOP

 Enter the Standards Bodies of Web Services Interoperability (WS-I) and OASIS who have heeded the call to solve more specific problems. One of their main objectives would be to coordinate the range of standards activity underway in different organisations.

 Web Services Enhancements (WSE)                                                                                                            ^TOP

To keep up with the evolving web services protocol specifications, Microsoft released WSE for .NET as a supported add-on to its Visual Studio .NET and .NET Framework, providing developers the latest advanced web services capabilities. WSE is Microsoft’s opportunity to get ideas out in the field quickly, and solve more delicate, complicated and specific current business application issues, so that businesses can run and operate in true distributed fashion without being hindered by the technology implementation of the underlying systems. 

The WSE is also another step to add support and help realise Microsoft’s vision of web services. WS-* was designed to provide a consistent model for building infrastructure-level protocols for web services and applications. Microsoft has made public statements of its plans to submit WS-* specifications to standards setting bodies for ratification similar to the process taken with WS-Security as the architecture is an open architecture. It allows exploration of the proposed standards that Microsoft, IBM, and others have been working on as part of advanced web services architecture and see how it develops over time. The web services architecture defines a framework that augments the basic web services with generic higher-level services like security, reliability, and transactions, which are required by many distributed applications and are not specific to a particular problem domain. You can find more in-depth articles and information regarding advanced web services at:  

WSE 1.0 was released in December 2002 with implementations of WS-Security and other advanced WS functionality.  

WSE 2.0 was released on 23 June 2003 and builds on WSE 1.0 functionality enabling corporations to build trust relationships with web services communication. There was a good take-up rate amongst the Line-of-Businesses in different vertical business sectors in the version 1 rendition. I expect to see an even stronger adoption uptake in version 2. For more detailed articles and information regarding each version and the specifications it addresses, visit:  

Some web services protocols which WSE supports include WS-Security, WS-Addressing, WS-Policy, WS-Trust, WS-Secure Conversation and WS-Attachment. I will briefly discuss how some of these specifications can help solve the business application issues of today and eliminate the stumbling blocks to the external adoption of web services. 

Security Specifications                                                                                                                               ^TOP

 The likes of WS-Security, WS-Secure Conversation, WS-Trust, WS-Federation, WS-Federation Active Requestor Profile, WS-Federation Passive Requestor Profile, and Web Services Security Kerberos Binding are some of the specifications that make up web services security specifications. The main specification and one of the earliest to be standardised and adopted is WS-Security, which makes it the most matured and acceptable specifications in the web services Industry today. 

The web services security specifications address the weaknesses of transport-layer security protocols when it comes to SOAP Message-oriented communication and integration. Protocols such as Secure Sockets Layer (SSL on HTTPS) encrypt only at the channel of transport and are therefore specific to two end-point communications and can be rather expensive as message payload increases. When using SSL, your application must pay the processing cost of encrypting and decrypting each message. 

WS-Security provides a standard SOAP message-oriented protocol structure to encrypt and decrypt the SOAP message itself. By doing so, SOAP messages will be able to hop along multiple points to reach a specific end-point in a secure fashion. WS-Security also allows granular encryption of the SOAP messages right down to the XML element level which then allows businesses to control the payload of the SOAP messages more effectively and efficiently. Another consideration to use message-layering encryption is also to realise the transport-neutral wonders of web services. WS-Security, as part of the grand objectives of web services, therefore, plays a big part in realising the decoupling of web services from the transport-protocol layer. In other words, because the security is now at the message level, the same secured SOAP message can also be transmitted securely along other transport channels, even on non-secured ones like HTTP. 

WS-Security depends very much on the W3C-endorsed standards of XML Encryption (XML-ENC), XML Digital Signatures (XML-DSIG) and a variety of other security models and encryption technologies. Without delving into technical details, WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. It also provides a general-purpose mechanism for associating security tokens with messages. No specific type of security token is required by WS-Security. It is designed to be extensible (egg. support multiple security token formats). For example, a client might provide proof of identity and proof that they have a particular business certification. Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets, as well as how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message. 

There are five major areas of e-Security, which are critical in business needs today. 

• Authentication – Proving one’s identity to another

• Authorisation – Controlling access to secured resources based on one’s identity

• Confidentiality or privacy – Preventing the eavesdropping of messages sent in transit

• Data integrity – Ensuring the non-tampering of messages sent in transit

• Non-repudiation – Ensuring that the author of the message cannot disavow responsibility

Various common and acceptable security methods already in place today such as the various implementations of Cryptography (Hashing, Symmetric and Asymmetric Algorithm Encryption, and Kerberos), Public-Key Infrastructure (Certificate Authorities and Trust Hierarchy), and Digital Certificates (X509 Certificates) are designed to address the above areas and have been very successful in e-business and e-commerce implementations and transactions. Nonetheless, what was missing is a common standard way to structure the above methods via XML and embed it into transmitted SOAP message so that secure communication interoperability can take place. This is where WS-Security Specifications steps in. 

As it tells implementers exactly how to use these security mechanisms in web services development and implementation, WS-Security solves these critically important problems by allowing disparate systems to communicate with each other in a standard secure manner over the internet. Being supported since WSE1.0, it provided a framework for the application developers to secure SOAP messages. WSE also provides the processing of all incoming and outgoing SOAP messages at the filter level, sparing these developers from technology implementation and focusing on business domain issues and the functional aspects of business solutions instead.

Another noteworthy interesting security specification is WS-Secure Conversation, a relatively new specification. Like other newer specifications, it is built upon WS-Security and defines extensions to request and issue security tokens, and to secure conversations. It supports WS-Security by allowing multi-message conversation scenarios of long duration without repeated use of computationally expensive cryptographic key validations. 

It is imperative to note that WS-Security is neither a new security method nor implementation. It just provides a standard XML structure for implementing the most common security methods into the underlying web services to assure businesses that they can communicate securely with customers and partners in a standard way using matured and acceptable security standards. 

Messaging Specifications                                                                                                                         ^TOP

 Messaging specifications include, amongst others, SOAP, WS-Addressing, MTOM (Attachments), and WS-e-venting. While SOAP is the core specification in this list, WS-Addressing looks set to take off in a big way. It was designed to supersede the specifications of WS-Routing, which is supported in WSE1.0. 

Most distributed applications take advantage of routing in one form or another. Routing is the process where an intermediary, which may be a piece of hardware or software between the sender and receiver, decides where to send an incoming message. While many people may dismiss it at first glance, WS-Addressing is a lot more useful than it sounds. Web services that are in mass adoption now are very much end-point-centric. This implies that end-points know of each other and their implementations fairly well and that the interface of the end-points rarely changes much. This is also known as a “Single-Hop” scenario. As web services grow to serve the increasing demands of businesses, more robust ways must be created to address those weaknesses. Business processes that create the most value tend to span across multiple points, either in the departmental or organisational level. Many times, the starting point of the entire process does not know who or where the end-point is, and even if they do, this end-point may not be an end in itself. It may just be acting as logical messengers to route requests to the next correct appropriate point for further processing and this goes on until it finds the end results. The results will then be returned to the sender via the same return route or through another different way. In an organisation, some such intermediary or end-point nodes may also be operating behind Network Address Translator (NAT)-based routers. Therefore, they may not be that straightforward in sending a response back to the originator if the process takes a while to complete. To add more complexity into this equation, some processes may take the message through a different mode of transport. So even while two end-points are on a HTTP channel, the in-between intermediaries that are crucial to the completion of the whole process are operating in a transport channel other than HTTP, such as email (SMTP). 

WS-Routing was the first specification to tackle this issue by providing the capability to specify message routing and dispatching information in a transport-neutral way. However, while WS-Routing offers some interesting possibilities, it also brought a set of other challenges which come mainly as message digital signatures at the intermediaries. 

WS-Addressing was then crafted in to simplify WS-Routing and mitigate the security challenges mentioned. As an improvement to WS-Routing, which already provided a transport-neutral mechanism for addressing web services, WS-Addressing formalises the simplification of WS-Routing and added features as well. This facilitates the transition to a “Multiple-Point-Hop” Routing scenario where messages can be sent to just a single end-point, which will take care of additional routing needs behind closed doors. 

It is interesting to note that WS-Addressing has been submitted to W3C for ratification recently. This is also done with SUN on board, which bodes, very well for the advancements of Web Services Standards. 

We have already implemented web services routing capabilities in a couple of projects for our clients. Besides the problems I have described above, another scenario that is extremely useful in implementing web services routing is in environments where business trust is important. For governmental projects and clients, even trust between two divisions of the same organisation must be established before communications can be initialised. 

A common situation, which we frequently encounter, is with units and departments with applications and data hosted in environments behind the corporate firewall that can only be accessed via a single or few trusted intermediaries through a secure leased line. We had to implement a pilot project where this data needs to be consumed by another party within the same organisation. The caveat is that the consuming party does not have direct access to the environment hosting the data and the data host is not going to let the consuming party through due to its IT Trust Policies. However, both parties share a common lifeline in a shared and trusted intermediary. (See Fig. 1 below) Of course, an alternative was to create multiple web services and implement them at each of the three locations. Although viable, this solution requires much effort in terms of application configuration and maintainability. Web services routing/addressing/referral offers a much more elegant and better solution by having a SOAP Router implementation at the intermediary end-point. This requires a much smaller installation footprint and offers better scalability and maintainability for additions or changes in end-point addresses without any recompilation work. These specifications, essentially allows SOAP request messages to be sent through this intermediary node and have this node re-route the requests to the intended end-recipient. WSE offers a very good extensibility model as well that allows us to incorporate other end-user requirements such as logging and content-based routing into our SOAP Router implementation at the intermediary node. Besides enabling us to design a viable and feasible solution that is easy to build, configure and maintain, all features of WSE also allow us to get this project rolled-out in a much shorter to-market time, which really improves margins and returns for both parties. 

As mentioned previously in the security segment, it is very crucial for SOAP messages to remain transport-neutral. Many current implementations of web services fail to provide a mechanism for referencing end-points and dispatching messages without the help of a transport protocol. In doing so, it ties SOAP routing and dispatching to transport specifics and consequently places more demands on the business. The same message cannot be transported over a different transport in a standard way without reworking the development and implementation. 

With the merits established above to carry the security information in the SOAP message itself, the same applies to the end-point referencing and action for the dispatching of the SOAP messages. The resultant architectural design will make it possible for SOAP infrastructure to accommodate a wider range of transports while improving the simplicity and flexibility of SOAP. 

Metadata Specifications                                                                                                                          ^TOP

 Metadata Specifications include WSDL, UDDI, WS-Policy, WS-Policy Assertions, WS-Policy Attachment, WS-Security Policy, WS-Discovery, and WS-Metadata Exchange. These specifications essentially serve as descriptive bindings for web services. While WSDL and UDDI have been formalised and have worked great since the inception of web services, the recent additions of WS-Policy Specifications will only strengthen the adoption rate of advanced web services in the business enterprise. 

As we have learnt, most implementations of web services today are very much end-point-centric. For most scenarios, companies on both sides of this equation are discussing on what goes into the message via meetings, emails or phone calls. This means all these pre-work was done out-of-band. As business processes and messages grew more complex, things started to break down and the cycle slowed down from there. As web services are supposed to be designed with re-usability in mind, pre-work sometimes had to take other customers and partners into account. Thus, more than often, the above out-of-band discussion will fail when another company is introduced into this equation. Security implementations of the web services will further complicate the entire process. 

What is needed is an open specification to describe the message security details. Microsoft and its peers in the WS-I did just that. Such specifications basically inform a calling application what a web service can and cannot do. It also describes how to invoke a specific web service. These policies make it possible for selected web services to be used in more meaningful ways. I will provide a snapshot view of some related WS-Policy Specifications. 

WS-Policy Specification, for instance, informs a web service what security tokens to expect and also the order of preference it has. This is done through a group of policy statements defined in the specifications. WS-Policy Assertions compliments WS-Policy by defining assertions for the mundane details for a successful invocation such as the Text-Encoding, Language, Versioning, etc. WS-Security Policy defines the security assertions of a web service such as defining which parts of the message must be signed or encrypted, and using which mathematical algorithm, how long a message can live before it is discarded, what can be read by an intermediary node before it can be routed to the next recipient and other security-related implementations. 

These policies are enforced when SOAP messages arrive and if they do not conform to the corresponding policy, an error is generated immediately and returned. This will raise the performance benchmarks as well because the target operation is not executed in that event. This will save enterprises lots of processing time and resources as their web services neither have to inspect each header or security token for validity nor if the message has expired. Think of these policies as a more flexible level of XML Schema Validation that predicates what the messages should look like for different parties that are using or implementing it. 

Businesses alike can now consume each other’s web services much more easily by referring to these policies to determine what must be included in the message for it to be successfully processed without resorting to often-unproductive out-of-band meetings and discussions. 

In a nutshell, WS-Policy and WS-Security Policy help application developers and business users author policies that operate a runtime component. For example, the runtime can automatically sign and encrypt a message based on the authored policy without the developer having to write code.  

Extensibility-Web Services Enhancements                                                                                           ^TOP

 On top of all web services specifications that it supports, WSE also allows the further extensibility of SOAP messages through a pipeline of filters that processes both incoming and outgoing SOAP messages. Developers are able to perform further writing, creating or transforming of the message headers or bodies through these filters with very minimal code exposed via the WSE Application Programming Interfaces (APIs). What this means for organisations is an even more robust and extensible way of adopting web services in their specific businesses or industries by allowing industry standards, semantics or vocabulary to coalesce with standard SOAP messages. Examples of recognised industry standards are: 

·    Financial Services – IFX, FIX

·    Healthcare – HL7, HIPAA

·    Supply chain, logistics, and retail – EDI

·    Manufacturing, electronics – Rosetta Net 

Extending and Increasing Business                                                                                                          ^TOP

 Extending and increasing business value with Web Services Adoption Without the coordination of WS-I, its Working Group members and the other respective Web Services Standards Bodies, Microsoft and its peers fear that the promise of web services could be lost beneath a growing pile of competing and conflicting specifications. It has achieved tremendous success in advancing web services specifications to plug the gaping holes of Business Application, Data Integration and Business Collaborations. 

The adoption of web services within the firewall can significantly reduce integration costs; it can also increase the value and the use of shared information amongst business employees. When IT staff aligns itself with customer-facing and revenue-generation activities instead of mere back-end integration work, one very important intangible benefit is the transformation of an organisation’s IT from a cost center into a business center. 

Real-time Business Collaboration Activities                                                                                             ^TOP

 However, web services hold a lot more promises than simply inter-departmental application and data integration implementation. The incumbent Web Service and Technology providers are aggressively making this happen and with Microsoft releasing WSE and implementing the latest web services specifications, web services looks set to be taken to the next level of implementation where businesses, organisations and industry-wide collaboration will feature more prominently. 

Businesses of today realise that the greatest value can be added through near real-time collaboration with its customers and industry partners. Manufacturing, logistics and transport services companies are leaders in using in business collaboration technology. Standards like Electronic Data Interchange (EDI) and Rosetta Net are created to solve the needs of business collaboration with Supply Chain Management and the likes. Therefore, the combination of Industrial Standards and Web services Specifications will propel the industry to adopt web services on a different and larger scale with business and industry collaboration outside of the firewalls. 

I strongly believe the benefits gained and the business value created by the collaboration activities will outweigh those created from integration activities. Benefits include significantly reduced transaction costs, and increased shared information and processes with business or industry partners. The growth in partners’ and customers’ connectivity will result in near real-time dialog with firms across the whole business value chain. Small trading companies, which were previously limited by its relatively smaller pockets for investments in expensive EDI tools are no longer, excluded from this industry value chain. The messaging technology of web services is much cheaper and faster to develop and implement. With .NET, it can be used on existing company infrastructure resulting in faster to-market and turnaround times. Once businesses realise the huge benefits that web services can offer them through business and industry partners and customers collaboration, they will be able to extend their value chain with web services. 

The only major missing piece to the big picture of WS-* and advanced web services is the description of a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. This is addressed in the WS-Reliable Messaging specifications. It would be nice if this was in the next WSE release. WS-Reliable Messaging specifies three types of reliable delivery: guaranteed delivery, which means the message is delivered at least once; duplication elimination, that ensures the message is delivered at most once; and message delivery sequencing, which determines the order messages are delivered. It is only natural for WS-Reliable Messaging to be one of the final pieces because while being able to consistently and reliably send messages from one web service to another is a necessary basic function, it is not substantial on its own. The functions of Security, Federations, Trust, Secure Conversation, Policy, Transactions and Coordination Specifications must be in place to support WS-Reliable Messaging to reach a wider goal of consistency and reliability or it may be unusable in the long run. In my opinion, the specifications of WS-Reliable Messaging are definitely more complete and address more business issues than those of the OASIS Reliable Messaging.  

An intuitive assumption                                                                                                                             ^TOP

The rapid standardisation and acceptance of web services specifications, together with the release of the WSE for Microsoft .NET, provided a much-needed boost for .NET Solution Developers to take their web services implementations beyond the corporate firewall. Eventing With proper messaging security, routing and addressing infrastructure, policy implementation and adherence, and reliable messaging architecture brought on through the introduction of new specifications, the envisioned end result will be the seamless integration of a networked eco-system of business customers, partners and suppliers, with interoperability across heterogeneous systems, thereby, extending the value chain beyond traditional organisational boundaries.