Web Services Technologies
| < BACK NEXT > |
[oR]Understanding Web services requires understanding four technologies XML, WSDL, SOAP, and UDDI and how they relate to one another. This section provides an introduction to each of these four pillars.
Describing Information: XML
Meaningful communication isn't possible without some agreement on how to represent what is being communicated. In the last few years, XML has emerged as the standard solution for describing information exchanged between heterogeneous systems. Not too surprisingly, then, XML is fundamental to Web services. Every other technology in the Web services family uses it in some way, and so understanding Web services requires understanding XML.[3] Providing a complete XML tutorial is beyond the scope of this book. Fortunately, grasping the basics of Web services requires knowing only a few core XML concepts. What follows is an informal description of those core ideas.
[3] In fact, Microsoft usually refers to Web services as XML Web services, which is slightly redundant.
Every Web services technology relies on XML
XML provides a way to describe information. That information is typically contained in an XML document, which is a set of characters that meets the basic syntactic requirements of XML. An XML document contains one or more elements, each of which is demarcated using tags. A tag is typically a word enclosed in angle brackets, such as <Account> or <Balance>. Tags are used in pairs, beginning and ending each element, and the end tag in an element is just the start tag with a slash in front of the word. Each element contains information that has some relationship to the word in the tags. For example, in the element
An XML document contains one or more elements
<Account>729-1269-4785</Account>
the text between the two tags probably represents the number of some account, such as a checking account at a bank. Similarly, in the element
<Balance>3,822.55</Balance>
the text between the tags might represent the amount of money currently available in an account. Given the right set of tags, it's possible to create an XML document containing elements that describe almost any information. You might, for example, create a simple document containing information about bank accounts and the balances they contain using only the two elements just described.
The start tag for an element can also contain one or more attributes. Each attribute describes some aspect of the element in which it appears. For example, in the element
<Account type="checking">729-0084-7823</Account>
the type attribute indicates that this is a checking account.
Elements can contain attributes
An optional simplification, one that's especially useful in elements with attributes, allows omitting the end tag from an element. To indicate that an element consists of only a single tag, a slash can appear before the closing bracket. For example, if a particular document lists the types of accounts a customer has, it might contain the element
<Account type="checking"/>
This is equivalent to, but simpler than, this:
<Account type="checking"></Account>
Elements are the core of an XML document. Yet how are these elements actually defined? There must be a way to specify a group of elements (and thus tags) that will be used for a particular purpose. In the original incarnation of XML, elements were defined using document type definitions (DTDs). DTDs had various limitations, however, so today a more flexible approach called the XML Schema definition (XSD) language is used. The XML Schema language is too complicated to illustrate here, but the basic idea is fairly simple. Each schema defines one or more elements, along with rules on how those elements can be used. For example, a schema might define an Envelope element demarcated with the tags <Envelope> and </Envelope> and then mandate that this element can contain within it one or more occurrences of a Body element, demarcated with the tags <Body> and </Body>. An XML document that conforms to a particular schema is said to be valid.
An XML document can have an associated XML schema
If a single document will use tags from only one schema, life is simple. It's common, however, to mix elements from two or more schemas in a single document. Since the schemas were created independently, it's entirely possible that the same tag is defined in each schema with a different meaning. For example, the <Account> tag in one schema might identify a checking account element, while the very same tag defined in some other schema might identify an element representing a brokerage account. To mix tags from different schemas in the same document, there must be a way to associate an element with the schema in which it's defined. Providing this association is the role of namespaces. A namespace provides a unique identifier for a group of names. Each namespace is assigned a uniform resource identifier (URI).[4] Note that even though the URI used to identify a namespace often looks like a URL you type into a browser, there's no requirement that a Web page actually exists with this name. Instead, a URI just provides a convenient format for creating a unique name for some namespace.
[4] A URI can be either a Uniform Resource Locator (URL), identifying a resource on the Web, or a Uniform Resource Name (URN), which can be used to name pretty much anything.
A namespace allows specifying a scope for element names
Whatever its name, the namespace in which an element is defined can be specified using an attribute. For example, in the element
<Account xmlns="http://www.qwickbank.com/bank"> 729-1269-4785 </Account>
the xmlns attribute indicates that the Account element is defined in a namespace identified by the URI http://www.qwickbank.com/bank.
A namespace can be specified using an attribute
Finally, although not essential to its meaning, an XML document can contain comments. Comments allow including information intended for a human reader rather than for any software that processes this document. XML comments look like this:
An XML document can contain comments
<!-- This is an XML comment -->
XML contains much more than the relatively few ideas described here. Still, a basic grasp of Web services doesn't require knowing much more than the fundamentals of this data description language. Armed with these core concepts, we're ready to examine the technologies of Web services.
Defining Web Services: WSDL
To invoke a Web service, client software must know several things: It must know the name of the operation it wishes to invoke, for example, along with what kinds of input parameters that operation expects and what results it will return. For the developers of the client and server software to agree on these things, there must exist some standard format in which this information the interface between client and server can be described. In both COM and CORBA, for example, interfaces and the operations they contain can be described in an Interface Definition Language (IDL). Web services need something similar.
Clients and servers must agree on the interface between them
WSDL was created to address this problem. Unlike COM's IDL, whose syntax is derived from the C programming language, WSDL is defined using XML. WSDL isn't simple, and so completely understanding even a small interface definition expressed in WSDL requires a fairly good knowledge of XML. Despite this, however, the core elements of a WSDL definition can be understood in a straightforward way. Here's an example that illustrates the basic components of a very simple WSDL definition. Note that this example is neither legal WSDL nor legal XML, but rather a simplified illustration of the language's key aspects.
WSDL can be used to describe Web services interfaces
<definitions name="AccountAccess"> <types> <element name="BalanceRequest"> <!-- definition of input type, e.g., Account, appears here --> </element> <element name="BalanceResult"> <!-- definition of output type, e.g., Balance, appears here --> </element> </types> <message name="GetBalanceInput"> <part name="body" element="BalanceRequest"/> </message> <message name="GetBalanceOutput"> <part name="body" element="BalanceResult"/> </message> <portType name="AccountAccessPortType"> <operation name="GetBalance"> <input message="GetBalanceInput"/> <output message="GetBalanceOutput"/> </operation> </portType> <binding name="AccountAccessSoapBinding" type="AccountAccessPortType"> <soap:binding transport= "http://schemas.xmlsoap.org/soap/http"/> <operation name="GetBalance"> <!-- definitions for input and output bindings appear here --> </operation> </binding> <service name="AccountAccessService"> <port name="AccountAccessPort" binding="AccountAccessSoapBinding"> <soap:address location= http://www.qwickbank.com/accounts.asmx"/> </port> </service> </definitions>
This definition has only a single operation, GetBalance, that takes an account number as its input and responds with the balance in that account. WSDL is a nontrivial language, and so even this simplified description of a simple interface isn't especially simple. Yet with a little effort, it's not hard to understand what the key parts of the definition are and what they're defining.
To see the definition's overall structure, note that like every WSDL interface, all of the elements in this example are contained within an outermost definitions element. The key elements within definitions are types, message, portType, binding, and service. How each of these is used will be described shortly, but first, it's important to understand that the contents of a WSDL interface can be thought of in two logical parts. First, operations are defined abstractly using the types, message, and portType elements. Once this is done, those abstract operations are then bound to a specific protocol using the binding and service elements. WSDL doesn't assume that any particular protocol is used to invoke the operations it describes, and so the same set of operations can have bindings defined for more than one protocol.
A WSDL interface defines operations, then binds them to one or more protocols
To get a sense of how operations are specified, look at the types, message, and portType elements in the example shown earlier. The types element is used to define basic types that will be needed later in the definition. In this example, those types are BalanceRequest, which specifies the account number, and BalanceResponse, which defines the type of the returned information. The contents of these types are omitted in this simple example, but they are the parameters that are passed into and out of the operation this interface defines. The next elements use the message element to define the messages sent and received by the GetBalance operation, and they make use of the types just defined. The first, called GetBalanceInput, contains a value of the type BalanceRequest, while the second message, GetBalanceOutput, contains a value of the type BalanceResponse. Once the necessary messages and the types they contain have been defined, it's possible to define the GetBalance operation that uses those messages. Operations are specified within the portType element, and as shown earlier, each operation can define its input and output messages. In this case, those messages are GetBalanceInput and GetBalanceOutput, both defined earlier in this WSDL interface.
The types, message, and portType elements are used to define operations
All three of the elements described so far have focused on defining the GetBalance operation. The last two elements in this example associate (that is, bind) that operation to a particular protocol, which in this case is SOAP. The binding element defines the AccountAccessSoapBinding, explicitly associating the GetBalance operation with the SOAP protocol. Finally, the service element explicitly defines a port, associating the AccountAccessSoapBinding with a particular URL at which this service, the GetBalance operation, can be found. In this example, the GetBalance operation is provided by the fictitious QwickBank, and so it can be accessed at the URL http://www.qwickbank.com/accounts.asmx.
The binding and service elements are used to define a protocol binding
All of this might seem like a lot of work (and remember, several details are omitted in this simplified example), but the result is a quite flexible approach to defining Web services interfaces. Given the diversity of uses for Web services, the flexibility WSDL provides is both necessary and useful. And fortunately, as described in more detail in Chapter 7, WSDL is typically produced and consumed by software tools such as Visual Studio.NET; people don't usually need to look at it.
People seldom need to use WSDL directly
Accessing Web Services: SOAP
While WSDL doesn't require any particular protocol, it's fair to say that the most common choice for invoking Web services is SOAP. SOAP isn't especially complicated, and so even a brief description doesn't need to omit much detail. To begin, think about what's required to invoke a Web service. To convey any kind of request and return a response, it's useful to define an envelope that carries the information in those messages. A key part of SOAP, then, is the definition of a standard envelope format. Each envelope that is, each message sent usually contains some typed information. A call to the GetBalance operation described in the previous section, for example, contains a string representing an account number. To enable this, SOAP specifies a set of encoding rules for representing data while it's in transit. Finally, because it's common to express remote communications as a request followed by a response, SOAP defines a convention for representing remote procedure calls and responses. (SOAP can also be used for asynchronous communication; however, it's not limited purely to synchronous calls.) These three things an envelope, a set of encoding rules, and an optional remote calling convention are the heart of what SOAP defines.
SOAP defines an envelope and rules for representing information sent in that envelope
As with WSDL, the clearest way to get a concrete feeling for SOAP is to look at an example. Suppose a client wished to access the GetBalance operation exposed by QwickBank and defined in the last section. Here's how the SOAP message for invoking that operation might look:
<soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <GetBalance xmlns="http://www.qwickbank.com/bank"> <Account>729-1269-4785</Account> </GetBalance> </soap:Body> </soap:Envelope>
Like all SOAP messages, this one consists of an Envelope element with an embedded Body element. The Envelope element identifies the standard XML namespace that defines the SOAP envelope itself, while the Body element contains the primary contents of the message and also illustrates the SOAP convention for making a remote request. In this example, the GetBalance operation is being invoked, and it's defined in another XML namespace created by QwickBank. The operation has one parameter, the number of the account whose balance should be returned, which in this case is 729-1269-4785.
Each SOAP envelope contains a body
Here's how the response to this message might look:
<soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <GetBalanceResponse xmlns="http://www.qwickbank.com/bank"> <Balance>3,822.55</Balance> </GetBalanceResponse> </soap:Body> </soap:Envelope>
Once again, the message consists of an Envelope element containing a Body element, and the Envelope references the standard SOAP namespace. The Body contains the response returned by the GetBalance operation, which is the amount of money in this account. And as before, the XML namespace containing the operation's definition is identified within the message's Body.
These two messages provide very simple examples of all three core aspects of SOAP: the envelope, the encoding rules, and the convention for representing remote calls and responses. There are many aspects of real communication that they don't show, however. The most obvious of these is that there's no way to tell from these examples how the messages are conveyed between the parties involved in the communication. The most common choice today is to send the request on an HTTP POST message, with the response sent back on the standard HTTP response to a POST. For example, if we assume that the mes sages shown earlier are exchanged using HTTP a reasonable although not obligatory assumption what gets sent initially might actually look like this:
SOAP messages are most commonly conveyed using HTTP
POST /AccountAccess/Accounts.asmx HTTP/1.1 Host: www.qwickbank.com Content-Type: text/xml; charset="utf-8" Content-Length: 231 SOAPAction: <soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <GetBalance xmlns="http://www.qwickbank.com/bank"> <Account>729-1269-4785</Account> </GetBalance> </soap:Body> </soap:Envelope>
The SOAP message in this example is just the same as before. What's different is that it's now preceded by an HTTP POST header. This header identifies the machine to which this message should be sent and the application that should handle it (which in this case is an .asmx page, indicating that the Web service is implemented using ASP.NET); it identifies the content type and includes everything else necessary to convey this message from sender to receiver using HTTP. As this example shows, the HTTP header must contain the SOAPAction field, which among other things can be used by a firewall to block SOAP traffic.
SOAP requests are commonly sent on an HTTP POST
The response would also likely be sent over HTTP and might look as follows:
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: 213 <soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <GetBalanceResponse xmlns="http://www.qwickbank.com/bank"> <Balance>3,822.55</Balance> </GetBalanceResponse> </soap:Body> </soap:Envelope>
As before, the message itself is no different from the earlier example. All that's new is the information added in front of the message to allow it to be sent via HTTP. Once again, it's important to emphasize that, although it's very common, sending SOAP messages over HTTP is not required other protocols can also be used. Also, the example shown here might seem to imply that SOAP messages must always take the form of a request and a response. While this is also common, it too is not required. SOAP defines a convention for specifying requests and responses but doesn't require using it.
To be as broadly useful as possible and to avoid unnecessarily reinventing existing technologies, there are several things that the SOAP specification does not currently define. As already mentioned, the spec doesn't define what protocol should be used to convey SOAP-defined messages, and it also doesn't define how to provide security services such as authentication and data privacy. Instead, those services are currently provided as necessary depending on the protocol used to carry SOAP messages. When those messages are conveyed using HTTP, for instance, one possibility is to use the Secure Sockets Layer (SSL) protocol to provide a secure channel (although as described in Chapter 8, .NET My Services takes another approach). SOAP messages sent using some other protocol, such as a messaging technology, might well use another mechanism to provide the required security services.
The SOAP spec doesn't define how security should be provided
Because SOAP is commonly carried over HTTP, it can potentially pass through firewalls undetected. Firewalls typically leave open port 80, the port used by HTTP, to allow access to Web servers. Traditional protocols for remote access such as Distributed COM (DCOM) and the Object Management Group's Internet InterORB Protocol (IIOP) generally require opening a range of ports in the firewall, something network administrators are loath to do. By using port 80, SOAP avoids this problem. Administrators can still block SOAP calls if desired, however, by filtering out any HTTP request that contains SOAP content. If calls are not blocked, then the use of some reliable authentication mechanism for SOAP calls is critical for any organization that cares about security.
SOAP can pass through firewalls more easily than protocols such as DCOM or IIOP
The SOAP specification also defines other useful components for SOAP messages. An envelope may contain a Header element, for example, that itself contains elements allowing various kinds of information to be sent. A header might contain information used to authenticate a client, for instance, or an indication of the path a message should take. While the initial SOAP specification leaves headers completely up to each application, work has begun on defining a few standard headers. (Microsoft's initial proposals in this area are described later in this chapter.) Each header can contain a mustUnderstand attribute that indicates whether it can be safely ignored. If this attribute is present and has the value 1, a receiving SOAP implementation either must be able to understand it or must not process the message that contains it at all.
A SOAP message can contain one or more headers
The specification also defines a standard Fault element for conveying error information. This element contains a fault code that identifies the error, a fault string that provides human-readable information about the error, and possibly other information. A few standard faults are defined, including the MustUnderstand fault that is sent when a header in a received message contains a mustUnderstand attribute with a value of 1 but the receiver doesn't understand this header.
A SOAP message can identify an error with a Fault element
Finally, notice once again that nothing about this messaging standard is connected to any particular operating system, programming language, or object model. This fact is one of the most important attributes of this technology. Ecumenical by design, SOAP can be adopted by all faiths in the software world today.
SOAP InteroperabilitySOAP has been endorsed by Microsoft, IBM, Oracle, Sun, BEA, and many other vendors. Even the open source world has embraced SOAP, with the Apache Web server now providing strong support. As a result, several different implementations of SOAP exist. To fulfill the promise of this new technology, all of these implementations must interoperate seamlessly. Sadly, the reality today falls somewhat short of this ideal. For example, SOAP allows adding proprietary headers, something that implementations quite commonly do. Knowing that two products each speak SOAP isn't enough to be confident that they will interoperate one or both may send entirely legal but nonetheless proprietary headers. Another source of problems is that the SOAP 1.1 specification was completed before the XML Schema specification. As a result, SOAP's rules for expressing information in XML, defined in Section 5 of the SOAP spec, don't exactly match what's allowed in a standard XSD schema. Also, think about the problem of converting from the type system of a programming language, such as C# or VB.NET, into the XML types required by SOAP. The SOAP 1.1 specification doesn't define how this should be done in every case, so different implementations can make different choices. (In fact, ASP.NET provides several options for controlling this translation.) Add the problems of converting from, say, C#'s type system first into XML and then into the type system of another language, such as Java. The potential for introducing incompatibilities in this process is very real. Tim Ewald, a principal scientist at DevelopMentor in Torrance, California, has raised the possibility of a Web services winter, a time during which this promising technology lies cold and barren because interoperability problems make it impossible to use effectively. This vision may well come true in the short term, but over the long run, I'm optimistic. I think the interoperability problems we're seeing today are the natural growing pains of a new technology, and they'll eventually be fixed by SOAP's current owner, the W3C's XML Protocol group. Still, be aware that cross-vendor interoperability with SOAP isn't always a given it may take some work. |
Finding Web Services: UDDI
The technologies discussed so far focus on describing a Web service and then invoking it over a network. While these are crucial parts of the solution, some important problems still remain. For example, how can businesses find out what Web services are exposed by their partners? How can developers find the WSDL interface they need to implement for a client for a particular service? How can software that wishes to invoke a Web service determine whether that service is implemented in a compatible way? And how can this information about Web services be managed?
All of these problems are addressed by UDDI. An organization that wants to expose Web services can create a UDDI business registration, an XML document whose format is specified in a UDDI-defined schema. Once they've been created, these business registrations are stored in a replicated database known as the UDDI business registry. A copy of the business registry is maintained by each UDDI operator site. These sites communicate with one another as needed to maintain consistency among the information they store. To access the information in the UDDI registry, client software always uses SOAP over HTTP. This means that UDDI is itself a Web service, one that provides useful information to other Web services. Finally, UDDI also defines a standard application programming interface (API) that developers can use when writing software that accesses or modifies the information in the registry.
UDDI stores registrations describing Web services and more
Describing a Business Registration
The UDDI XML schema defines the common structure for all business registration documents. Each one contains a businessEntity element that can contain one or more businessService elements. Each of these, in turn, can contain one or more bindingTemplate elements, each of which identifies a particular tModel. As always, the easiest way to make sense out of this is to walk through a simple example. As with WSDL, a complete example of a businessEntity element providing even a single Web service is beyond the scope of this chapter. The example that follows is intended to give some idea of how the information stored in the business registry might actually look for QwickBank's very simple GetBalance service. What follows is not a fully complete UDDI definition it's just a simplified example.
A registration can describe one or more Web services and other information
<businessEntity businessKey= "E7CD0D00-1827-11CF-9946-444553540000"> <name>QwickBank</name> <description>Internet bank</description> <contacts> <contact> <personName>Webmaster</personName> <email>Webmaster@qwickbank.com</email> </contact> </contacts> <businessServices> <businessService serviceKey= "15940A43-1956-63DC-0124-444553540000"> <name>AccountAccess</name> <bindingTemplates> <bindingTemplate bindingKey= "9E43F20A-1963-22EC-1053-444553540000"> <accessPoint> http://www.qwickbank.com/accounts.asmx </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey= "uuid:F7A90326-EB0D-40E0-9013- F55606BD4804"> <description> QwickBank balance access </description> </tModelInstanceInfo> <tModelInstanceInfo tModelKey= "uuid:43CAC139-D822-40B5-A004- 82DDDC0A12F2"> <description> WSDL binding reference </description> <instanceDetails> <!-- More about the WSDL interface --> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate> </bindingTemplates> </businessService> </businessServices> </businessEntity>
The businessEntity element, container for all the others, has a businessKey attribute that provides a globally unique identifier for this particular business. To guarantee uniqueness, these names are 16-byte universally unique identifiers (UUIDs).[5] A businessEntity also typically contains information about the organization described by this registry entry. In this example, that information includes the organization's name, what it does, and whom to contact for more information. Each of these pieces of data appears in an appropriate element: name, description, and contacts, respectively. Finally, each businessEntity can contain a businessServices element indicating what Web services this organization provides.
[5] A UUID consists of a 6-byte globally unique value such as the Ethernet address of the machine on which it was created, a timestamp indicating when it was created, and a few more fields. The combination of the unique value and the timestamp provides uniqueness, since no other machine could have produced this same UUID. UUIDs are also sometimes referred to as globally unique identifiers (GUIDs).
UUIDs provide unique names for several elements in a registration
The businessServices element, in turn, contains one or more businessService elements, each describing a particular service. This example shows only a single businessService describing QwickBank's very simple offering. Like a businessEntity, the businessService element has a UUID key that serves to identify this specific service definition. It can also include a name for this service, which in this example is AccountAccess, and a bindingTemplates element. Each bindingTemplates element can contain one or more bindingTemplate elements, each identified with a UUID key. The single bindingTemplate in this example contains the information needed for a client to connect to and use QwickBank's Web service. This information includes the access point, expressed here as the URL at which QwickBank's account access service can be found, as well as information about this service.
A bindingTemplate contains the information needed for a client to use a Web service
The specifics of a Web service are defined using one or more tModels.[6] Each tModel element identifies some specific aspect of a service. This information can include defining what the service offers, identifying a particular WSDL interface, specifying what protocols can be used to access the service, mandating certain security requirements, and more. A typical UDDI registration will contain multiple tModels for each bindingTemplate. Note, however, that information identified by the tModel is not directly included in the bindingTemplate element. Instead, each tModel has a unique identifier (again, a UUID) that references the actual definition of this tModel. Although it's not shown in the example, this tModel definition can also be made accessible in the UDDI business registry.
[6] The t doesn't stand for anything in particular it was just an initial letter that the UDDI committee was able to agree on.
A tModel can identify one or more characteristics of a Web service
The example here shows a typical use of tModels. The first tModel in the bindingTemplate indicates that this is an interface provided by QwickBank for the purpose of accessing account balances, while the second references the WSDL file that describes this interface. In general, a bindingTemplate can include as many tModel references as necessary to specify completely the service it defines.
The businessEntity in this example contains only a single businessService, which in turn contains only one bindingTemplate. A real business, of course, might well offer many different services, with multiple potential bindings for each one. Still, this simple example gives the flavor of the nested structure UDDI uses to store the information needed to access a Web service.
The UDDI API
Storing information about Web services in UDDI's business registry wouldn't be very useful if there weren't some way to access that information. Various applications need to create, search, and modify this information, so to make life easier for the developers of those applications, UDDI also defines a standard API. This interface defines a relatively small set of calls that is divided into two logical parts.
UDDI defines a two-part API for applications accessing its services
The calls used by applications that must search the business registry make up the Inquiry API. These calls include the following:
find_business: Locates information about specific businesses in the registry
find_service: Locates specific services within a particular businessEntity
find_binding: Locates a specific binding within a particular businessService
find_tModel: Locates information about a particular tModel
get_businessDetail: Returns the businessEntity information for one or more businesses
get_serviceDetail: Returns the businessService information within a particular businessEntity
get_bindingDetail: Returns the bindingTemplate information for one or more bindings
get_tModelDetail: Returns information about one or more tModels
The Inquiry API allows searching the registry
While the Inquiry API allows access to the business registry, applications such as management tools must also be able to create and modify this information. The calls used for this make up the Publishing API. These calls include the following:
save_business: Creates or updates businessEntity information
save_service: Creates or updates businessService information
save_binding: Creates or updates bindingTemplate information
save_tModel: Creates or updates tModel information
delete_business: Deletes the information in a specific businessEntity
delete_service: Deletes the information in a specific businessService
delete_binding: Deletes the information in a specific bindingTemplate
delete_tModel: Deletes information about a tModel
The Publishing API allows creating and modifying information in the registry
Accessing information in the UDDI business registry that is, using the calls in the Inquiry API requires no authentication. Any client can access anything. Changing that information, however, does require authentication. An application using any of the calls in the Publishing API must prove its identity to the operator site it's accessing. How it does this is up to that site, but all calls in this part of the UDDI API must use HTTPS, that is, HTTP over SSL.
Remote requests to modify the registry use SSL
UDDI is an important piece of the Web services puzzle. Without it, there would be no way for organizations providing Web services to let potential clients know what they have to offer, nor would there be a simple way for clients to learn the details they need to access those services. And although a primary goal of UDDI is to allow clients to locate Internet-based services, it can also be useful inside a single organization. Web services are a significant advance, yet they couldn't achieve their full potential without a service like UDDI.
UDDI provides a necessary service in a Web services world
UDDI and DiscoUDDI is clearly a good idea. Yet like most good ideas, it's not perfect. One problem is that it's a fairly complex solution to what should be a simple problem. For developers, at least, a primary function of UDDI is to let them find the information they need to build compatible Web services clients. Today, this means letting developers find WSDL definitions for those Web services. Yet UDDI isn't especially focused on addressing this problem. It's certainly possible to store WSDL definitions UDDI's tModels are general enough to allow storing anything but UDDI has been used first for storing business information. While this may be valuable at some point, if developers can't build compatible clients for Web services, those Web services will have no business value. While Microsoft is clearly behind UDDI, the company also recognizes that UDDI isn't the complete answer today. As a result, the .NET Framework includes Disco, a much simpler technology for discovering Web services. Disco is focused on accessing what developers need to build compatible clients, especially clients that will access Web services within a single organization's environment. Visual Studio.NET has built-in support for UDDI, but it also supports Disco. New technologies are seldom exactly right. It takes time to understand the real problems and to figure out how best to solve them. UDDI's chances of success are good, but in the short run, it's not the only answer. |
| < BACK NEXT > |
EAN: 2147483647
Pages: 60