With all the media attention to Web Services and now SOA it is an interesting exercise to look back at the steps we took to get here. Hind site is 20-20 and the dead ends that we followed are just memories so the evolution is pretty clear.
DEC VMS
Digital Equipment Corp, maker of the MicroVAX, boasted the first common language programming environment. Meaning that any of the languages, FORTRAN, COBOL, Bliss, etc., could call procedures from the other languages and the VMS runtime and system services libraries. This of course was not across the network, but it did begin the journey toward loosely coupled systems by allowing systems written in different languages to call each other, which was a huge step in code/library reuse. Perhaps the biggest hurdle was mapping datatypes from one language to another.
RPC
The Remote Procedure Call (RPC) allowed a program to call a function/procedure across machine boundaries. The programmer used Interface Definition Language (IDL) to "design" an API and generate a stub and skeleton code. The skeleton code had to be filled in with the remote side code and the stub code was used locally to call the remote procedure. Again, datatype mapping issues where the biggest issue here.
CORBA
Common Object Request Broker Architecture. Besides being a mouthful, CORBA extended RPC calls into a the object oriented world. While CORBA is still viable, Web Services have all but replaced the need for it.
CGI
Right around the time the HTML became popular the Common Gateway Interface (CGI) became the way to deliver dynamic HTML. This was pretty clumbsy because the entire payload had to be generated every time. So, this gave way to just delivering the data from a CGI and parsing the bits (typically CSV) in a hidden frame using JavaScript allowed two things. The UI could be separated from the Web Tier allowing the Web programmer to focus on the user experience instead of interfacing with the backend system. It also opened up the possibility of having more than one client use the same backend. CGI gave way to Java Servlets with better performance.
XML/HTTP
With Servlets dishing up CSV and text blobs to clients, along came XML. At first XML was more of a pain than a help. That is, dealing with it with Javascript, C, or even Java was not easy, reliable, or efficient, until it was widely supported. Soon every language had very good XML parsers and some even saved code. Eventually, the parsers, like SAX and now StAX, made performance only a minor consideration.
XSD
Since XML representations of data can vary greatly the correctness of XML, and so the usefulness of it, varies too. For instance, repeating elements with different meanings, missing or badly named elements are often used. Adding a schema definition XSD or previously DTD provides structure and common datatype definition to XML. Basically, it evolves to better XML. XSD also allows for a message definition and client side message validation. Without XSD, message definition was left to user documentation and server side message validation required a round trip to the server to verify simple things like required elements.
SOAP
Simple Object Access Protocol is really just a combination of the RPC mechanism and XML/XSD. SOAP defines the service operations (functions) and XSD defines the operation payloads (request and response). Typical clients generate stubs and proxy classes to use when calling a SOAP service. The details of the call are handled by the generated code, like the Axis2 client from Apache, wsdl2java or a Web Reference in Visual Studio. The classes acts much like a local object call.
The REST
RESTful services are in interesting evolution or de-evolution. They offer a simpler call interface yet still provide XSD/XML output. Because of the simple use, REST could gain significant popularity.
WS-*
The need for increased functionality from Web Services has pushed for Security, ReliableMessaging, etc. As the standards evolve, so does the usablility.
Wednesday, January 10, 2007
Tuesday, October 18, 2005
BPEL
BPEL
BPEL stands for Business Process and Execution Language. It is a standard from the Oasis group for defining Web Services Orchestration. That is, it is an XML process flow language for calling and defining Web Services. Some of the language constructs are: while loop, invoke, request, response, sequence, etc. A coder will build a BPEL flow and deploy it in a server like BPWS4J or WebSphere Application Server (WAS). BPEL combines and replaces IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG specification. (BPEL is also sometimes identified as BPELWS or BPEL4WS.)
BPEL Tools
The IBM WebSphere Business Integration Modeler
http://www-306.ibm.com/software/integration/wbimodeler/faq/faq_51.html http://www.microsoft.com/technet/prodtechnol/biztalk/biztalk2004/planning/bpm-solution-overview.mspx
BPEL stands for Business Process and Execution Language. It is a standard from the Oasis group for defining Web Services Orchestration. That is, it is an XML process flow language for calling and defining Web Services. Some of the language constructs are: while loop, invoke, request, response, sequence, etc. A coder will build a BPEL flow and deploy it in a server like BPWS4J or WebSphere Application Server (WAS). BPEL combines and replaces IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG specification. (BPEL is also sometimes identified as BPELWS or BPEL4WS.)
BPEL Tools
The IBM WebSphere Business Integration Modeler
- Eclipse plug-in
- graphical tool
- Supposed to export to WSDL and BPEL, but the export wizard failed to start for me
- Can import XSD but not WSDL (for referencing existing web services)
- I think the idea of this product is to export to BPEL and import into the IBM WebSphere Studio Application Developer Integration Edition (WSAD - IE)
- Deployment in WAS
IBM BPEL4WS editor or BPWS4J editor
- plug-in for eclipse
- table drive (not drag and drop)
- very basic, you have to fill in much of the information
- Saves to BPEL (this does actually work)
- Provides error messages, but doesn't help you fix them
- Double click properties doesn't work
- Deployment in BPWS4J runtime
I think both of these are free downloads
Microsoft Visual Studio Orchestration Designer
- BPEL compliant
- Deployment to Biztalk
BPEL and enterprise software
Currently proprietary work flow products do not all provide BPEL compatibility. Neither do all the Web Services as a standard interface for the legacy application. As Web Services are added, it might make sense for the work flow to support BPEL and export flows to BPEL for customers to use as a midlevel solution. High end solutions might be IBM's Business Modeler.
References
Friday, April 9, 2004
Object COBOL
Description
In December of 2002 a standard for a new version of COBOL was ratified, Object COBOL. Before you laugh, listen up! They added syntax to the 40 year old language to create class instances and invoke methods in those classes. This means 2 major things: First: the class instances can be activated as a thread instead of a process and pooled in an application server. Second: Interoperability between other OO languages and COBOL is possible. That is, Java can call COBOL and the COBOL can call Java.
The syntax is a little clunky primarily because the period (".") is already used to mark the end of a sentence in COBOL. So, there is a little redirection. For instance the following syntax might be used to create an object instance and then call the ?GetHelloWorld() method.
INVOKE ABC-CLASS "NEW" RETURNING XYZ.
INVOKE XYZ "GETHELLOWORLD" USING "MYNAME" RETURNING MY-NAME.
Microfocus, Fujitsu and IBM are compilers available for Object COBOL.
Fujitsu
The Fujitsu NetCOBOL for .NET product produces a dll of "managed" classes that run in the Microsoft .NET Framework. The .NET application server installs with Windows 2003 server. The application pooling and scaling is managed from IIS 6 application console. Interoperability between .NET classes and the COBOL follows the Object COBOL standard. Visual Studio 2003 for .NET is the development environment.
Microfocus
Microfocus NetExpress has 2 variations, one for J2EE interop and one for .NET. The NetExpress class declaration syntax breaks from the Object COBOL standard slightly, but is basically straight forward. Microfocus has its own application server to provide interop between a J2EE app server and the COBOL. The Java version IDE is also a Microfocus product. The .NET version is similar to Fujitsu where the IDE is Visual Studio and the app server is .NET.
Additional References
http://www.aboutlegacycoding.com/default.htm?AURL=%2FArticles%2FV%2FV60101%2Easp
In December of 2002 a standard for a new version of COBOL was ratified, Object COBOL. Before you laugh, listen up! They added syntax to the 40 year old language to create class instances and invoke methods in those classes. This means 2 major things: First: the class instances can be activated as a thread instead of a process and pooled in an application server. Second: Interoperability between other OO languages and COBOL is possible. That is, Java can call COBOL and the COBOL can call Java.
The syntax is a little clunky primarily because the period (".") is already used to mark the end of a sentence in COBOL. So, there is a little redirection. For instance the following syntax might be used to create an object instance and then call the ?GetHelloWorld() method.
INVOKE ABC-CLASS "NEW" RETURNING XYZ.
INVOKE XYZ "GETHELLOWORLD" USING "MYNAME" RETURNING MY-NAME.
Microfocus, Fujitsu and IBM are compilers available for Object COBOL.
Fujitsu
The Fujitsu NetCOBOL for .NET product produces a dll of "managed" classes that run in the Microsoft .NET Framework. The .NET application server installs with Windows 2003 server. The application pooling and scaling is managed from IIS 6 application console. Interoperability between .NET classes and the COBOL follows the Object COBOL standard. Visual Studio 2003 for .NET is the development environment.
Microfocus
Microfocus NetExpress has 2 variations, one for J2EE interop and one for .NET. The NetExpress class declaration syntax breaks from the Object COBOL standard slightly, but is basically straight forward. Microfocus has its own application server to provide interop between a J2EE app server and the COBOL. The Java version IDE is also a Microfocus product. The .NET version is similar to Fujitsu where the IDE is Visual Studio and the app server is .NET.
Additional References
Friday, February 27, 2004
Apache Axis
Apache Axis
As a follow-on to the Apache SOAP project and built on Tomcat, Apache Axis is a Java Web Service deployment server. Axis conforms to SOAP by implementing the JAX-RPC API.
JWS
Axis has a simple way to deploy Web Services, the JWS file. This is a java class with methods that accept and return primitive classes, like String and Integer. The classes are saved in the axis tomcat webapp directory with the .jws extension. Axis compiles the java and generates a WSDL.
WSDD
Axis uses Web Service Deployment Descriptors (WSDD) to describe, register and deploy Web Services in the server. While document style can be specified when deploying a Web Service, currently only primitive parameters can be passed.
What this means to enterprise software
It would be possible to use Axis to deploy SOAP Web Services. It would, however, be limited to Tomcat installations and each of the Web Services would have to be registered with a separate generated WSDD. Also, the current version of Axis does not support document literal Web Services, which is required for Microsoft integration.
References
http://ws.apache.org/axis/
As a follow-on to the Apache SOAP project and built on Tomcat, Apache Axis is a Java Web Service deployment server. Axis conforms to SOAP by implementing the JAX-RPC API.
JWS
Axis has a simple way to deploy Web Services, the JWS file. This is a java class with methods that accept and return primitive classes, like String and Integer. The classes are saved in the axis tomcat webapp directory with the .jws extension. Axis compiles the java and generates a WSDL.
WSDD
Axis uses Web Service Deployment Descriptors (WSDD) to describe, register and deploy Web Services in the server. While document style can be specified when deploying a Web Service, currently only primitive parameters can be passed.
What this means to enterprise software
It would be possible to use Axis to deploy SOAP Web Services. It would, however, be limited to Tomcat installations and each of the Web Services would have to be registered with a separate generated WSDD. Also, the current version of Axis does not support document literal Web Services, which is required for Microsoft integration.
References
http://ws.apache.org/axis/
Friday, January 23, 2004
Authentication
Authentication
HTTP Authentication is needed to secure web resources, including directories, files and services, including cgi, servlets and web services. The following list of authentication types are the most common and supported by a wide variety of servers and clients.
http://as400bks.rochester.ibm.com/tividd/td/TWS/SC32-1265-00/en_US/HTML/Eqqc1mst72.htm http://web.mit.edu/kerberos/www/ http://support.microsoft.com/?id=264921
HTTP Authentication is needed to secure web resources, including directories, files and services, including cgi, servlets and web services. The following list of authentication types are the most common and supported by a wide variety of servers and clients.
- Anonymous
No challenge to http resources. - Basic
Sends the password in the http header unencrypted. Supported by most servers, clients and browsers. - Digest
Similar to basic, but sends password encrypted so more secure. Supported by Apache with a module and IIS natively. - Forms
A session id based on identity is kept in a Cookie and passed in the http header. Cookies are specific to the browser instance. IIS also provides a framework for implementing this. - Passport
Microsoft's single sign on solution, with a centralized solution. Native support in IIS/Windows 2003, browser support is not limited to IE. - Kerberos
A network authentication protocol, implementation available free from MIT and commercially from many vendors, including Microsoft IIS. While the MS implementation in Windows 2000 does use windows user accounts, it is not specific only to IE. - NTLM
A Windows Integrated authentication similar to Kerberos, but for prior versions of Windows. - Certificates (X.509)
The client maintains a digital certificate. "Digital certificates are, in essence, electronic ID cards that are issued by trusted parties and enable a user to verify both the sender and the recipient of the certificate through the use of public-key cryptography." Both IBM's Tivoli and IIS support certificates. Not all clients and browsers support certificates because a client install is required.
What this means to the enterprise
Since proprietary SSO products are typically based exclusively on a Forms style authentication, it is a strongly encrypted authentication, but we are limited to clients that support it. Also the session is limited a single client session. This means that if you start up another session you will be forced to login again. I believe that we should continue to support basic authentication in 8.1 and moving forward we should support the emerging standards, such as X.509 and Kerberos.
References
Friday, January 9, 2004
Microsoft SharePoint
Windows SharePoint Services
WSS is a server portal component included in Windows Server 2003 for creating a workgroup collaboration site. It includes document upload, indexing and searching. It also includes Alerts, which are triggered when a document or document area has been changed.
Why develop on WSS?
Web Parts. Microsoft put a modular user interface into every SharePoint site, and it uses the full power of ASP.NET and Visual Studio .NET. Web Parts are created from within Visual Studio and have strong integration with Web Services. Sites as Programmable Objects. SharePoint sites, their contents, and the servers that deliver them are accessible, manipulable, and extensible via a managed code API and set of Web Services. You can even package them up as Templates to deploy reusable solutions. An accessible, extensible content store for documents and other data. You can reach the contents of a SharePoint site via Web Services, WebDAV, or the Windows XP Web Client service. Office applications read/write from/to SharePoint sites.
SharePoint Portal Server 2003
SPS is an enterprise portal server which can tie together individual SharePoint sites. This is a separate product.
Why develop on SPS?
It's based on Windows SharePoint Services. If it works in a SharePoint site, it'll probably work in a MySite, an area or a portal home page. Extensible services for indexing and search, people and personalization, and content aggregation/organization. Enterprise Application Integration features, particularly in the areas of Single Sign-On and BizTalk Server interoperability.
InfoPath Integration
InfoPath, which is a new Web Services forms product in Office 2003, is tightly integrated with SharePoint . It allows for saving forms to and launching forms from a SharePoint forms library. Also, forms data, with repeating complex elements, that is saved to a SharePoint library can be automatically aggregated into a single form inquire. For instance, travel expenses from a department can be merged into a single InfoPath form.
What this means to the enterprise
SharePoint integration is one of the most frequently requested feature from enterprise clients. I believe these are larger clients that have software from other vendors in addition to enterprise applications. One thought is that the enterprise portal could run in a SharePoint instance. Or perhaps integration could be reached using specific WebParts created for forms and drill, calling enterprise Web Services. While this would be a specific platform implementation, it could be a strong product offering for the enterprise.
References
http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28001891
WSS is a server portal component included in Windows Server 2003 for creating a workgroup collaboration site. It includes document upload, indexing and searching. It also includes Alerts, which are triggered when a document or document area has been changed.
Why develop on WSS?
Web Parts. Microsoft put a modular user interface into every SharePoint site, and it uses the full power of ASP.NET and Visual Studio .NET. Web Parts are created from within Visual Studio and have strong integration with Web Services. Sites as Programmable Objects. SharePoint sites, their contents, and the servers that deliver them are accessible, manipulable, and extensible via a managed code API and set of Web Services. You can even package them up as Templates to deploy reusable solutions. An accessible, extensible content store for documents and other data. You can reach the contents of a SharePoint site via Web Services, WebDAV, or the Windows XP Web Client service. Office applications read/write from/to SharePoint sites.
SharePoint Portal Server 2003
SPS is an enterprise portal server which can tie together individual SharePoint sites. This is a separate product.
Why develop on SPS?
It's based on Windows SharePoint Services. If it works in a SharePoint site, it'll probably work in a MySite, an area or a portal home page. Extensible services for indexing and search, people and personalization, and content aggregation/organization. Enterprise Application Integration features, particularly in the areas of Single Sign-On and BizTalk Server interoperability.
InfoPath Integration
InfoPath, which is a new Web Services forms product in Office 2003, is tightly integrated with SharePoint . It allows for saving forms to and launching forms from a SharePoint forms library. Also, forms data, with repeating complex elements, that is saved to a SharePoint library can be automatically aggregated into a single form inquire. For instance, travel expenses from a department can be merged into a single InfoPath form.
What this means to the enterprise
SharePoint integration is one of the most frequently requested feature from enterprise clients. I believe these are larger clients that have software from other vendors in addition to enterprise applications. One thought is that the enterprise portal could run in a SharePoint instance. Or perhaps integration could be reached using specific WebParts created for forms and drill, calling enterprise Web Services. While this would be a specific platform implementation, it could be a strong product offering for the enterprise.
References
Friday, December 19, 2003
WSDL
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
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
SQL XML
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
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 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.
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
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.
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)
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="
<statenum>41</statenum>
</m:getStateName>
</SOAP:Body>
</SOAP:Envelope>
http://schemas.xmlsoap.org/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)
Subscribe to:
Posts (Atom)
