WSDL and Artix
Fundamental to Artix is a service-oriented view of application development. Artix services are loosely coupled and tightly contracted interfaces between business systems and their underlying middleware mechanisms. Artix uses Web Services Description Language to express the logical interaction between such service. This separates the service from its underlying middleware mechanism, and allows the service to be invoked over an optimized connection using existing transport mechanisms such as MQSeries, Tuxedo and Web Services.
Enterprise Service Contracts
The benefits obtained from following a standard is what makes these standards widely accepted. So what matters for railroad services, for example, is that train tracks built by different companies come together, or that products from several companies work together.
Several vendors have come together in order to establish Web services standards. One of the specifications that make up Web Services is the Web Services Description Language, or WSDL.
WSDL provides a way for Web service providers and users of such services to work together easily. It is easy for train tracks built by several firms to come together: all they have to agree on is the standard distance between the two rails. For Web services, it's much more complex. We first have to agree on a standard format for specifying interfaces.
More than just Web Services
Adopting an SOA (Service-Oriented Architecture) has always been a underlying proposition, as there has not been a way to model the services independently from the middleware or implementation. The landscape has changed with WSDL, and for the first time there is a standard way of modeling diverse enterprise systems in a technology-neutral way.
Besides the strong developer, ISV and industry momentum for WSDL, why is WSDL ideal as a universal service contract definition language?
Strong Type System: WSDL provides XML Schema, the most comprehensive type system, the industry has yet seen. In addition, the WSDL is not limited to a single middleware. For instance, JAVA mappings have been standardized for WSDL, by way of the JAX-RPC specifications.
Logical and Physical Contracts: The logical contract describes the component interface, which is independent of the implementation (C++, JAVA, Cobol, etc.) and the middleware (HTTP, JMS, CORBA, MQ, Tibco, etc.). The physical contract describes the middleware layer, namely what payload format and transports are used. For a Web service this would be SOAP and HTTP.
Extensibility: The extensibility of WSDL provides headroom for policies as well as transports and payload formats. Providing policies for security, transaction, and routing is easily achieved.
So where are the Gaps?
With Artix IONA has taken WSDL beyond simple Web services by extending the features of WSDL to model diverse enterprise systems in a technology neutral way.
Other middleware bindings: It is important to note that as typed systems have more standards-based WSDL extensors, it becomes easier to map between the logical components, allowing them to be bound to different physical contracts as needs arise. This allows for applications transports to be upgraded or changed without impacting the code. The physical contract can be mapped to various transports, allowing for a vendor neutral way of creating application logic with extensions for each specific middleware. Sample mappings are shown below for the major standards and defector middleware.
|
Transport |
Binding |
Port |
|---|---|---|
|
Web Services |
SOAP |
HTTP |
|
MQSeries |
Application Specific |
MQSeries |
|
Tuxedo |
FML |
Tuxedo |
|
Tibco |
TibMsg |
Tibco |
|
CORBA |
IIOP |
IIOP |
|
JMS |
XML |
Implementation Specific |
C++ WSDL mapping: There is no standards based C++ mapping for WSDL at this point, but IONA is in the process of working with key clients to define the WSDL to C++ mapping.
Security: At the basic level, wire level security is provided in the Web Service infrastructure. This can be configured in the WSDL port extensors. The WSDL UseSecureSockets parameter is set and additional values to configure the certificates can be added in conjunction with the HTTP 1.1 specification.
The more interesting part of the discussion is the ability of WSDL to handle authorization and authentication from a security provider, using for example, security principle, token or username and password. This can be achieved by setting the WS-security SOAP header properties or by loading these parameters into the values supplied by HTTP 1.1. The supporting security infrastructure will use LDAP or a commercial security package to hold the user's roles and privileges.
Transactions: As with security, WSDL contracts also need to be transactional. This includes both the ability to participate in the transaction and the ability to propagate transaction context between the different middleware used. Both implicit transactions and propagation can be easily modeled into the WSDL contracts. The key concept is that all aspects of the service's contract need to be declaratively expressed in the WSDL, which it allows.
Connection transparency: Connection transparency is required to make the adoption of the technology scalable for large-scale deployment. This means that large numbers of clients must be able to connect to a mid-tier in a manageable load balanced way. Mechanisms to expand the point-to-point nature of Web services need to be either created as application services, or provided as part of the infrastructure. UDDI does not provide the range of capabilities required, and customers cannot deploy it for large-scale environments that involve 10,000 clients and 1000's of servers with nearly real time lookup requirements. However, well understood and enterprise proven mechanisms of 'locate forward' can be used with WSDL to achieve connection transparency.
Conversational state: Conversational state is required for many mid-tier systems, as most of the services built in the early 1990's were created without Web services in mind. However, many cases are combinations of state-full and state-less components, and some cases have singleton implementations. In order to bridge the impedance mismatch between the tiers, either an application protocol needs to be created to maintain and manage state, or the infrastructure is required to provide these services. Conversational state, or state abstraction, needs to be able to associate multiple interfaces with a session context, manage the context and protect the interface state from corruption, while still being connection transparent. Conversational state is in essence a policy that needs to be reflected into the contract.
IN DEVELOPER CENTER...
Related Content
Need More Info?
Feel free to reach us by phone or email anytime of the day.
> View Phone Numbers
> Contact Us Form