Level: Introductory Arthur Ryman (ryman@ca.ibm.com), Senior Technical Staff Member, WebSphere Studio Development , IBM Toronto Lab
22 Jul 2003 Suitable for both novices and experts, this technical overview by an IBM Web services expert describes the current status of Web services and their evolving standards.
© Copyright International Business Machines Corporation 2000-2003. All rights reserved. The dawn of the service Web In the beginning, there was the Document Web. The Document Web was powered by Web servers that spoke
Hypertext Transfer Protocol (HTTP) and delivered information marked up in Hypertext Markup Language (HTML) for display on Web browsers.
The Document Web was created to serve the needs of scientists who needed to share research papers. Businesses saw that
the Document Web was a good thing, and many businesses created Web sites to advertise their products and services. Then businesses wanted to do transactions with their customers, so the Application Web was created.
The Application Web was powered by Web application servers, such as IBM ® WebSphere® Application Server,
which dynamically generated HTML documents from server-side business logic written in programming languages such as JavaTM.
Web application servers acquired distributed programming capabilities, so that they could scale over multiple machines to handle
large transaction rates. Web application servers also learned to speak Wireless Application Protocol (WAP) and deliver information
marked up in Wireless Markup Language (WML), so that mobile customers could participate in the Application Web. e-business flourished. Then e-businesses wanted to integrate their processes with other e-businesses, so the Service Web was created.
The Service Web is powered by Web application servers that speak Simple Object Access Protocol (SOAP),
and deliver information marked up in Extensible Markup Language (XML). Today, the Service Web is in its adolescence.
We are currently witnessing the rapid maturation and deployment of a stack of interrelated standards that are defining the
infrastructure for the Service Web. The building block of the Service Web is the Web service, a set of related application functions that
can be programmatically invoked over the Internet. The information that an application must have in order to programmatically
invoke a Web service is given by a Web Services Description Language (WSDL) document. WSDL documents can be
indexed in searchable Universal Description, Discovery, and Integration (UDDI) Business Registries
so that developers and applications can locate Web services. This article describes the Service Web, outlines the key standards of SOAP, WSDL, and UDDI, and discusses new
tools for developing Web services. Armed with this information, you should be able to understand how Web services can enhance your
business and how you can begin developing them.
The service Web Web services provide an application integration technology that can be successfully used over the Internet.
To illustrate this integration, consider how the Web is currently used for planning travel. Many Web sites sell airplane tickets,
and most of them are well-designed for personal travel. However, they may not be useful for planning business travel,
because many businesses have internal processes that control travel. A typical business process for travel might require the use of preferred airlines, car rental agencies,
hotels, and travel agents. A travel request might also require management approval to ensure that it is within corporate guidelines
and expense constraints. Employees are highly motivated to follow their employer's business processes since failure to do so may result in
denial of expense claims. A business may provide a travel planning application to help employees prepare travel requests. Suppose you are an employee using your company's travel planning application. If the request form asks you
to fill in your desired flight times, you naturally want to know what flights are available. Since your travel planning application
is not integrated with the airline Web site, you must launch your Web browser, go to the airline Web site,
find the schedule query page, and then enter your origin, destination, and dates and times of travel.
The airline Web application then returns a list of scheduled flights, from which you choose the flight you want.
But since the information on the airline Web page is probably in a different format than that required by the travel application,
you must write down or copy the information, switch back to the travel application, enter the information in the travel application,
and then submit your request. A simple task that should have taken seconds, instead takes minutes, because there is no easy way to integrate
the airline Web application with the corporate travel planning application. Figure 1 shows the weak integration that exists on the Application Web:
Figure 1. Weak Integration on the Application Web
Consider how Web services could change this scenario. Suppose the airline develops a Web service that allows applications to obtain the list of available flights
between two cities on a given date. Now, the corporate travel planning application can programmatically invoke the airline flight
schedule Web service, so that the employee does not have to navigate through the airline Web site. The ease of use of the
corporate travel planning application is greatly improved. There is also a minor benefit to the airline since now its servers are
more responsive. The Web service-based transaction is completed with a single request, whereas the traditional Web site returns
many HTML pages and images to the user. Figure 2 shows how Web services can improve application integration:
Figure 2. Improved Integration on the Service Web
Continuing this scenario, suppose that airlines, hotels, and car rental agencies provide Web services that
allowed applications to programmatically purchase airplane tickets, book hotel rooms, and reserve rental cars. In most cases,
a travel planning application could make all of the necessary arrangements without the aid of a human travel agent. The use of Web services would reduce costs, improve quality, and increase function. For example, suppose the airline
also had a Web service that monitored flight departure and arrival times. The travel planning application could query the airline to
determine if your flight was delayed, and if so, it could then notify your hotel and your car rental company to hold your reservations. Here, the economic motivation for businesses to implement Web services is improved customer service and more
efficient management of inventory. For example, if the car rental agency knows that you will be two hours late, it might be able
to avoid the cost of transporting cars between agencies in order to meet the worst-case peak demand. More interestingly, the widespread implementation of Web services would also enable a whole new wave of
advanced applications. For example, suppose your flight is oversold. Your travel application calls you in the departure lounge on
your WAP phone and asks what you want to do. Your travel application can access an e-marketplace Web service that lists seats on
this flight. If you have a confirmed seat, your travel application asks you if you would like to put your seat up for auction,
shows you the current bids, and lets you specify an asking price. Conversely, if you don't have a confirmed seat, your travel application asks you if you want to bid on a seat,
shows you the current prices, and lets you specify a bid. If you need to check your agenda in order to make a decision, your
travel planning application accesses your corporate calendar application Web service and displays your agenda on the WAP phone.
If you don't have a confirmed seat but really need to get to that meeting on time, the travel application verifies that corporate
expense guidelines are met and approves your bid. If your bid is accepted, the travel application submits the bill to the
corporate expense statement Web service. Figure 3 shows how powerful new applications can be assembled from the Web services of multiple suppliers:
Figure 3. The New Web services Economy
As the number of Web services increases, their interactions will become more complex and we may even begin to
attribute characteristics such as intelligence or self-awareness to the Service Web. The usual vision of artificial intelligence
as arising through some very complex thinking program must be re-evaluated. More likely, intelligence may arise as a network effect.
After all, the brain itself is simply a very complex network of relatively simple neurons. It is likely that the first time a collection
of interacting Web services displays a useful, unanticipated behavior, we will start to think of it as intelligent. For example, suppose you also rent a cell phone with your car, because you want to avoid long distance charges
or because your phone has no local coverage. Suppose also that while driving back from your meeting to the airport, your newly rented
cell phone rings and your travel application tells you that the flight has been delayed. The first time this happens to you,
you might be surprised and you might think the travel application was intelligent, especially if this capability had not been
explicitly programmed into it. This type of apparently intelligent behavior could arise through the following sequence of simple Web service
interactions. When you rented the car and cell phone, the travel application requested the rental agreement from the car rental
agency and submitted it to the corporate expense application. When the expense application received the invoice, it scanned the
items and noticed a cell phone. The expense application then updated the corporate phone directory with the cell phone number.
Later, the travel application requested the departure time from the airline and noticed that it had changed.
The travel application then queried the corporate phone directory, retrieved your new cell phone number, and called you. Most travelers would consider these kinds of notifications very convenient, but other kinds of unanticipated
interactions might be undesirable. As we go forth and bravely build the Service Web, we should build appropriate safeguards and controls
into it in order to prevent undesired consequences. Considerations of security and privacy will be more important on the Service Web than
they are today on the Application Web, and could well become the differentiators between successful e-businesses and their competitors.
Web services standards The Service Web is being built on Internet standards. One of the key attributes of Internet standards is that
they focus on protocols and not on implementations. The Internet is composed of heterogeneous technologies that successfully
interoperate through shared protocols, not shared middleware. No single vendor can impose a standard on the Internet, and no
single programming technology will dominate. Fortunately, Web services standards are being cooperatively developed by IBM,
Microsoft®, Ariba, and many others, and are being submitted to the World Wide Web Consortium (W3C). Open-source software development plays a crucial role in preserving the interoperability of vendor implementations
of standards. To understand this, consider the Apache Web server, which has rapidly gained market share to become the dominant Web server.
The Apache Web server acts as the reference implementation of HTTP. Consider what would happen if the next release of Microsoft
Internet Explorer or Netscape Navigator included a change to HTTP that made it only work with Microsoft Internet Information Server
or Netscape Enterprise Server. The market share of such a vendor-specific Web browser would drop to zero.
The existence of the Apache Web server prevents any Web browser or server vendor from fragmenting HTTP. IBM is actively contributing
implementations of Web services standards to open-source projects in order to ensure interoperability on the Service Web. This section discusses three major Web services standards:
- SOAP
- A standard for messaging over HTTP and other Internet protocols
- WSDL
- A language for precisely describing the programmatic interfaces of Web services
- UDDI
- A business registry standard for indexing Web services, so that their descriptions can be
located by development tools and applications.
Figure 4 shows how these standards are related to each other:
Figure 4. How SOAP, WSDL, and UDDI Are Related
Application servers host Web services and make them accessible using protocols such as HTTP GET, HTTP POST, and SOAP/HTTP.
The Web services are described by WSDL documents, which can be stored on the application server or in special XML repositories.
A WSDL document may reference other WSDL documents and XML Schema (XSD) documents that describe datatypes used by
Web services. An XML repository is useful for managing WSDL and XSD documents. The WSDL documents contain the URLs of the Web services.
The Web services are described and indexed in a UDDI business registry that contains the URLs of the WSDL documents. SOAP SOAP is a standard for sending and receiving messages over the Internet. SOAP was initially proposed by
Microsoft as a way to do Remote Procedure Call (RPC) over HTTP. IBM and other vendors contributed to the development of the
SOAP 1.1 standard, which was then submitted to the W3C. The current SOAP specification allows transports other
than HTTP, and other messaging styles in addition to RPC. The SOAP specification defines an XML envelope for transmitting messages, a method for encoding programmatic
data structures as XML, and a binding for using SOAP over HTTP. These features are best illustrated with an example. Consider a
simple Web service that gives stock quotes. Here is a SOAP request sent over HTTP to the stock quote service: POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.com/stockquote.xsd"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="http://example.com/stockquote.xsd">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
In the above example, the request is being sent to the URL
http://www.stockquoteserver.com/StockQuote. The request specifies that the
GetLastTradePrice operation is to be performed using the symbol DIS. Here is the a SOAP HTTP Response for the above stock quote service request: HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="http://example.com/stockquote.xsd">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
Here, the GetLastTradePriceResponse element contains the DIS price of 34.5.
SOAP is being used in an RPC style in this example. However, SOAP can also be used for one-way message delivery. The SOAP specification defines the SOAP encoding style, which defines a way to express data structures in XML.
The SOAP protocol permits the use of other encoding styles, but this is a potential source of fragmentation, because if a Web service
uses a different encoding style, then its reach is limited to only those applications that support that particular encoding style.
Alternative encoding styles should be used only after careful consideration of the intended users of the Web service.
SOAP messages are not required to use any encoding style in which case the message body is treated as literal XML. The SOAP specification defines a binding for using SOAP over HTTP, but other transports may be used.
For example, Simple Mail Transport Protocol (SMTP) can be used to send SOAP messages to e-mail servers. Using SMTP is useful for
asynchronous message delivery. SOAP is a relatively simple protocol, and is easy to implement, as witnessed by the explosion of implementations.
One of the first implementations was done in Java by developmentor. IBM then released another Java
implementation, called IBM SOAP4J, on the IBM alphaWorks Web site. The SOAP4J implementation was later contributed to the Apache XML project
and was released as Apache SOAP 2.0 which runs on Apache Tomcat, IBM WebSphere Application Server,
and other servlet engines. Microsoft released a SOAP Toolkit for use with Visual Basic.
Many implementations of SOAP are now available, as shown by the list of Web services at XMethods. SOAP has rapidly matured. In the Java world, many Java Specification Requests (JSR) were created to standardize APIs.
The main JSRs are JSR 101, which defines the Java binding for SOAP, and JSR 109,
which defines the deployment model for Web services. These JSRs are included in J2EE 1.4. The Apache Axis
project implements JSR 101, while WebSphere Application Server V5.0.2 implements both JSR 101 and JSR 109. In the Microsoft world,
Web services are supported by ASP.NET, which is part of the .NET Framework. After the SOAP 1.1 specification was submitted to the W3C, it formed the Web services Activity to advance
Web services standards, and created the XML Protocol Working Group to turn SOAP into a W3C standard. Recently, the
SOAP 1.2 specification became a W3C Recommendation. WSDL For an application to use a Web service, the programmatic interface of the Web service must be precisely described.
In this sense, WSDL plays a role analogous to the Interface Definition Language (IDL) used in distributed programming.
The description must include such details as the protocol, host and port number used, the operations that can be performed, the
formats of the input and output messages, and the exceptions that can be thrown. There were several proposals for languages to solve this problem. Microsoft first proposed Service Description
Language (SDL) and provided an implementation of it in their SOAP Toolkit. After reviewing the proposal, IBM countered with the
Network Accessible Service Specification Language (NASSL) and released an implementation of it in SOAP4J as the NASSL Toolkit.
Ideas from NASSL influenced Microsoft's SOAP Contract Language (SCL), which was also planned to describe Web service composition
(also referred to as workflow or orchestration). These proposals converged with input from several other vendors as the
WSDL 1.1 specification, which was then contributed to the W3C. IBM and Microsoft continued to work on Web services
composition and released the Business Process Execution Language for Web services
(BPEL4WS) specification. Here is a WSDL file that describes the stock quote service: <?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/1999/XMLSchema">
<element name="GetLastTradePrice">
<complexType>
<all>
<element name="symbol" type="string"/>
</all>
</complexType>
</element>
<element name="GetLastTradePriceResponse">
<complexType>
<all>
<element name="Price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:GetLastTradePrice"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:GetLastTradePriceResponse"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/stockquote.xsd"/>
<input>
<soap:body use="encoded" namespace="http://example.com/stockquote.xsd"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded" namespace="http://example.com/stockquote.xsd"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://www.stockquoteserver.com/StockQuote"/>
</port>
</service>
</definitions>
|
The file begins with type definitions for GetLastTradePrice and GetLastTradePriceResponse using XML Schema.
The remainder of the file builds up the Web service definition by assembling the types into messages, the messages into
operations, and the operations into port types. It then binds the port type to the SOAP/HTTP protocol, and finally assigns it the
address http://www.stockquoteserver.com. As is evident, this file is complex. Its construction is best left to tools
that generate it automatically from simple parameters specified by the developer. A notable feature of WSDL is that interfaces are defined abstractly using XML Schema and then bound to
concrete representations appropriate for the protocol. WSDL has predefined bindings for the protocols HTTP GET, HTTP POST, and
SOAP/HTTP, but is extensible. For example, in the case of HTTP GET, the binding specifies that the input message is encoded in a
URL of an XML request body. WSDL permits the description document to be composed from parts using an import mechanism. It is useful to put
the abstract definitions in a separate file, so that they can be imported by many concrete bindings. For example, the travel
industry could define an abstract flight schedule Web service interface, which would then have concrete bindings by many airlines.
Each airline would create its own WSDL file that specified the protocols, hosts, and port numbers used by the airline's application
servers, and would import the abstract definition of the Web service from the travel industry's XML repository. WSDL is being standardized by the W3C Web Services Description Working
Group which is part of the Web services activity, and drafts of the WSDL 1.2 specification are
available for public review. UDDI UDDI addresses the problem of how to find Web services. UDDI defines a business registry where Web service
providers can register services, and where developers and applications can find them. IBM, Microsoft, and Ariba implemented
the original UDDI registries, but other vendors now also have implementations. A service provider
only has to register a Web service at one of the business registries, because updates to any registry will be replicated
in all of the other registries that are part of the UDDI Business Registry Network. Figure 5 shows how the UDDI Business Registry Network is used by providers and users of Web services:
Figure 5. The UDDI Business Registry Network
UDDI is based on four types of entity: Business Entity, Business Service, Binding Template, and Technology Model: - A Business Entity describes the business that is providing the services. The Business Entity description
includes categorization information so that searches can be performed for specific types of businesses.
- A Business Service is a class of services within a business. Each Business Service belongs to some Business Entity.
- The Binding Template and Technology Model (tModel) together define a Web service as described by WSDL. The tModel corresponds to
the abstract description and the Binding Template corresponds to its concrete binding to a protocol. Each Binding Template
belongs to some Business Service, but many Binding Templates can refer to the same tModel. A UDDI business registry
is itself a SOAP Web service. It provides operations to create, modify, delete, and query each of the four entity types.
You can use UDDI at both development time and run time. At development time, you can search the registry
for suitable services and use it to locate the appropriate WSDL file. Development tools can then be used to generate client proxies
from the WSDL files so that the application can access the service. At run time, the application does not have to use UDDI if the
target Web service is fixed and always available. However, if the Web service becomes unavailable, the application can query the
registry to determine if the service has been moved to another location. This capability is useful when service providers have to
rehost their services. UDDI can also be used at run time, for example, to determine all available services that implement some interface.
For example, all car rental agencies could be located and queried at run time to find the lowest rates or the best availability at
that moment. The UDDI specification is being standardized by OASIS, along with new Web services
standards for security, reliability, and other enterprise computing qualities of service.
Development tools Although SOAP, WSDL, and UDDI form the infrastructure for Web services, developers should be shielded from
their details, so that they can focus on the business problem being solved. Development tools that facilitate Web services
development are now available. Early versions of several IBM development tools, such as the WSDL Toolkit, the Web Services Toolkit, and the
IBM XML and Web Services Development Environment, appeared on the IBM alphaWorks Web site, which continues
to host emerging Web services technology. The IBM XML and Web Services Development Environment is now integrated into the
IBM WebSphere Studio product, which contains a full suite of Java, J2EE, Web, XML, data, and Web services tools along with
tools for building, debugging, testing, deploying, and profiling applications. Figure 6 shows the WebSphere Studio desktop:
Figure 6. WebSphere Studio desktop
The Navigator pane shows the projects, folders, and files in the currently open workspace. The Editor pane
contains two open files: StockQuoteService.java and StockQuoteServiceSoapBindingStub.java. Many files may be open at once, but
only one at a time can be selected for editing. You select the files using the tabs at the top of the pane. When a file is
selected, its contents are displayed and it is outlined in the Outline pane. Parts of the file can be selected by clicking in the
Outline pane. The All Tasks pane lists problems in the solution. Double-clicking on a task opens the file and scrolls it to the
line where the problem occurred. WebSphere Studio has a built-in Java development environment and a set of XML and Web services development
tools. The XML tools include editors for XSD and WSDL. The Web services tools include a wizard that can create a Web service from a
Java class, an EJB, or a set of SQL statements. The wizard can then generate a WSDL file that describes the Web service,
generate a Java client proxy and server skeleton from a WSDL file, generate a Web test client from a WSDL file,
and explore the Web services in a UDDI Business Registry. The Web services wizard frees you from dealing with the details of XML,
SOAP, WSDL, and UDDI, and lets you focus on the business problem at hand. For more information on the Web services tools
in WebSphere Studio, see the IBM Systems Journal article or the book chapter in
Java Web Services Unleashed.
Interoperability The key value business value of Web services is that they enable interoperability of applications that use
different hardware, operating systems, programming languages, or middleware. While SOAP, WSDL, and UDDI are a good starting point,
they contain too many features to ensure consistent implementation and interoperability. For example, early experience with SOAP
exposed problems in achieving interoperability when using SOAP encoding. To ensure that Web services were interoperable, IBM,
Microsoft, and other vendors formed the Web Services Interoperability Organization (WS-I.org).
The membership of WS-I.org includes all major vendors and many customers, so there is good reason to believe that interoperability
will become a reality in the near future. WS-I.org established a Basic Profile 1.0 that clarifies the specifications for SOAP, WSDL, and UDDI, and
identifies a subset of features that can be implemented by all vendors in an interoperable way. The Basic Profile 1.0, which
covers SOAP, WSDL, and UDDI, is in the final stages of approval and is part of J2EE 1.4. WebSphere Application Server V5.0.2 and
WebSphere Studio V5.1 will enable the creation of WS-I.org compliant Web services. The Basic Profile 1.1 will include support for
SOAP with Attachments and WS-Security.
SOAP with Attachments allows binary documents, such as images, to be efficiently transported with XML SOAP messages.
WS-Security defines how portions of SOAP messages can be digitally signed or encrypted. As new key Web services standards emerge,
they will be added to future WS-I.org profiles.
Conclusion The next generation of advanced Web applications will be constructed from Web services building blocks. By
developing Web services, businesses enable their applications to be integrated into the processes of their suppliers, partners, and
customers, yielding improved function, reduced costs, and competitive advantage. Web services are based on open, implementation-neutral standards such as XML, SOAP, WSDL, and UDDI.
The Web services infrastructure is now ready for serious consideration by businesses. Development tools that support Web services standards are available and IBM has a full-featured suite of Web
services tools in WebSphere Studio. We hope that this article has motivated you to look into this exciting new technology.
Try out our tools and send us your feedback.
Questions from users Question
A great article! A lot of useful info in a short space! Just a few points. How the WSDL is actually used by the developer
could be expanded. You mention that if a Web service is down, the UDDI can be dynamically searched for another service.
But you don't say how to change the proxy object so that the call can be made to the newly identified service. Response from author
If the client proxy fails to connect to a Web service, the reason might be that the Web service location has changed.
If the Web service description if published in UDDI, then the application can dynamically query UDDI to obtain the current location.
A Java application can use the UDDI4J class library to simplify the task of querying the UDDI registry and obtaining
the new Web service location. If a new location is found, then the application can set the new value into the proxy.
In the Apache SOAP run time, client proxies have a setEndpoint(url) method that you can use for this purpose.
In JAX-RPC client proxies, the endpoint url is a property, for example: ((javax.xml.rpc.Stub)myproxy)._setProperty("javax.xml.rpc.service.endpoint.address",urlstring); |
To see additional user comments, click the View results button below.
Top of page
Resources
About the author  | | |
Arthur Ryman
, PhD, is a Senior Technical Staff Member and the Solution Architect for the IBM XML and Web Services Development Environment at the IBM Toronto Lab, where he has worked since 1982. He is a Member of the IBM Academy of Technology, an Adjunct Professor of Computer Science at York University in Toronto, and a Sun Certified Java Programmer. You can reach Arthur at
ryman@ca.ibm.com
.
|
Rate this page
| 
