Web Services Framework (WSF) API abstracts the details of connecting to and communicating with a Web service. It also provides helper classes for sending requests and handling the responses of Web services.
The use of this API is not restricted to some certain type of client applications (which are called Web service consumers). It can be used by end user applications or even by system applications. One thing to keep in mind is that the operation starting from the establishment of a connection and ending with the actual receiving of the response is usually time consuming. This API provides a way to perform the whole operation behind the scenes (asynchronously) so that the Web service consumer application’s execution is not blocked while the call and response are being handled by WSF.
Service-Oriented Architecture (SOA) is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve the desired end results for a service consumer.
A Web service is a SOA where the interfaces must be based on Internet protocols such as HTTP, FTP, and SMTP. Also, except for binary data attachments, messages must be in XML.
The focus in WSF is on Web services where the messages passed between the consumer and provider are SOAP messages.
There are generally two entities involved in service transactions: a service consumer and a service provider. The service-oriented world consists of networks of these entities.
A service consumer is a software application that uses one or more service providers to provide some value to the user of the service consumer application. For example, a travel agent consumer could access a car rental service provider and an airline reservation service provider, and combine the results in some way that makes it easier for the service consumer’s users to book their travels.
Service-Oriented Architecture is not limited to certain types of devices. Any networked device that could run a piece of software might act as a service provider and expose a service interface - even, for example, a refrigerator.
Services offer methods for extracting or modifying data that may change the state of resources associated with the service, or the state of the resources held by the service consumer. Any software application that provides such an interface can be called a service.
A service that exposes such an interface using SOAP messages to wrap service messages is a Web service. Consumers of such services are thus Web service consumers and providers of such services are Web service providers.
The World Wide Web Consortium (W3C) describes a Web service as a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically Web Services Description Language (WSDL)). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
Such software systems have been available on standard computers for quite a while now. Many companies (including, for example, Amazon.com and Google) now provide access to their systems based on Web services.
Of course, there is nothing in the above definition that prevents Web services either from residing on or being accessed from a mobile device. However, there are a few things to consider regarding mobile devices:
Usually with mobile devices, the network connection is not as stable as in PCs. Developers should plan for a scenario where a network service becomes suddenly unavailable: using an asynchronous approach to messaging may help minimize the effect on the user.
The used network is usually more bandwidth-limited than a standard Ethernet network.
Mobile devices have very limited resources. This may cause problems with physically large messages. There may not be enough memory to process the message as a whole.
Service-oriented applications are created as components that send messages to each other. In Web services, the SOAP protocol defines a messaging envelope, which consists of SOAP headers and a SOAP body. XML namespaces are used to prevent problems with colliding element names in the body and the headers. SOAP header blocks are also known as roles (or as actors). An example of a SOAP header is the SOAP security header.
A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. This XML document is referred to as a SOAP message. XML schemas are used to validate SOAP messages. A SOAP message contains the following:
The envelope is the top element of the XML document representing the message.
The header is a generic mechanism for adding features to a SOAP message. SOAP defines a few attributes that can be used to indicate who should deal with a feature and whether it is optional or mandatory.
The body is a container for mandatory information intended for the ultimate recipient of the message. SOAP defines one element for the body, which is the Fault element used for reporting errors.
The grammar rules are as follows:
Envelope
The element name is Envelope.
The element is mandatory.
The element may contain namespace declarations as well as additional attributes. If present, such additional attributes must be namespace-qualified. Similarly, the element may contain additional sub elements. If present, these elements must be namespace-qualified and must follow the SOAP Body element.
Header
The element name is Header.
The element may be present in a SOAP message. If present, the element must be the first immediate child element of a SOAP Envelope element.
The element may contain a set of header entries each being an immediate child element of the SOAP Header element. All immediate child elements of the SOAP Header element must be namespace-qualified.
Body
The element name is Body.
The element is mandatory in a SOAP message and it must be an immediate child element of a SOAP Envelope element. It must directly follow the SOAP Header element (if present).
The element may contain a set of body entries each being an immediate child element of the SOAP Body element. Immediate child elements of the SOAP Body element may be namespace-qualified. SOAP defines the SOAP Fault element, which is used to indicate error messages.
The following is an example of a SOAP message:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<s:GetVersion xmlns:s="someURI">
<Version>1.0</Version>
</s:GetVersion>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
A single SOAP message may be processed a number of times between the actual sender and the receiver. For example, one node in the chain between the sender and the receiver might add some security headers to the SOAP envelope.
A service consumer may use SOAP envelopes to send content to a service. The content is passed in the SOAP body. Control information, such as message security, can be passed using SOAP headers. If the service responds to the client, the response is delivered in the SOAP body. SOAP envelope is an XML document, so the content of the envelope can be used by parsing the envelope with an XML parser.
The SOAPAction HTTP request header field can be used (in SOAP version 1.1) to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. An HTTP client must use this header field when issuing a SOAP HTTP request. The header field value of an empty string ("") means that the intent of the SOAP message is provided by the HTTP Request-URI. No value means that there is no indication of the intent of the message.
In WSF, the Service Connection library provides classes for working with SOAP messages. SOAP messages may be constructed for sending and the results from the used service may be parsed using the XML Extensions library.
WSF uses the concept of “framework” in order to send messages that are appropriate for a particular service. Currently WSF supports two frameworks:
Basic Web Services Framework, which can be used with common Web services. This framework supports the WS-I Basic Profile.
Liberty Identity Based Web Services Framework (ID-WSF)
There may not be a need for specific framework, for example when the used service is quite straightforward, not requiring authentication or expecting any additional SOAP headers. In these cases, it is appropriate to use Basic Web Services Framework.
Identity is very important in both Web services and the mobile world. Typically, it is necessary for the users of a Web service (the requester) to authenticate themselves in order to gain access to the service. This depends on either the service itself, or on some other entity that the service trusts, being confident that it knows the identity of the service requester.
An Identity Provider (IDP) can be described as a service at which the user has some kind of account (the service can be said to know the user).
Services may, of course, each individually maintain an account for each user of the service. In such situations, the service “self-authenticates” the user.
Services may also, however, rely on some separate identity providing service, which they trust to make assertions regarding the identity of a service-requesting user. That trust is explicitly modeled in WSF by associating identity-providing services with those that trust them to make such assertions.
The use of a separate identity providing service can be recommended for the following reasons:
Separating authentication and account management from services that nonetheless rely on such services allows application service to not have to re-invent authentication and account management on a per-service basis.
Allowing third-party identity providers enables good business practices; it is much easier to work with a new business partner if you have systems that can integrate easily. Separating identity provider functionality from application services facilitates such partnerships if partners use standard interfaces for identity provision (such as the Liberty ID-FF specifications).
Identity services are identified by contracts, or in other words, service type identifiers. A contract is a URI such as “urn:nokia:test:addrbook:2004-09”. A contract maps to an abstract WSDL document of a service. A service instance is the instantiation of a certain contract. There may be several instantiations to a certain service type which each have their own concrete WSDL document. Each service instance is hosted by a service provider identified by a provider identifier. A service instance offers means to access some resources, which may be data or just service functionality. Resources usually have access control policies, which must be enforced by the service instance.
Authentication is only one view of identity. Information resources related to an identity may be exposed through a Web service interface, and so identity may be linked to these exposed resources. Consider a calendar service; a user may have an own calendar service that provides an interface to the user’s personal agenda. Other services may use identity information to provide a better service. For example, a weather forecasting service could provide a local weather forecast for the user if it knows the user’s postal code. The postal code could be obtained from a service that exposed the user’s address profile details.
The Liberty Alliance Identity Web Services Framework (ID-WSF) specifications define a full framework for identity-centric Web services, and WSF supports the usage of this framework for handling identity information. In this framework, identity-providing services are explicitly decoupled from those that either expose a service on behalf of an identity (such as a service that provides an interface to a user’s calendar; the calendar service is exposed on behalf of the user’s identity), provide service based on identity-related information (such as a service that offers content customized based on some piece of identity-related information; e.g. a weather forecasting service that tells the user’s local forecast might need to know the user’s postal code to give the user a more relevant forecast), or have no need for identity at all.
A framework for identity Web services is necessary as there are intrinsic concepts that are required to make such a world possible: with service providers and consumers getting access to information about the identity of other users, privacy is a particular concern, for example. In the Liberty ID-WSF, privacy, security, and other areas are the focus for the specifications. Two of the most useful concepts in Liberty are the opaque name identifier, and the UsageDirective SOAP header.
Discovery service is an identity service, which provides discovery of resource exposures (service instances) associated with a given identity.
A Web service consumer may look up service instances with a certain service type (a contract). The response contains information about the service instances and their policies.
Many services require authentication. One obvious service type that requires authentication is Identity Provider. Usually the Web service consumer receives some credentials during the authentication process and can use these credentials, for example, to access some discovery service.
It is also possible that the authentication provider acts as an Identity Provider. This is the case in Liberty ID-WSF.
A facet is a certain characteristic that describes the used service instance.
Currently, only ID-WSF framework supports facets. For example, if the consumer application is interested in resolving if the initialized service connection has a facet indicating that the service is free of charge (for e.g. " urn:some.service.free:cost "), the method used to check this would be:
_LIT8(KFacetOfFreeService, "urn:some.service.free:cost"); TBool hasFacet; TInt err = iConnection->HasFacet(KFacetOfFreeService, hasFacet);
WSF supports OASIS Web Services Security 1.0 (WS-Security 2004) which allows,
for example, the authentication of a SOAP message via a security token. One
type of security token is UsernameToken, which
is used simply to provide a username and password to authenticate the SOAP
message. Obviously, this is not the most secure authentication method available,
and when sending credentials in clear text like this, Secure Sockets Layer
(SSL) / Transport Layer Security (TLS) should be used to protect the content
of the message. This type of authentication is akin to HTTP basic authentication,
but it is done at the SOAP rather than the HTTP layer. A common approach today
is that security identities have a name, private key and X.509 certificate.
The X.509 certificate contains public characteristics (a.k.a. credentials)
of a particular identity, including the public key.
WSF also supports authentication via HTTP Basic Authentication with a username and password. If the Web service endpoint is protected by HTTP Basic Authentication and the initial request is made, an HTTP 401 error (requesting authentication) is returned to WSF. WSF then supplies the credentials so that the request can be authenticated.
Liberty ID-WSF Security Mechanisms Specification is also supported by the ID-WSF framework.