Friday, December 19, 2003
WSDL
Web Service Description Language (WSDL) is an XML document standard defined to describe a SOAP web service. Specifically, a WSDL defines the message, portType, binding and services of a Web Service. The message is basically the XML schema of the SOAP envelope contents, including message structure and the data types used in the message. The portType describes groups of operations (methods) including input and output messages (parameters). The binding describes the specifics of a portType, including style and soapAction. Finally, the service section describes the location of the Web Service, which is often a URL.
WSDLs are consumed by programs which create proxy classes such as wsdltojava from Apache Axis, which generates Java, or wsdl.exe in .NET, which generates VB, C#, or JS. WSDLs are also consumed by Web Service messaging products such as XML Spy Pro and Microsoft InfoPath.
WSDLs are created from classes by javatowsdl or directly by Web Service servers. IIS automatically produces a WSDL for a .NET Web Service. Axis will produce a WSDL from a jws file, which I will discuss next week.
What this means to the enterprise
Simply wrapping a legacy application in a Web Service is very powerfull. This allows Web Service enabled application, such as Microsoft Office, to talk to the Applications (more easily). The preliminary schema validation of the message occurred client side, with no additional programming. This validation, combined with the definition of a specific message description in the WSDL, including readable legacy field names with some meaning, enabled a user, to build an application that consumed this web service.
References
Friday, December 12, 2003
UDDI
UDDI
Universal Discovery Description and Integration (UDDI) is a protocol standard for Web Services repository. Specifically UDDI allows for storage and searching of web service WSDL files and associated information, like web service descriptions, provider information, and categories. Currently UDDI V3 is in beta implementation at the IBM, Microsoft, and SAP sites listed below. You can register and search for Web Services at these sites. The standard describes Web Services for publishing and searching for Web Services.
Support
Microsoft provides UDDI support in Visual Studio and Office for locating and consuming web services, addition to an SDK to publish and search. Also, UDDI services are delivered with Windows 2003 Server.
Also, there is a java UDDI server available on sourceforge and there are java APIs for accessing UDDI, including uddi4j and JAXR. However, using the Web Services described at the sites below is most likely a preferred method to search a UDDI registry.
UBR
Universal Business Registry (UBR) is a specific implementation of the UDDI V2 standard for search for businesses and business web services.
What this means to the enterprise
When an enterprise supports SOAP Web Services for data access, form definitions, and db actions, these Web Services could be published in a local directory at a clients sight. A design tool could search UDDI like the way it searches for web pages today through a search engine. These local UDDI searches could be combined with searches to multiple local servers and Internet based UDDI servers. Since Web Services are the end result of any UDDI search, this would be most appropriate for a developer in a forms designer scenario.
References
Sunday, December 7, 2003
SQLXML
SQLXML is a really interesting feature of Microsoft SQL Server 2000. It allows you to send SQL statements or XML queries to the server and get XML back. For instance you can send a SELECT statement to get back a list of currency codes. This would be very useful in an SEA style web applications. It also has support for SOAP Web Services, XPath queries, and SQL templates for other operations, like UPDATE and INSERT.
Since SQLXML is accepting SQL and making the database queries through native drivers, it should perform and scale significantly better than DME.
Authentication and Security
Authentication is managed by IIS virtual directory permissions. Since this utility is native to SQL Server database, security would be limited to the table and column security managed directly by the database. Lawson currently has a utility to dump SQL statements from LAUA data, bldibmsec for db2, to a script file. This script is executed on the database and applies grant/revoke privileges to table and column entities. This native database security is used to secure direct database access with ODBC, OleDB etc and would apply to SQLXML access.
What this means to the enterprise
I believe that it would be possible use to SQLXML to access enterprise Database Information. This would provide direct URL based XML data access without the need to go through a custom DB layer. The drawbacks include lack of support for metadata and custom security. Also, Oracle and DB2 support for an SQLXML standard is not clear. Giving SQL database access to application developers provides more flexibility and also opens the door for problems like database tuning, index design, and SQL syntax issues between db vendors.
More Information
http://www.sqlxml.org/
http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001300
Friday, November 28, 2003
Microsoft and Web Services
Microsoft has been one of the leaders in driving the definition of SOAP web services. Microsoft's web service story is strong, and the future direction of Microsoft appears to depend on a SOAP web services backbone. So much so that they are calling it a programming paradigm switch from Object Oriented Architecture to Services Oriented Architecture (SOA). Here is a link to a slide from a recent Microsoft web presentation on this topic: http://stitch/IOSTEST/obj%20to%20serv.bmp.
.NET Web Services
The simplest way to write a web service is to write an asmx program. This example is a C# web service , which I've put out at the following link: http://stitch/IOSTEST/ATest.txt. When you run the web service, at http://stitch/IOSTEST/ATest.asmx, it shows you a list of methods. You can click "Service Description" to get the WSDL describing this web service. If you want to deploy this locally, you will need IIS running and the .NET platform installed. The default style of a .NET web service is document.
In visual studio, you can also create a web service with a wizard, which walks you through creating a program similar to the one shown here.
Consuming Web Services in Visual Studio
In addition to a SOAP api for .NET, Visual Studio .NET has a built in web service proxy creation utility, allowing you to call a web service as if it was a local class. The proxy handles the SOAP communication and some naming conversion if needed. To use it, you create a "Web Reference" using a URL of the WSDL. Then you can work with the class as if it was local. This makes it pretty simple. Both rpc style and document style web service proxy classes can be created as a Web Reference.
Consuming Web Services in Office
The new version of Microsoft Office has some built in support for web services, specifically, the new application InfoPath. InfoPath is a forms painter that can use XML, ADO, or web services as a data source. For web services, you tell it the URL of the WSDL and it parses the schema to determine the element names which are mapped to fields. You can drag fields onto the form and change the field properties, like color, check box, background color, etc. Then you can add a button and map the button to "submit" to the web service. This sends a SOAP request to the web service and the response data is populated back to the form.
Friday, November 21, 2003
Web Services
Although Web Services can be widely defined as HTTP and XML, a more common modern definition is XML/SOAP/WSDL. They are typically used for computer to computer application invocation when the same technology is not guaranteed. SOAP can be viewed as an XML wrapper used to define the namespace, schema and "method" name of the payload. SOAP is a standard XML namespace governed by W3C. It is human readable, simple and language/technology agnostic. Apache Tomcat w/ Axis and IIS w/ .NET are 2 free servers that can both accept SOAP requests and return SOAP responses.
The other part of web services is WSDL: Web Service Description Language. This is a standard 4 part XML document that defines the message (schema), port, binding and service. The servers mentioned above generate WSDL documents for each web services. There are also utility programs that will generate classes or interfaces from a WSDL, like wsdltojava and xsd.exe.
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<m:getStateName xmlns:m="http://www.soapware.org/">
<statenum>41</statenum>
</m:getStateName>
</SOAP:Body>
</SOAP:Envelope>
Document vs. RPC Style
These are the two primary types of web services. RPC or Remote Procedure Call style is similar to extending a method to remote consumers. By default Axis returns RPC style web services. Document style is more free form, using the XML document schema to define the message. The style is defined in the operation section of the WSDL document.
Web Service Consumers
Both Java and .NET languages, like C#, can easily consume SOAP web services. I'll talk more about this next week.
References
http://www-106.ibm.com/developerworks/webservices/library/ws-docstyle.html
http://radio.weblogs.com/0101679/stories/2002/03/16/aGentleIntroductionToSoap.html
http://www.w3.org/TR/SOAP/
XMethods List of Web Services
http://www.xmethods.org/ve2/Directory.po;jsessionid=RuOWqay9nCAzSNSMmolYh-o6(QhxieSRM)