Anna University, Chennai
MC9251 / MIDDLEWARE TECHNOLOGIES QUESTIONBANK
1. Write some popular web service technologies.
| Product | Support OS | Language |
| Apache SOAP | UNIX, Windows | Java |
| WASP | UNIX, Windows | C++ |
| GLUE | UNIX, Windows | Java |
| SOAP BEA WebLogic | UNIX, Windows | Java |
| MS SOAP Toolkit | Windows | C++, VB, COM |
| .NET Framework | Windows | C#, VB.NET |
| SOAP::Lite | UNIX, Windows | Perl |
| PocketSOAP | WinCE | C++ |
| SOAP for ADA | Linux | Ada |
| Web Service Behavior | Windows | JavaScript, DHTML |
| SOAPx4 | UNIX | PHP |
| Delphi 6 | Windows | Delphi |
| Kafka | Windows | XSLT |
2. Define federation.
Federation is a design methodology for spreading out processes, components, and machines in a way that removes single points of failure. Instead, the pieces of a distributed system are federated out over the entire system. Federation enables you to distribute systems across organizational and trust boundaries, and seldom requires a single administrative server. DNS (domain name system) and Usenet are familiar examples of federated services.
3. What is a namespace?
A unique identifier of resources on the Web. A resource can be a Web page, a SOAP
endpoint, or even a person.
4. Define WS-Routing.
Routing allows point A to send a message to point B, and then point B to forward the message to points C and D because the message contained routing information.
Assuming that the message also contained security controls, this scenario could allow for message passing from within companies to within other companies, traveling through their firewalls. Of course, there are many other applications of routing as well. As well, I fully expect that this specification will evolve over time.
5. Write the major standards in web services development.
SOAP, XML, XML Schema (XSD), HTTP, and WSDL.
PART – B (40 Marks)
6. a) How will you secure web services with WS-Security? . (16)
Security Technologies and Standards
Security is really three different but complementary technologies. Generally speaking, to secure an application can mean
· Authentication— Ensuring that only authorized users can access the application.
· Confidentiality— Keeping secret data secret, unviewed by unauthorized persons.
· Integrity— Verifying the integrity of data, that it hasn't been changed.
Security Token
A security token in the most basic sense is a piece of security-related information. More specifically, a security token typically relays some form of identity, although this isn't strictly required. Typical examples of security tokens include x.509 certificates and XrML (eXtensible rights Markup Language) documents. WS-Security includes both signed and unsigned tokens.
A signed security token is a piece of security information such as a Kerberos ticket or an x.509 certificate that is cryptographically signed. This signature assures issuers and recipients of these tokens that the security information hasn't been tampered with. Typically, a signed security token is in a binary format. This means that if it is present in a SOAP message, it probably will be base64 or binHex encoded.
An unsigned security token does not contain a cryptographic signature that can verify its issuer. Typically, this means that the token doesn't need this cryptographic assurance. The usual example for this is that of a username token. Clearly, there is no need to sign this kind of thing.
Obviously then, these kinds of tokens don't usually contain binary data, but are instead typically pure XML. You wouldn't expect a base64 encoding (or any kind of encoding) for these tokens.
Claim
A claim is a particularly difficult idea to get across without the definition becoming self- referential. Basically, a claim is a set of assertions made either by the subject (see below) of the security token, or the issuer of the token. These claims are usually things such as the role the subject can play, or the resources it can access.
Subject
A subject is the person or identity of the security token. In other words, it's the principal of an x.509 certificate, or the user of a username. A subject will usually have some set of claims made on its behalf with the more sophisticated tokens.
Policy
Policy is the set of specific security-related requirements a Web service has. These can range from a specific security token that is expected, certain claims that must exist, or even the key size for encrypting messages to the service.
WS-Security
With these definitions in mind, we can now delve into the WS-Security specification in more detail. The version of WS-Security I am writing about is the one that Microsoft, IBM, and VeriSign published on 12 April 2002. This version of the specification has the namespace of http://schemas.xmlsoap.org/ws/2002/04/secext for the XML elements it defines.
This specification defines a single SOAP header named <Security>. This header may occur multiple times in a SOAP message, as long as each occurrence has a different SOAP actor. Of course, there also may be one occurrence of this header with no SOAP actor.
(or)
6. b) Explain the anatomy of UDDI. (16)
The Anatomy of UDDI
There are two large pieces to UDDI, and one smaller piece. The larger pieces are:
· The data format
· The API for querying and submitting
Just as important, but not as critical for everyone to know, is the replication API. UDDI registry operators need to follow a standard API for replicating their data to the other registries. Because that is a highly specialized technology, I've omitted it from this book. However, I will say that if you need to learn how to replicate data, then you still need first to learn the data format and API. For further information, refer to the UDDI API documentation at www.uddi.org.
It's important to understand some design points of UDDI. Most important is the use of relational data references using GUIDs (Globally Unique Identifiers). This makes itself apparent in the way in which information is fanned out across multiple structures, and then related using references.
More than two dozen data structures exist in the UDDI specification; therefore, covering them all would turn this book into a reference. What we should look at are the major data structures, and there are five very important ones, each with its own sub-elements:
· businessEntity— Contains information about a specific business, such as
Microsoft.
· businessService— Contains information about a specific electronic service offered by a specific company.
· tModel— Categorizes a type. A service may contain multiple types.
· bindingTemplate— Collects tModels and other specific information about a service.
· categoryBag— Collects name–value pairs for a general categorization. businessEntity.
The following sections discuss businessEntity, businessService, and tModel in greater detail.
businessEntity
The businessEntity type holds information about specific businesses. Of course, there is no requirement that these documents precisely correspond to a single business entity. They could correspond to corporate entities, such as subsidiaries or corporate divisions.
This structure contains the following main pieces of information:
· businessServices— The service that this entity hosts
· categoryBag— A generic bag of names and values for properties that this entity has
· identifierBag— Similar to the category bag, a set of name–value pairs for generic information about the business entity
· contacts— A list of people to contact
· discoveryURLs— The location of documents that contain more information
businessService
The businessService document holds information about a specific service for a particular service. It contains the following data:
· serviceKey— A GUID that uniquely identifies the service
· name— A friendly, human-readable name for the service
· description— A human-readable description of the service and what it offers
· bindingTemplates— A set of properties that define the taxonomy of the service
· categoryBag— A generic name–value pair that helps to define the categories to which the service belongs
Here is an example of a businessService document:
<businessService
businessKey="some GUID here" serviceKey="some GUID here">
<name>Keith's Service</name>
<description>This service doesn't do anything</description>
<bindingTemplate>
...
</bindingTemplate>
</businessService>
tModel
The tModel is the hardest to understand and most misunderstood data structure in the UDDI Schema. It's actually very simple, but extremely powerful. A tModel is a technology model; it's a type. In other words, it's a generic keyed reference to something.
7. a) Explain the anatomy of WSDL (16)
Requirements for Describing Web Services
It is possible to implement Web services in a variety of ways. For example, to send a message correctly, you need to know the following:
· The IP address and other endpoint information
· If using HTTP, the SOAPAction
· The allowable set of messages (called operations) that the service supports
· The schema (and possibly the SOAPAction) for the request message of each operation
· The response schema to expect if there is a response
· Any possible headers that may be expected in the request or response, and the schema for those
· Whether or not each operation is defined according to the rules of SOAP Section
5
· Other metadata that would be helpful, although not strictly required to send a correctly formatted message, such as inheritance chains and business processing rules
The major goals of WSDL were extensibility, abstraction, and structure
Abstract Message Operations
The abstract pieces include the <types>, <message>, and <portType> sections. In those sections, you can describe in a WSDL document all of the data and operations that a Web service implements. Note that this information is completely nonspecific to SOAP. What we are getting is purely information about the data and the messages and the operations involved. Let's review what messages and operations mean.
Messages are pieces of data that are sent from one process to another. Operations are combinations of messages that express complete sets of related messages. That is the most abstract definition I can think of, but it's actually fairly specific. For example, you can send a message that is a purchase order from machine A to machine B, and then machine B can respond to machine A with a purchase order confirmation message.
Now, it's possible to describe this message in a completely abstract manner. Although you could include the semantic content of the message in this abstract description (such as the pieces of information that make up a purchase order), the actual message format, which would include information such as that it is using SOAP and HTTP, would still be unknown.
The power of this is that you then can specify multiple concrete ways of sending and receiving these messages! For example, you can define the purchase order operation abstractly, and then implement it with both SOAP/HTTP and ebXML.
Concrete Operation Information
The <binding> and <service> sections of the WSDL document specify all of the specific, concrete pieces of information needed to send the messages in any specific operation. Typically, this is formatting information, such as the SOAP enveloping schema, and possibly encoding information, such as that found in SOAP Section 5.
Concrete binding information usually also contains other nonformatting specifics, such as the service endpoint. Typically however, the actual location of a service will be found within the <service> element, which will refer to the <binding>.
(or)
7. b) Explain the messaging protocol in web services. (16)
The SOAP Body
The <Body> element is the other mandatory element of any SOAP message. Within this element, any XML can be included. The data found within the <Body> is the data that is intended for the final message recipient. No matter how many firewalls, bridges, and other intermediaries or processes touch the SOAP message, only the final destination should actually read and act upon the <Body> data.
The SOAP Header
The <Header> element specifies data that by default is intended for the final destination, but that intention can be changed. In general, the <Header> specifies data that is orthogonal to the <Body> data; for example, it may contain authentication information (refer to Listing 9.1), or information to specify the contextual ID (e.g., a session) for the message. The <Header> isn't required for a SOAP message.
SOAP messages can be very simple, because the specification states that although a namespace declaration is recommended, neither it nor the <Header> element is required. This means that the following SOAP message is legal, albeit useless:
<Envelope>
<Body />
</Envelope>
Here is an example of a slightly more complicated SOAP message:
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<Alert xmlns="http://keithba.com/alerts">
KeithBa is online!
</Alert>
</Body>
</Envelope>
Listing 9.1 Using the Header for Authentication
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Header>
<AuthHeader xmlns="http://keithba.com/security">
<UserName>Keith</UserName>
<Pwd>KeithRocks!</Pwd>
</AuthHeader>
<Context xmlns="http://keithba.com/context">
http://keithba.com/alerts/1234321
</Context>
</Header>
<Body>
<Alert xmlns="http://keithba.com/alerts">
KeithBa is online!
</Alert>
</Body>
</Envelope>
Actors
Header elements, by default, are intended for the final destination, that is, the <Body> recipient. However, you can reset the destination of the header data to another recipient. As a matter of fact, you can have a header for the final destination, another for a firewall, and yet another for another firewall.
Firewalls, Bridges, and Intermediaries
SOAP is a messaging protocol. Messages aren't always sent from one machine (the sender) directly to just one other machine (the destination). Often, you may need to send a SOAP message through several intermediares. These intermediares may be bridges, which take the SOAP message as HTTP and send it out over SMTP. Or they may be firewalls, which take the message and verify that is authorized.
Imagine that our authentication header from Listing 9.1 were really intended for the destination's firewall, which handles authorization, but that the context were still intended for the final destination. In this case, the actor attribute would be used to indicate the intended recipient of the header data, as shown in Listing 9.2.
Listing 9.2 Using the Actor Attribute
<soap:Envelope soap:xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<AuthHeader
soap:actor="http://theFirewall"
xmlns="http://keithba.com/security">
<UserName>Mel</UserName>
<Pwd>MelRocks!</Pwd>
</AuthHeader>
<Context xmlns="http://keithba.com/context">
http://keithba.com/alerts/1234321
</Context>
</soapHeader>
<soap:Body>
<Alert xmlns="http://keithba.com/alerts">
KeithBa is online!
</Alert>
</soap:Body>
</soap:Envelope>
The mustUnderstand Attribute
Another attribute that can be applied to headers, called mustUnderstand, indicates that the intended recipient of the header must process and semantically understand the header. Otherwise, a standard error must be returned (refer to the section entitled Errors with SOAP later in this chapter).
Listing 9.3 shows an example of using the mustUnderstand attribute on the context header from Listing 9.2.
Listing 9.3 Using the mustUnderstand Attribute
<soap:Envelope soap:xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<AuthHeader
soap:actor="http://theFirewall" xmlns="http://keithba.com/security">
<UserName>Mel</UserName>
<Pwd>MelRocks!</Pwd>
</AuthHeader>
<Context
xmlns=http://keithba.com/context
soap:mustUnderstand="true" >
http://keithba.com/alerts/1234321
</Context>
</soapHeader>
<soap:Body>
<Alert xmlns="http://keithba.com/alerts"> Melissa is online!
</Alert>
</soap:Body>
</soap:Envelope>
In this example, if the intended recipient of the context header (in this case, the final destination of the SOAP message) doesn't semantically understand the header, then an error must be returned. By semantically understand, I mean that the final destination must be expecting the header. This varies from SOAP toolkit to SOAP toolkit, but generally it means that unless there is specific code in the message handler for this header information, the SOAP runtime of the toolkit should raise the error.
8. a) How will you create a web service using ASP.NET? (8) Building an XML Web service with ASP.NET is easy. Here is a simplified list of the
tasks required:
1. Verify that you have IIS and the .NET Framework installed.
2. Create a virtual directory, which acts as an application for ASP.NET. Let's call it
"Test."
3. Create a file named Test.asmx, and put it in this virtual directory.
4. Add the WebService directive as the first line of the file:
5. <%@ WebService Class="TestClass" Language="C#" %>
6. Reference the System and System.Web.Services namespace.
7. Create a class called "TestClass".
8. Add a method to this class called Add, using the following code:
9. public int Add( int a, int b)
10. Declare this method to be callable as an XML Web service, using the WebMethod
attribute, as follows:
11. [WebMethod]
|
public class TestClass {
[WebMethod]
public int Add( int a, int b)
{
return a+b;
}
}
No comments:
Post a Comment