® How to Implement a Web Service with SAS — A Business Scenario Making the Most Out of Data Assets Using Web Services A SAS White Paper Table of Contents Introduction ....................................................................................................................1 Web Services with SAS – the Architecture..................................................................1 A Simple Business Scenario.........................................................................................3 The SAS Code.................................................................................................................4 Using the .NET Architecture .........................................................................................5 Implementing the Web Service.....................................................................................5 Calling the Web Service ...............................................................................................8 Using the J2EE Framework ...........................................................................................8 Implementing the Web Service.....................................................................................9 Calling the Web Service .............................................................................................13 Conclusion ....................................................................................................................15 Appendix A – The Basic Web Services Model ..........................................................16 Appendix B – Calling the Web Service Using ASP.NET...........................................18 ® Content providers for How to Implement a Web Service with SAS are Anton Fuchs, Daniel Jahn, Tony Dean and Bryan Allen. How to Implement a Web Service with SAS – A Business Scenario Introduction Messages from today’s press, analysts and vendors talk of Web services as a technology for implementing transactional applications such as inventory ordering or receiving stock prices via the Internet. No doubt, Web services have a great potential in this area. Nevertheless, there is another key business benefit – the delivery of analytical services and business intelligence functionality via the Web and other distributed computing environments. Web services are perfectly suited for delivering business intelligence and analytical services across the enterprise, as well as to users outside of the enterprise such as customers, suppliers or partners. Today, reaching users outside an enterprise is achieved mostly via extranets, which have proven effective in a number of business scenarios. Web services offer the potential to take Web-based business intelligence to the next evolutionary level by providing extranets with secure, standardized interfaces, technological elegance, easy integration and economical repeatability thus speeding the development and deployment of applications, reducing time to market and decreasing overall business costs. Today, SAS customers can develop Web services utilizing SAS technologies with existing .NET and Java infrastructures. Over time, as technology and standards mature, higher-level tools will be built into the SAS infrastructure. This paper provides a technical overview on how Web services fit into the SAS Intelligence Architecture and shows how to develop applications that make use of the Web services framework. It gives in-depth code examples on how to implement a simple, real world scenario. Web Services with SAS – the Architecture The basic Web services model defines three roles (service consumer, service provider and service registry) and three operations between them (publish, find and bind). “Appendix A: The Basic Web Services Model” explains those roles and how they work together in further detail. Related standards that are built on top of this model are Simple Object Access Protocol (SOAP) for defining the transport mechanism, Web Service Description Language (WSDL) for describing the service and Universal Description Discovery and Integration (UDDI), which provides a central location to register and discover services. SOAP and WSDL are widely accepted by the industry while UDDI is currently being reworked to address existing problems. One of those problems is that it defines only central public UDDI registries made available over the Internet. In many business scenarios, Web services should not be publicly available on the Internet but available only inside of the company or to permanent business partners. An example is a Web service that provides a credit limit for a given customer where contractual relationships and operational security are reasons not to use public registries. UDDI Version 3 will solve the problems by enabling companies to have 1 How to Implement a Web Service with SAS – A Business Scenario their own registry as part of an overall topology. For more information, please check http://uddi.org/pubs/uddi_v3.htm. Alternatives to public UDDI registries include using private registries made available by companies like IBM or Sun Microsystems, sending the Web service description via e-mail to related parties, or using WSIL -- a specification proposed by Microsoft and IBM. SAS customers today can develop Web services using SAS technologies with existing .NET and Java infrastructures. Figure 1 shows the architecture. Figure 1 Accessing SAS via a Web service In this model, any client that can send and receive SOAP messages can access a Web service. Figure 1 shows three Web service scenarios: 1. A full desktop application installed and running on a user’s local desktop. 2. A Web application accessed via a Web browser. (Examples of this might be ASP using Microsoft technology, J2EE using a Java framework or any other Web application that can send and receive SOAP requests over the wire.) 3. A Web service calling another Web service to fulfill a request. An example of this would be a Web service that checks to see if a credit card number is valid for paying an order by using the Web service of a credit card company. The Web service itself is implemented in using either Microsoft’s .NET technology or a Java framework containing the appropriate XML APIs that are necessary to build Web services. There are three different ways to expose SAS data and functionality via a Web service: 1. 2 Data that the Web service might need can be exposed using SAS/SHARE server. In this case, you request data from SAS that can be used to satisfy the Web service request. How to Implement a Web Service with SAS – A Business Scenario 2. If your request is running against a huge amount of data you can also use the SAS Scalable Performance Data Server. The SAS Scalable Performance Data Server is optimized to quickly deliver information extracted from large data stores while maintaining consistent performance. You can access the SAS data servers via ODBC or JDBC. SAS provides drivers for both access methods. 3. SAS Integration Technologies is another way to take advantage of SAS functionality and data services. Integration Technologies delivers the SAS Integrated Object Model (IOM) that allows stored processes to execute on the SAS server. Through execution of the stored processes, results are delivered back to the client via a result set. There are multiple ways to communicate with a SAS server via IOM depending on which technology platform and server platform you run. If the Web service runs in a .Net environment you can use COM, DCOM or the IOM bridge for COM (if the SAS server sits on UNIX). If the Web service runs in a Java 2 environment you can use the IOM bridge for Java. For more information using IOM you can download the white paper, SAS Integration Technologies – A Roadmap. A Simple Business Scenario The following business scenario is conceptual in nature as we don’t want to go into complex coding just yet. Suppose a customer asks a sales representative for a 1 million US$ credit. The sales representative doesn’t know the creditworthiness of the customer. He has to find out what the customer’s credit limit is. To solve this problem, the company that the sales representative works for has implemented a Web interface that can be used via the company intranet. Using simple HTML, the intranet application is accessible from a laptop as well as from a handheld device that is capable of displaying HTML. The application consists of two user interfaces: 1. A display to enter the customer name and customer identification number (Figure 2). 2. A display that shows the credit limit of the customer (Figure 3). Figure 2 Input screen Figure 3 Result screen 3 How to Implement a Web Service with SAS – A Business Scenario This Web service passes two parameters (the customer name and customer ID) to the SAS credit scoring server. A SAS stored process containing SAS code is called with those two parameters. The SAS stored process looks up the appropriate customer information with SAS data services. Those parameters are passed to a SAS credit scoring model. The model is scored using the customer parameters and the results are sent back to the calling application. The SAS Code The first step in creating your Web service is to create the SAS code that is called behind the scenes to fulfill the request. The SAS code presented in Figure 4 could be generated from the SAS Credit Scoring for Financial Services solution but has been simplified to always return a specific limit for a specific customer ID. Both the .NET Web service and the Java Web service can call this code, as we’ll see in the next sections. In the scenario, the SAS code exists in c:\SASRepository\GetCreditLimit.sas. Take note of the *ProcessBody; at the beginning of the SAS code. This is where the StoredProcessService inserts macro variables with the values specified in the Web service code. When SAS actually runs this code, it replaces *ProcessBody; with these three macro definitions (because the call to StoredProcessService.Execute has three parameters). %LET custid=1234567; %LET custname=MyCompany Inc.; %LET outdata=work.out; The Web service code will take care of extracting the result from the outdata (work.out) data set. *ProcessBody; data &outdata; if &custid = 8675309 then do; creditLimit = output; end; else if &custid = 1234567 do; creditLimit = output; end; else do; creditLimit = output; end; run; Figure 4 SAS code used by the Web service 4 2000000; then 1000000; 5000; How to Implement a Web Service with SAS – A Business Scenario Using the .NET Architecture Microsoft premiered the .NET framework in February 2002. One of the features of the .NET framework provides the ability to easily create a Web service. Another feature of the .NET framework is the ability to easily and naturally call COM components. By combining these two features, it is a simple matter to create a Web service that calls SAS. Implementing the Web Service This code is written in VB.Net but you might use any language that uses the .NET framework, such as C#. The source file (see Figure 5) to be placed in a Virtual Directory on IIS (Version 5 and up) with an .asmx file extension such as CreditService.asmx. Afterwards, the GetCreditLimit Web service can be tested from a Web browser using the URL http://machine/VirtualDirectory/CreditService.asmx. The steps the Web service goes through are: 1. Verify and validate inputs; initialize. 2. Make an IOM connection to SAS. 3. Invoke the Stored Process in SAS (GetCreditLimit), passing in the parameters custid, custname and outdata. 4. Pull the result from SAS back to the Web Service through the OLE/DB data interface. <%@ WebService Language="VB" Class="CreditService" %> Imports Imports Imports Imports System System.Web.Services System.Data System.Threading <WebService (Name := "Credit Limit Service", _ Description := "Provides information on a customers credit limit.")> _ Public Class CreditService Inherits System.Web.Services.WebService Private m_obSAS As SAS.Workspace Private WithEvents obSASEvents As SAS.LanguageService Private m_ErrorCount As Integer Private m_EventComplete As ManualResetEvent = New ManualResetEvent(False) <WebMethod(Description:="Returns a credit limit for the requested Customer ID and Name.")> _ 5 How to Implement a Web Service with SAS – A Business Scenario Public Function GetCreditLimit(ByVal custName As String, ByVal custID As String) As Double ' Some initialization goes here and validate inputs GetCreditLimit = 0 ' Get a SAS workspace Dim obWorkspaceManager As New SASWorkspaceManager.WorkspaceManager() Dim xmlInfo As String ' Make a connection to SAS running on the same machine as the web ' service. We could change this code to make a connection to a SAS server ' running on any OS supported by SAS like Windows, OS/390 machine or Unix. m_obSAS = obWorkspaceManager.Workspaces.CreateWorkspaceByServer("", _ SASWorkspaceManager.Visibility.VisibilityProcess, Nothing, "", "", xmlInfo) ' Tell SAS where to find the SAS source code. m_obSAS.LanguageService.StoredProcessService.Repository = "file:c:\SASRepository" ' Parameters to a StoredProcess are name=value space-separated pairs Dim params As String params = "custid=" & custID & " custname=" & custName & " outdata=work.out" ' Run the SAS StoredProcess passing in the parameter string ' The result will be stored in a table called work.out. ' The SAS StoredProcess is saved in c:\SASRepository\GetCreditLimit.sas. Try m_obSAS.LanguageService.StoredProcessService.Execute("GetCreditLi mit", params) Catch e As Exception obWorkspaceManager.Workspaces.RemoveWorkspace(m_obSAS) Throw e End Try ' We're using events to detect errors in the submitted SAS code. So, we'll ' wait here until the SAS code has finished running, and see if we did get ' any errors. m_EventComplete.WaitOne(20000, True) If (m_ErrorCount > 0) Then ' Web service exceptions can be caught by the caller m_ErrorCount = 0 Throw New SystemException("The submit has failed or we have exceeded the timeout: GetCreditLimit") 6 How to Implement a Web Service with SAS – A Business Scenario End If 'Get value using ADO.NET Dim obConn As System.Data.OleDb.OleDbConnection Dim obCmd As System.Data.OleDb.OleDbCommand Dim obRdr As System.Data.OleDb.OleDbDataReader Try ' These are standard ADO calls…make a connection, execute an SQL command, ' read the result, close the connection. obConn = New System.Data.OleDb.OleDbConnection("provider=sas.iomprovider.1; SAS Workspace ID=" & m_obSAS.UniqueIdentifier) obCmd = New System.Data.OleDb.OleDbCommand("select * from work.out", obConn) obConn.Open() obRdr = obCmd.ExecuteReader() ' Check whether the ADO calls did work, ' return the result to the client. ' and close the connection to the SAS server. obRdr.Read() Dim result As Double If (obRdr.IsDBNull(0)) Then Throw New System.Exception("There was an error getting the customers credit limit from SAS.") Else result = obRdr.Item(0) End If GetCreditLimit = result Catch e As Exception Throw e Finally If Not (obRdr.IsClosed()) Then obRdr.Close() End If If Not (obConn.State = ConnectionState.Closed) Then obConn.Close() End If obWorkspaceManager.Workspaces.RemoveWorkspace(m_obSAS) End Try End Function End Class Figure 5 Web service implemented using VB.NET 7 How to Implement a Web Service with SAS – A Business Scenario Calling the Web Service Now that we’ve implemented and deployed the Web service, we can use it from any client that supports the SOAP protocol. The code shown in Figure 6 can be implemented in any .NET application including a Web application, a code library or another Web service. In the case of our credit limit application, we decided to implement the code in ASP.NET as a Web application. It creates the necessary HTML that is sent to the Web browser, performs some checks, calls the Web service and returns the result to the Web browser. The complete ASP.NET client code is attached in Appendix B. Note, that this client code uses C#; while the Web service code (Figure 5) uses VB.NET. You can use any .NET-supported language for either the client code or the Web service code. At design time, we use the .NET Framework SDK’s WSDL.EXE tool to generate a client proxy. In this case, WSDL.EXE created the CreditLimitService class, which is used in Figure 6 to call the Web service for us. try { //Create a new instance of our Web Service CreditLimitService svc = new CreditLimitService(); Double creditLimit = 0; creditLimit = svc.GetCreditLimit(custName.Text, custID.Text); Label1.Text = custName.Text + "'s credit limit is " + creditLimit + "."; } catch (Exception ex) { //Handle errors and display them Label1.Text = "An exception was thrown attempting to get the customer credit limit. Error: " + ex.Message; } Figure 6 Sample C# code fragment to call the Web service Using the J2EE Framework There are several choices for implementing a Web service in Java. The two main options are JAXM and JAX-RPC. Java API for XML Messaging (JAXM) enables developers to send and receive XML messages based on the Simple Object Access Protocol (SOAP) 1.1 with attachments specification and profiles for ebXML and SOAP-RP. Java API for XML-based RPC (JAX-RPC) enables Java technology developers to build Web applications and Web services incorporating XML-based remote procedure call (RPC) functionality according to the Simple Object Access Protocol (SOAP) 1.1 specification. By using JAX-RPC, Java developers can rapidly achieve Web services interoperability based on widely adopted standards and protocols. 8 How to Implement a Web Service with SAS – A Business Scenario You can get these by downloading Sun Microsystems’s Java Web Services Developer Pack (JWSDP), which contains the Java XML Pack. For our purposes we’re using the JAX-RPC approach. Although not as flexible as JAXM, it hides many of the details and therefore makes it very easy to implement a Web service. The following examples are created using the JWSDK from Sun that you can download from http://java.sun.com/webservices/webservicespack.html. There are other Web service or XML development frameworks that you could use instead, such as the Apache AXIS framework (see http://xml.apache.org/axis/index.html) or IBM’s Web Services Tool Kit (WSTK). Implementing the Web Service There are several steps that you must follow to create a Web service. 1. Create a Java interface that describes the Web service. 2. Create the actual Web service implementation code. 3. Compile the code and create an “intermediate” war file. 4. Generate Ties and WSDL and repackage the war file. 5. Deploy the Web service. The following examples make use of the ant make utility and its targets that come with the JWSDP. For more information we highly recommend to read the XML-RPC chapters of the Java Web Services Tutorial, which you can download from http://java.sun.com/webservices/docs/1.0/tutorial/index.html. Here are the details on each step. Step 1: Create a Java interface that describes the Web service. The Java interface that describes the CreditService Web service has to extend the java.rmi.Remote interface and must throw the java.rmi.RemoteException exception. Figure 7 shows the Java interface. It defines a method getCreditLimit that takes two parameters (customer name and id) and returns the credit limit. package creditservice; import java.rmi.Remote; import java.rmi.RemoteException; public interface CreditServiceIF extends Remote { public double getCreditLimit(String custName, String custID) throws RemoteException; } Figure 7 Java Interface to describe the CreditService Web service 9 How to Implement a Web Service with SAS – A Business Scenario Step 2: Create the actual Web service implementation code. The actual implementation of the Web service is shown in Figure 8. It implements the above interface. The steps the Web service goes through are: · Verify and validate inputs; initialize. · Create an IOM connection to SAS. · Invoke the Stored Process in SAS (GetCreditLimit), passing in the parameters custid, custname and outdata. · Pull the result from SAS back to the Web service by using SAS IOM driver for JDBC. package creditservice; import import import import java.util.Properties; com.sas.iom.SAS.IWorkspace; com.sas.iom.SAS.IWorkspaceHelper; com.sas.rio.MVAConnection; public class CreditServiceImpl implements CreditServiceIF, java.rmi.Remote { public double getCreditLimit(String custName, custID) throws java.rmi.RemoteException { /* Here’s the place to put some validation code */ double _retVal = 0; /* Define a connection to a SAS IOM server via a iWorkspace object */ try { WorkspaceFactory wsf = new WorkspaceFactory(); Properties serverInfo = new Properties(); serverInfo.put("host", "anyserver.com"); serverInfo.put("port", "9999"); IWorkspace iWorkspace = wsf.createWorkspaceByServer(serverInfo); /* Use the StoredProcessService to execute the SAS code */ ILanguageService iLang = iWorkspace.LanguageService(); IStoredProcessService iSP = iLang.StoredProcessService(); iSP.Repository("file: c:\\SASRepository"); iSP.Execute("GetCreditLimit", "outdata=work.out" + "custname=" + custName + " custid=" + custID); /* Read the result via an MVAConnection */ IDataService iDataService = iWorkspace.DataService(); java.sql.Connection connection = new MVAConnection(iDataService, new Properties()); java.sql.Statement statement = 10 How to Implement a Web Service with SAS – A Business Scenario connection.createStatement(); java.sql.ResultSet rs = statement.executeQuery( "Select * from work.out"); /* Get the credit limit and return it to the calling client */ if( rs.next() ) { String creditLimit = rs.getString("creditLimit"); _retVal = Double.parseDouble(creditLimit); } } catch( Throwable t ) { t.printStackTrace(); java.rmi.RemoteException ex = new java.rmi.RemoteException("Error getting credit limit”, t); } finally { try{ /* Close JDBC connection if open */ if(connection != null) { if(!connection.isClosed()) connection.close(); } /* Close iWorkspace */ if(iWorkspace != null) iWorkspace.Close(); /* Shutdown WorkspaceFactory */ if(wsf != null) wsf.shutdown(); } catch(Throwable t) { //t.printStackTrace(); } } return _retVal; } } Figure 8 Implementation of the Web service 11 How to Implement a Web Service with SAS – A Business Scenario Step 3: Compile the code and create an “intermediate” war file. The next step of creating an “intermediate” war file is very easy if you use the ant targets that come with the JWSDP. To create the war file you need two configuration files jaxrpc-ri.xml (Figure 9) and web.xml (Figure 10). For further information, please check the Java Web services tutorial. <?xml version="1.0" encoding="UTF-8"?> <webServices xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd" version="1.0" targetNamespaceBase="http://tempuri.org/" typeNamespaceBase="http://tempuri.org/" urlPatternBase="/ws"> <endpoint name="CreditService" displayName="Credit Service" description="A service returning a credit limit for a certain customer" interface="creditservice.CreditServiceIF" implementation="creditservice.CreditServiceImpl"/> <endpointMapping endpointName="CreditService" urlPattern="/creditservice"/> </webServices> Figure 9 jaxrpc-ri.xml - Deployment descriptor for the Web application <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd"> <web-app> <display-name>CreditService Application</display-name> <description>A web application getting the credit limit for a customer</description> <session-config> <session-timeout>60</session-timeout> </session-config> </web-app> Figure 10 web.xml – Implementation specific descriptor 12 How to Implement a Web Service with SAS – A Business Scenario You must execute the following three ant targets: · ant compile-server which compiles the Java file in Figure 8. · ant setup-web-inf creates a Web application structure. · ant package creates the “intermediate” war file. This war file is not ready for deployment because it does not contain needed Java classes and the WSDL file. Step 4: Generate Ties and WSDL and repackage the war file. This step generates the necessary server-side Java (Tie) classes that you need to do a Web service call, the WSDL file and changes the web.xml file according to the JAX-RPC standard. After doing so, it repackages the war file. You can automate this process by using ant target process-war: ant process-war Process-war extracts and reads the jaxrpc-ri.xml file from the intermediate war file to get information on how to generate the Tie classes and the WSDL file. Jaxrpc-ri.xml is implementation-specific to JWSDP and is not part of the JAX-RPC specification. Step 5: Deploy the Web service. Again you can easily deploy the Web service by using an ant target: ant deploy Depending on the Web application server that you’re using, you could use the deploy tools that come with it. In the case of tomcat, you can just take the war file created in Step 4 and copy it to $TOMCAT_HOME\webapps. Now we’re ready to test the accessibility of the Web service by using a URL similar to http://localhost:8080/creditservice-jaxrpc/creditservice If the call was successful then the browser should display a page titled Web Services, which lists the port name CreditService with a status of ACTIVE. This page also contains a URL to the service's WSDL file. Calling the Web Service Now that we’ve implemented and deployed the Web service, we can use it from any client that supports the SOAP protocol such as the one that we created in the section Using the .NET Architecture. In this section we’ll create a simple Java application that uses the CreditLimit Web service. The following steps are necessary to create the client: Step 1: Generate the Stubs. These are proxy classes that can be used on a client to call the Web service. The ant target generate-stubs automatically creates them: ant generate-stubs 13 How to Implement a Web Service with SAS – A Business Scenario Step 2: Code the Java client application. Figure 11 shows some sample Java code that calls the CreditLimit Web service and writes the result into the console window. package creditservice; import javax.xml.rpc.Stub; public class CreditServiceClient { public static void main(String[] args) { double limit; try { Stub stub = createProxy(); CreditServiceIF cservice = (CreditServiceIF)stub; System.out.println("Calling the service"); limit = cservice.getCreditLimit("MyCompany", "8675309"); System.out.println("The credit limit is " + limit); } catch (Exception ex) { ex.printStackTrace(); } } private static Stub createProxy() { // Note: CreditService_Impl is implementation-specific. return (Stub)(new CreditService_Impl().getCreditServiceIFPort()); } } Figure 11 Java client application to call the CreditLimit Web service Step 3: Compile the client code and package a jar file with all necessary class files. Again, you can use the JWSDP environment with the ant tool to do this: · ant compile-client compiles the Java client code. · ant jar-client generates the jar file that contains all necessary classes. You can test the client code and Web service either by using ant target run or by calling the client class directly: 14 · ant run · java creditservice.CreditServiceClient -classpath creditservice-client.jar How to Implement a Web Service with SAS – A Business Scenario Conclusion Doing business in the future will require technologies that allow an enterprise to adjust in many different ways. There’s an increasing need for a more flexible, open and integrated architecture to successfully deploy business applications. A service-oriented architecture, such as Web services, can help to meet that demand. SAS’ strategy has always been to enhance the value of a customer’s investment in SAS, regardless of which technology exploitation tools are used. Web services are no different. SAS software already supports the Web services model today utilizing SAS technologies with existing .NET and Java infrastructures. SAS is the only software vendor that provides organizations with the ability to develop and implement intelligence strategies that span the entire enterprise. Unlike other solution providers who have promised to deliver true intelligence and failed, SAS brings a 26-year history of innovation and leadership in data management and analytics. Furthermore, SAS technology capabilities embed SAS’ experience in delivering business value with the industry-leading investment in research and development so that you continually benefit from historical learning. 15 How to Implement a Web Service with SAS – A Business Scenario Appendix A – The Basic Web Services Model Web services in its most basic form can be defined as routines that call other routines using Internet protocols. Noted by analyst firms as the next technology whirlwind, Web services will speed the development and deployment of applications, thus reducing time to market and costs. There can be tremendous benefits associated with Web services. We have heard of interoperability among disparate systems, the ability to invoke a Web service over ubiquitous network technologies, and so on. But, how does all that work? Take a look at this conceptual Web services model. The model highlights two important elements of any system – roles and operations. By roles, we mean the different types of entities. Operations are the functions performed by these entities in order to make the Web services work. Let’s look at the following diagram to understand the Web Services model. Service Registry Find Service Consumer Publish Bind Service Provider Web Service Description Figure 12 Web services model In this Web services model diagram, we identify the three roles in a typical Web services environment and the operations that they perform in order to make Web services work. The roles shown in the diagram are as follows: · 16 Service provider – A service provider is the entity that creates the Web service. Typically, the service provider exposes certain business functionality in their organization as a Web service for other organizations to invoke. An example could be an online bookseller who wishes to expose its online ordering service as a Web service. The service provider needs to do two things to reach the full potential of a Web service. First, it needs to describe the Web service in a standard format, which is understandable by all organizations that will be using that Web service. Secondly, to reach a wider audience, the service provider needs to publish the details about its Web service in a central registry that is publicly available to everyone. How to Implement a Web Service with SAS – A Business Scenario · Service consumer – Any organization using the Web service created by a service provider is called a service consumer. The service consumer can know the functionality of a Web service from the description made available by the service provider. To retrieve these details, the service consumer does a find in the registry to which the service provider had published its Web service description. More importantly, the service consumer is able to get from the service description, the mechanism to bind to the service provider’s Web service and in turn to invoke that Web service. · Service registry – A service registry is a central location where the service provider can list its Web services, and where service consumers can search for Web services. Service providers normally publish their Web service capabilities in the service registry for service consumers to find and then bind to their Web service. Typically, information such as company details, the Web service that it provides, and the details about each Web service including technical details is stored in the service registry. In our Web services model, we can also identify three operations that are fundamental to making Web service work – ‘find’, ‘bind’ and ‘publish’. We need to achieve inter-application communication regardless of the language the application is written in, the platform the application is running on and so forth. To make this happen, we need the standards for each of these three operations and a standard way for a service provider to describe their Web service regardless of the language it is written in: · A standard way to describe Web services. The Web Services Description Language (WSDL) is a standard that uses XML format to describe Web services. Basically, the WSDL document for a Web service would define the methods that are present in the Web service, the input/output parameters for each of the methods, the data types, the transport protocol used and the end point URL at which the Web service will be hosted. · A standard protocol to publish and find Web services. The Universal Description, Discovery and Integration (UDDI) standard provides a way for service providers to publish details about their organization and the Web services that they provide to a central registry. This is the ‘description’ part in UDDI. It also provides a standard for service consumers to find service providers and details about Web services. This is the ‘discovery’ part in UDDI. · A standard protocol for applications to bind to Web services. The Simple Object Access Protocol (SOAP) is a lightweight XML mechanism used to exchange information between applications regardless of the operating system, programming language or object model. Web services are still very much in the ‘emerging technology’ space. The standard bodies accommodate early experiences that exposed deficiencies in the specifications and new requirements. As well, there are still no adopted standards for various aspects of security, which limits the complexity and scope of current implementations. 17 How to Implement a Web Service with SAS – A Business Scenario Appendix B – Calling the Web Service Using ASP.NET <%@ Page language="c#" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > <script runat="server" language="c#"> //Fired by the Button1 Click event private void Button1_Click(object sender, System.EventArgs e) { try { //Create a new instance of our Web Service CreditLimitService svc = new CreditLimitService(); Double creditLimit = 0; creditLimit = svc.GetCreditLimit(custName.Text, custID.Text); Label1.Text = custName.Text + "'s credit limit is " + creditLimit + "."; } catch (Exception ex) { //Handle errors and display them Label1.Text = "An exception was thrown when attempting to get the customer credit limit. Error: " + ex.Message; } } </script> <HTML> <HEAD></HEAD> <BODY> <form id="Form1" method="post" runat="server"> <table> <tr> <td colspan=2><h3>Get Customer's Credit Limit</h3></td> <tr> <td align="right">Customer name: </td> <td> <asp:TextBox id="custName" runat="server"></asp:TextBox> <asp:RequiredFieldValidator ControlToValidate="custName" ErrorMessage=" *** Required Field ***" Display="static" RunAt="server" /> </td> </tr> 18 How to Implement a Web Service with SAS – A Business Scenario <tr> <td align="right">Customer id: </td> <td> <asp:TextBox id="custID" runat="server"></asp:TextBox> <asp:RegularExpressionValidator ControlToValidate="custID" ValidationExpression="^\d+$" ErrorMessage=" *** Invalid Customer ID ***" Display="static" RunAt="server" /> <asp:RequiredFieldValidator ControlToValidate="custID" ErrorMessage=" *** Required Field ***" Display="static" RunAt="server" /> </td> <tr> <td colspan=2 align="left"> <br><asp:button id="Button1" runat="server" onclick="Button1_Click" Text="Get Credit Limit" ></asp:button> </td> </tr> </table> <p><asp:label id="Label1" runat="server" Height="88px" Width="800px"></asp:label></p> </form> </BODY> </HTML> 19 World Headquarters and SAS Americas SAS Campus Drive Cary, NC 27513 USA Tel: (919) 677 8000 Fax: (919) 677 4444 U.S. & Canada sales: (800) 727 0025 SAS International PO Box 10 53 40 Neuenheimer Landstr. 28-30 D-69043 Heidelberg, Germany Tel: (49) 6221 4160 Fax: (49) 6221 474850 www.sas.com SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product names are trademarks of their respective companies. Copyright © 2002, SAS Institute Inc. All rights reserved. 100486EU_213476.1102
© Copyright 2024