A SAS White Paper —

Transcription

A SAS White Paper —

®
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
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.
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
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;
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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.
·
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
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
<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

A SAS White Paper —

Transcription

Similar documents

XJ1100 SAS_PUB-00031-G_Front

Winter Holiday Book

SAS Data Warehouse for Risk analysis in Vilniaus Bankas AB

Tricell System 810 - SAS International

We repurposed the path analysis feature in SAS Visual Analytics to

I~IeMSA

Cokins, Gary. Performance Management: Integrating Strategy

Both WAVAW and SAS will support whatever decisions you make.

InterMail has a strong standing within digital and mail

SUN Microsystems – ciągłość biznesowa dla Banków Spółdzielczych