A web service
is an interface that enables communication between distributed applications.
Web services enable cross-platform integration by enabling applications
that are written in various programming languages to communicate by
using a standard web-based protocol. This functionality makes it possible
for businesses to bridge the gaps between different applications and
systems.
The following figure
shows how web services work.
In general, SAS BI Web
Services expose SAS Stored Processes for execution by using web service
protocols. Remote clients are then able to specify input parameters,
drive execution of SAS code, and obtain results from that execution.
Also, web services make it possible to write clients that perform
this act in a myriad of languages and on a variety of operating systems
by using HTTP to exchange messages. Web services can enable a service-oriented,
enterprise application approach, or they can support the development
of mobile or web clients, all of which leverage reusable SAS Stored
Processes.
There are two core types
of SAS BI Web Services: XMLA and structured web services. Structured
web services can further be divided based on how you access the services
and the format of the messages that you send and receive.
SAS BI Web Services
expose a single XMLA web service endpoint with two operations: Discover
and Execute. Clients call Discover in order to obtain information
from the system, including the list of SAS Stored Processes that are
available for execution by the XMLA engine, the inputs and outputs
of those stored processes, and other metadata about the stored processes.
Clients can then use the Execute operation to specify input, execute
a stored process, and obtain the results of that execution. The XMLA
web service is more limited than structured web services because it
provides only a general interface for invoking stored processes. For
example, XMLA includes a Web Services Description Language (WSDL) file,
but because XMLA can be used to execute any number of stored processes,
this WSDL does not actually describe the stored process inputs and
outputs. Instead, the WSDL describes the information that the Discover
calls return to the client. This makes XMLA web services unsuited
for use with client web service libraries where automatic proxy generation
and easy service execution are desired. Also, XMLA only supports XML
and the SOAP protocol for all operations and does not support many
features of SAS Stored Processes.
Starting in SAS 9.3,
all stored processes are available individually for execution using
web services without any action required from the user. SAS BI Web
Services automatically exposes a WSDL file for each and every stored
process that is available in the system. These WSDL files use XML
to include detailed information about the inputs and outputs of each
stored process using XML schema descriptions. Also, the WSDL file
includes the URLs of endpoints to use to invoke these stored processes
by using SOAP over HTTP. You can use these WSDL files to automatically
generate code in your client framework of choice that can be used
to invoke the web services. SAS BI Web Services exposes these services
using a simple mapping from the metadata folder path of the stored
process.
You can group multiple
stored processes together in a single, named web service using the Deploy
As Web Service wizard in SAS Management Console. In 9.2,
these were called generated web services because the wizard generated
a grouping (and because server artifacts were actually generated as
well). You can group stored processes for web service execution to
simplify management or to enable generated client code to invoke more
than one stored process. The grouping generates a single WSDL file
that describes all stored processes together in one document and all
stored processes in a generated web service grouping are invoked at
the same, unique endpoint based on the name of the generated service.
Stored processes that are a member of a generated web service are
still individually available for execution.
All structured web services
can be invoked by using SOAP over HTTP. SOAP strictly defines message
structure, including the envelope containing headers and body. SAS
BI Web Services define the content (and namespace) of the payload
within the body. In addition, starting in SAS 9.3, SAS BI Web Services
support Javascript Simple Object Notation (JSON) and plain XML as
message formats for all structured web services. The format of input
XML messages for a structured web service can be deduced from its
WSDL file. The addition of new output resource URL suffixes in conjunction
with the new SAS folder path mapping means that SAS BI Web Services
now support Representational State (REST) style web service invocation.
SAS BI Web Services
for Java are administered using SAS Web Application Server. If you
install SAS BI Web Services for Java, then you also need to have a
Java Virtual Machine for an application server. For more information
about administering and configuring web services, see the SAS Intelligence Platform: Web Application Administration Guide.