xml web services - wichita state university · xml web services page 3 of 21 part i –...

XXMMLL WWEEBB SSEERRVVIICCEESS

HANGNING QIU CS843 TERM PAPER

MAY 9, 2003

XML WEB SERVICES of 21

XXMMLL WWEEBB SSEERRVVIICCEESS

Introduction

This paper is an essay on XML Web services and is accompanied with a case study on architecting an XML Web service solution. It is divided into two parts. In Part I, this paper offers an architectural overview of XML Web Services, and discusses the advantages, the limitations, and the future of this fast evolving technology from the point of view of distributed computing systems. In Part II, this paper proceeds to discuss the case study with a focus on the architectural analysis and design necessary for building a real-world distributed application using XML Web Services.


PART I – ARCHITECTURAL OVERVIEW

What is an XML Web Service

In a nutshell, an XML Web service is a service program that relies on the Web programming model and the XML technologies. First, an XML Web service is always built on the Web programming model. In contrast to traditional programming models, the Web programming model uses World Wide Web for achieving system-level development goals such as interoperability and scalability. These Web technologies include TCP/UDP/IP and higher level transport protocols such as HTTP, FPT, SMTP as well as service infrastructures built on the transport protocols such as RPC and DCOM. Second, an XML Web service is always built on the XML technologies. Similar to HTML, XML is also derived from SGML. While HTML has evolved into a most popular markup language for labeling the format of plain texts for Web publishing, XML has evolved into a most popular general-purpose markup language for labeling the contents of plain texts or any information in text format. Unlike HTML, XML follows strict rules, so it can be used to describe programming messages where messaging rules must be unambiguous. In an XML Web service, XML is used to label every I/O service message. It is also used to describe the protocols and formats of such in/out messaging. Earlier, DTD used to be the document that defines the rules and formats of XML texts, but a DTD document is not XML. An XML document that is used to validate XML texts is called an XML schema. Third, an XML Web service is generally not an end-user application; instead, it is usually a service that uses Web-based transmission protocols and XML messaging. This means, the actual users of an XML Web service is usually not a human, but one or more other programs. A program that uses an XML Web service is called an XML Web service consumer, and the program that exposes the XML Web service is called an XML Web service provider. Fourth, XML Web services represent the vision of a "programmable Web" as well as the cutting-edge technologies for delivering this new generation of interactive Web. Due to the versatility of Web technologies, XML Web services are special Web resources that


can interact with a variety of Web-capable service consumers, including programs, human users, mobile devices, e-business portals, and so on. Generally speaking, typical XML Web services aggregate server resources and can automatically process service requests and respond with messages. Based on this, they can serve as building blocks of regular business applications. Fifth, XML Web services also represent a programming model that in essence differs from the more traditional Web programming model that most Web applications use. A major difference is that XML Web services ensure a programming model that is truly programming language neutral and platform independent, while Web applications are generally locked down to one platform and almost always have issues integrating with different Web applications that run on different platforms and/or use different programming languages. Another major difference is that XML Web services represent a distributed, loosely coupled, and messaging-oriented framework upon which one can build sophisticated distributed business solutions, whereas most Web applications are end-user systems.

Categorization of XML Web Services

There are three categories of XML Web services: non-standards based XML Web services, non-SOAP standards based XML Web Services, and SOAP and other W3C standards based XML Web services. First, non-standards based XML Web services are XML Web service providers that use private, proprietary messaging rules and formats with no established standards. Programs that rely on XML and Web for programmatically exchanging messages fall into this category. Second, non-SOAP standards based XML Web services are XML Web service providers that use industry standards of their choosing, other than SOAP or SOAP-based standards, in messaging. A good example is an XML Web service provider that uses RSS (Rich Site Summary) in publishing news reports online and in exchanging other electronic information over the Internet. RSS is an XML based contract on how to publish contents on the Web. It originated in 1997 and has evolved into one of the major uses of XML in online publication. Third, SOAP and other standards based XML Web services are standard XML Web services. In most technical articles, XML Web services by default refer to these standard XML Web services.


Standard XML Web Services

Standard XML Web services are based on a standards stack that includes:

• XML - essential. XML is used everywhere in standard XML Web services. In particular, all the messages received or sent by XML Web services eventually have to be in XML.

• SOAP - essential. SOAP is the standard for use by XML Web service message couriers. It is the XML based wrapper of XML Web service messages, and is used to convert between underlying XML messages and SOAP messages for transmission purposes. More will be discussed later.

• WSDL – optional, but most likely required. WSDL is the XML-based language of describing the types and bindings of XML Web services. More will be discussed later.

• UDDI - optional. UDDI is the specifications for building meta-XML Web services that categorize regular XML Web services and provide a discovery mechanism for regular XML Web services. A UDDI server is an XML Web service. More will be discussed later.

Simple Object Access Protocol

In essence, SOAP is a protocol for carrying other information for transmission purposes. In May 2000 W3C defines SOAP 1.1 as follows:

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses.


First, by this definition, SOAP provides an envelope (a courier or a carrier) for the messages to be transmitted. To do this, SOAP also defines a set of encoding rules and a convention for invoking remote method calls. Second, SOAP speaks XML, but itself is programming language neutral and platform independent. Third, SOAP can be used to “envelope” any type of information that is correctly encoded and appropriately represented. Such information can be textual or binary, can be plain or encrypted, and can be local or remote. A possible misunderstanding is to think that SOAP can only be used for plain text information, or XML messages in particular. Fourth, SOAP is not bound to one particular transport protocol such as HTTP. This means, SOAP messages can be transmitted using any transport protocol. A common misunderstanding is to think that SOAP can be and can only be used along with HTTP. In fact, SOAP can use FTP, SMTP, MSMQ, and virtually any software and hardware protocol that is capable of transmitting XML messages. This neutrality in using transport protocols is very valuable when time comes to using SOAP and hence XML Web services in wireless communications. Fifth, SOAP does not care about the actual contents of the message it carries. It only cares about how to use SOAP messages to carry the underlying message such that the underlying message can be transmitted using SOAP and SOAP tools. Sixth, SOAP messaging uses the request/response (sender/receiver) pattern similar to that for HTTP and FTP. The sender sends a request and receives a response, and the receiver receives a request and sends a response. To illustrate how SOAP works, suppose that there is an XML Web service method written in C#: [WebMethod] //an attribute tag in Visual C# to indicate that this is an

XML Web service.

public bool Login (string username, string password) {

return (userName.Equals(“username”) && password.Equals(“password”));

}

And there is a call on the method: bool result = Object.Login (“username”, “password”);


When a remote XML Web service consumer calls the Login method using HTTP with these two arguments, the service request message in SOAP (along with the HTTP headers) should look like this: POST /WebService1/Service1.asmx HTTP/1.1

Host: localhost

Content-Type: text/xml; charset=utf-8

Content-Length: xxx

SOAPAction: "http://tempuri.org/Login"

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<Login xmlns="http://tempuri.org/">

<userName>username</userName>

<password>password</password>

</Login>

</soap:Body>

</soap:Envelope>

The XML Web service provider will read the calling information out of the HTTP and the SOAP context and forward it to the object that exposes the Login method as an XML Web service. The return information will be packaged in SOAP and sent down to the consumer side. The service response message (again along with the HTTP headers) should look like this: HTTP/1.1 200 OK

Content-Type: text/xml; charset=utf-8

Content-Length: xxx

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<LoginResponse xmlns="http://tempuri.org/">

<LoginResult>true</LoginResult>


</LoginResponse>

</soap:Body>

</soap:Envelope>

Seventh, the details on how remote method invocations and SOAP messages are mapped to each other should be transparent to XML Web service developers. In typical business applications, such details are at a very low level. XML Web services tools such as the Web service toolkit from IBM and Visual Studio .NET from Microsoft, or supportive infrastructures such as Microsoft .NET sever 2003, should be used to hide such details from developers.

Web Service Description Language

For an outsider XML Web service consumer to be able to call a remote XML Web service, all the type and binding information about the service must be known to the consumer. WSDL is the language intended for doing that. In March 2001, W3C defined Web Service Description Language 1.1 as following:

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.... WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.... A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service.

First, WSDL describes the types, bindings and related information about a service but does not directly touch on what the service actually does. It is similar to an interface definition language like IDL that defines “types” and interfaces but not implementations. Second, similar to SOAP, WSDL speaks XML, but itself is not bound to any programming language or to any particular platform.


Third, This implies, WSDL is supplementary to SOAP, but does not require SOAP for being useful. Fourth, being XML-based, WSDL is both machine and human readable. This means, XML Web service tools can easily generate WSDL from existing object methods, and WSDL descriptions can also easily be mapped onto object methods in a particular programming language. And any developer can easily understand such mappings in both directions by simply examining the WSDL document. Fifth, similar to SOAP, WSDL should be transparent to XML Web service developers. This is simply because WSDL is in essence a routine type of mapping operations in developing, providing and consuming XML Web services. There are good tools doing this for developers.

Universal Description, Discovery and Integration

A cross-industry effort started in 2000 by 36 companies including IBM and Microsoft, the UDDI protocol defines a meta-XML Web service for easily, quickly and dynamically locating standard XML Web services. Unlike a general-purpose search engine, UDDI tries to categorize XML Web services and contains highly structured data about the Web services registered on the UDDI server. Unlike a repository, UDDI does not store or provide the Web services registered on the UDDI server. It is more like a global registry on the Internet. XML Web service providers may register their services on a UDDI server and XML Web service consumers may browse and search on the UDDI server for the services they are interested in.

Global XML Web Services Architecture Initiative

As XML Web services get more and more complex, the demand for better infrastructure increases. To address infrastructure issues, Microsoft proposed the GXA initiative in 2001. This initiative aims to provide – through GAX specifications – additional capabilities to baseline XML Web services in several important areas including:

• Security • Message routing • Reliable messaging


• Transactions The baseline XML Web services specifications include SOAP, WSDL and UDDI. The GXA specifications will at least include

• WS-Inspection – a secure way to browse XML Web services using UDDI. • WS-License – specifications on how several common license formats can be used

in XML Web services. • WS-Referral - a simple SOAP extension for enabling routing between SOAP nodes

on a message path to be dynamically configured. • WS-Routing – a stateless SOAP extension for sending SOAP messages

asynchronously over various communication transports including TCP, UDP, and HTTP.

• WS-Security – specifications on how to use existing W3C security specifications, XML Signature and XML Encryption, to ensure SOAP messages.

Advantages and Limitations

Standard XML Web services are built on programming language neutral, platform independent, well known standards. A high level of interoperability and the resultant loose coupling among different components of a distributed application system using standard XML Web services become the most essential characteristics of standard XML Web services. Because of this essential feature, XML Web services can be scaled to building global distributed application systems, integrating heterogeneous business services that scatter in many different places over the world, or establishing global level networking with business partners and clients. Here is a very brief comparison among DCOM, CORBA, RMI and XML Web services.

DCOM CORBA Java RMI XML Web Services

Messaging Protocol

RPC IIOP IIOP or proprietary

HTTP (or SMTP, etc) + SOAP

Message format

NDR CDR Java server XML

Service description

IDL OMG IDL Java WSDL

Service discovery

Windows registry

Naming service RMI registry UDDI


Compared to XML Web services, all other three protocols suffer from one thing: when a distributed system grows over time, the complexity of using those protocols to keep the distributed system maintainable, secure and scalable increases exponentially. The demand for a protocol like XML Web services drastically increased in the last decade, partly due to the explosive growth of the Internet and electronic business over the Internet. However, XML Web services are not a good solution in many situations. Obviously, they are not appropriate for building time sensitive, life critical, non-distributed, tightly coupled systems. Additionally, XML Web services are only as good as venders’ support for building solutions based on XML Web services. At this time, IBM Web services toolkit and Microsoft Visual Studio .NET are two best tools for quickly building nontrivial business solutions based on XML Web services. There are many things that are not easy to get done with current XML Web services tools, for example:

• Concurrent access to stateful XML Web service objects • Use small-sized binary data for large amount data exchange • Replicate complex objects over the XML Web services • ...

The Future of XML Web Services

Although XML Web services are not a good solution in many situations, the growth of XML Web services has been very impressive over the last few years. According to Gartner Inc, the XML Web services will dominate the deployment of new application solutions by 2004, and there have been about 80% of venders supporting what Gartner Inc calls the “next generation of platform middleware.”1 For all Microsoft product lines, XML and hence XML Web services have now been a built-in support, and the latest Windows server product, Windows .NET Server 2003, natively supports SOAP messaging, UDDI discovery, and XML Web services. For XML Web services to continue growing, more work will need to be done in three major areas including infrastructure, standards, and vender support.

1 Quoted from Jim Ericson, XML Grows... and Slows,

http://www.line56.com/articles/default.asp?ArticleID=4602, April 24, 2003.


First, Web service infrastructures will need to be built up to support secure, routable, reliable, and transactional XML Web services. By this time, these issues have been addressed by a couple of initiatives including the GXA initiative from Microsoft. Second, SOAP, WSDL and related standards will need to further evolve to address the issues that arise from use of those protocols. The most current draft of WSDL is version 1.1, and version 1.2 is currently under review. On May 7, 2003, SOAP version 1.2 became W3C’s recommendation. Third, vender support in form of toolkits and frameworks need to be improved. Microsoft has put a large stake in XML Web services. Microsoft has released several Web services toolkits including SOAP Toolkits and Office Web Services Toolkits, both of them available on Microsoft website for free. With the latest development tools from Microsoft, Visual Studio .NET 2002 and 2003 and Visual FoxPro 7.0 and 8.0, building an XML Web service using C++, C#, Visual Basic .NET, Visual FoxPro, J#, Jscript .NET, or even SQL scripts, has never been easier. The essential work that is needed to expose an object’s method as an XML Web service can be as simple as adding a tag to the method declaration, and the IDE will take care of everything else including building WSDL, publishing to the IIS server, and registering. And building an XML Web service consumer can be as easy as adding a Web reference to an existing WSDL document and invoking its methods. However, all this is only for the Windows systems.

Conclusions for Part I

XML Web services stand for a simple, loosely coupled, messaging-oriented platform upon which developers can build and integrate sophisticated distributed business solutions. Despite its limitations, in the last three years or so, this text based XML Web Service platform has taken a lot of territories once occupied exclusively by binary format based protocols such as RPC, DCOM and CORBA, and has permanently changed the way of architecting distributed application systems. XML Web services will dominate in the area of distributed application systems in the near future.


PART II – REPORT ON A CASE STUDY

Why this Case Study

Two of the program assignments for CS 843 involved building a small voting system using a distributed application model, including RPC, RMI, and CORBA. For using RPC in C, I wrote down 1573 lines of code (excluding all comment and blank lines) prior to porting the program from my Windows development environment to the school’s Linux environment. After that, I wrote down another several hundred lines of Java code to implement the same system in Java. Because of the amount of work (2500 lines of code, at least) and the thorough unit testing that I did before sealing the programs, I was late and suffered from heavy late penalty – so my programs must appear to be really funky junk judging by grades. To make some positive use of so much work I put in building this system, I decided to take a step further to evolve the system into an XML Web service solution for support of my term paper.

Requirement Review

The requirement can be summarized as follows: build a server and a client; the server controls access to the data; the client logs on to the server and issues commands to view and edit the voting data on the server side; the commands include list, add/remove, and vote as appropriate based on data types.

Initial Design Review

My initial design went through four stages; at that time, I had not thought of using this system as a case study for my term paper. At the first stage (see UML Diagram page 1/6) I mapped the functional requirements to a monolithic application that can roughly be divided into two tightly related parts: the controller part controls the control flow as well


as the I/O on the user interface. The helper part is a collection of helper functions that implement the functional requirements of the voting system. I actually built this monolithic system and tested out the data store and access code, which is not shown on my UML diagram because this is not directly related to the goal of this case study. At the second stage (see my UML Diagram page 2/6) I tried to abstract a server interface out of the previous monolithic system, and I mapped all of the major functional requirements onto the server interface. Then, I converted the collection of helper functions into an implementation of the server interface. At this stage, I completed the testing of my data store and access code. I also prepared most of the utility functions that help to build dynamic data objects in C, such as linked lists, dynamic string arrays, and so on. At the third stage (see my UML Diagram page 3/6) I tried to split the controller into two parts: one part implements a client side mirror interface of the server interface. The other part holds the remaining functions of the controller. With this architecture, the controller contacts the object that implements the client interface, for making all the service function calls. The client interface object contacts the object that implements the server interface, and forwards the controller’s function call requests to the real server. At the fourth stage (see my UML Diagram page 4/6) I tried to break the direct communications between the client object and the server object by introducing two more objects: RemoteClient and RemoteServer. They act as the proxy/stub for the real client and the real server object. An essential piece of work here is to give RemoteClient and RemoteServer their own communication interface, whose declaration is as follows: struct LoginInfo

{

string sUsername<>;

string sPassword<>;

};


typedef string* Array;

struct Data

{

string s1<>;

string s2<>;

Array array<>;

string error<>;

string command<>;

};

program VOTE_PROG

{

version VOTE_VERS

{

bool login(LoginInfo loginInfo) = 1;

bool execute(Data* data) = 2;

} = 2; /* version number = 2 */

} = 0x31655555; /* program number = 0x31655555 */

It is obvious that this interface is very different from the client/server interface I showed on my UML diagrams. I intentionally did this for the sole purpose of simplifying both the coding and maintenance work. I believe this technique is superior over having another mirror interface or giving them no separate interface. As can be seen later, when I need to support a different client/server protocol, all that I would need to do is to replace this interface with a new interface and then provides a new implementation, - with all the rest of my program untouched at all (except for making some adjustments due to possible data type conflicts). When I reached this point in coding and testing, I knew I had reached the starting point for implementing RPC as the only server/client communication protocol. After I implemented RPC in C, I re-implemented the entire system using Java with the exactly same architecture for demonstrating RMI. Here is the RMI interface: /*

* JRmiVoteInterfaces.java


* @author Hangning Qiu

*

* RMI server interface definition

*

*/

//package JRmiVotePkg;

import java.rmi.Remote;

import java.rmi.RemoteException;

public interface JRmiVoteServerInterface extends Remote

{

boolean login(String username, String password) throws RemoteException;

String[] getSessions() throws RemoteException;

String[] getCandidates(String sSessionId) throws RemoteException;

String[] getVotes(String sSessionId, String sCandidateId) throws

RemoteException;

boolean addCandidate(String sSessionId, String sCandidateName) throws

RemoteException;

boolean removeCandidate(String sSessionId, String sCandidateId) throws

RemoteException;

boolean vote(String sSessionId, String sCandidateId, String sUsername)

throws RemoteException;

}

Note that this RMI interface looks almost the same as the vote server interface, but they are essentially different. For program assignment #3, I replaced the RMI interface with a CORBA interface, and cleaned up the code according to the switch from RMI to CORBA. The entire assignment was done in just a few hours, including the time spent on testing, documentation, and porting to the school’s Linux environment and submitting everything. Here is my CORBA interface: module JOrbVoteServerApp

{


typedef sequence<string> strings;

interface JOrbVoteServerInterface

{

boolean login(in string username, in string password);

strings getSessions();

strings getCandidates(in string sSessionId);

strings getVotes(in string sSessionId, in string sCandidateId);

boolean addCandidate(in string sSessionId, in string

sCandidateName);

boolean removeCandidate(in string sSessionId, in string

sCandidateId);

boolean vote(in string sSessionId, in string sCandidateId, in

string sUsername);

};

};

Again, this CORBA interface looks similar to the vote server interface, but again they are essentially different. I can always swap this interface between CORBA and RMI, but the actual vote server interface and its implementation will have to be the same all the time.

XML Web Service Architecture

Now it’s time to rebuild the system as an XML Web service solution. But after reviewing the system architecture, it was obvious that the rewrite is completed unwarranted. In fact, all that I would need to do is to replace my existing RPC, RMI or CORBA interface with an XML Web service interface. Can this be done quickly? Yes, for sure, - if I turn to an excellent development tool and if the tool can hide lots of details from me without compromising my programming capability. And this tool is Visual Studio .NET 2003. I did not actually write any code to connect an XML Web service interface with my existing client and server interface, because I think this would be barely meaningful and also because writing such connecting code can be unbelievably easy using Visual Studio .NET 2003.


Here is my declaration of the first two methods on the XML Web service interface, and a demonstration of their complete implementation in C++. // WsVote.h : Defines the ATL Server request handler class

//

#pragma once

namespace WsVoteService

{

// IWsVoteService - web service interface declaration

//

[

uuid("C76C57D9-F3B2-447E-83C5-5F356911B07B"),

object

]

__interface IWsVoteService

{

[id(1)] HRESULT Login([in] BSTR bstrUsername, [in] BSTR bstrPassword,

[out, retval] bool *bResult);

[id(2)] HRESULT getSessions([out, retval] BSTR *bstrResult);

};

// WsVoteService - web service implementation

//

[

request_handler(name="Default", sdl="GenWsVoteWSDL"),

soap_handler(

name="WsVoteService",

namespace="urn:WsVoteService",

protocol="soap"

)

]

class CWsVoteService :

public IWsVoteService

{

public:

[ soap_method ]

HRESULT Login(BSTR bstrUsername, BSTR bstrPassword, bool *bResult)

{


CComBSTR username(bstrUsername);

CComBSTR password(bstrPassword);

*bResult = (username==L"username" && password==L"password");

return S_OK;

}

[ soap_method ]

HRESULT getSessions(BSTR *bstrResult)

{

CComBSTR bstrOut(L"Hello!");

*bstrResult = bstrOut.Detach();

return S_OK;

}

}; // class CWsVoteService

} // namespace WsVoteService

ALT Server wizard generated the skeleton code. Because the use of ATL makes such code almost identical to ATL-based COM programming, anyone familiar with ATL and COM can immediately start code for XML Web services – without having to know anything about SOAP, WSDL or XML. Building an XML Web service consumer in C++ is a bit trickier, so I switched to C#. Here is the complete C# code for consuming the above two XML Web service methods: using System;

namespace ConsoleApplication2

{

class Class1

{

[STAThread]

static void Main(string[] args)

{

try

{

localhost.WsVoteService ws = new localhost.WsVoteService();


bool loginSucceeded = ws.Login ("username", "password");

Console.WriteLine(

loginSucceeded?

"I got it!" :

"Login failed.");

if (loginSucceeded)

{

Console.WriteLine(ws.getSessions());

}

}

catch(System.Exception e)

{

Console.WriteLine (e.Message);

}

}

}

}

Conclusions for Part II

From the design and development experience from this case study, I strongly feel that the following two points about XML Web services are true from the point of view of a system architect. First, RPC, RMI, COM/DCOM, CORBA, XML Web services, and so on all have one thing in common: separation between interface and implementation. Compared to RPC, COM and so on, XML Web services are not much more than a different, many times better, option for building a distributed system. XML Web services may help but by no means can ensure the quality of the distributed system. Here, a sound, thoughtful architecture is more essential than anything else in building a right distributed system right. Second, an excellent development tool is essential in rapidly building fast, reliable, scalable, maintainable and extensible XML Web services. If many developers today still had to go through SOAP and WSDL processes towards building a simple XML Web services, then there would be no way for XML Web services to be popular among developers.


REFERENCES

Jim Ericson, XML Grows... and Slows, http://www.line56.com/articles/default.asp?ArticleID=4602, April 24, 2003. Microsoft Corporation, Global XML Web Services Architecture, http://www.gotdotnet.com/team/XMLwebservices/gxa_overview.aspx, 2001. OASIS standards consortium, UDDI Version 3 Specifications, http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm, 2002. World Wide Web Consortium, Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl, 2001. World Wide Web Consortium, SOAP Version 1.2, http://www.w3.org/TR/, 2003.

- Respectfully submitted -

UML DIAGRAM

V1.0.0.1 A STATIC STRUCTURE MODEL 5/1/2003 - 5/7/2003 HANGNING QIU

PAGE

1 OF 6PRINTED

5/7/2003 3:42:29 AMNOTES

This is a design, not necessarily the final implemented system.

+login() : BOOL{sequential}+getSessions() : BOOL{sequential}+getCandidates() : BOOL{sequential}+getVotes() : BOOL{sequential}+addCandidate() : BOOL{sequential}+removeCandidate() : BOOL{sequential}+vote() : BOOL{sequential}

+gUserName[1] : String = NULL+gPassword[1] : String = NULL+gLoginSucceeded[1] : BOOL = False+Sessions[1] : String* = NULL+Candidates[1] : String* = NULL+Votes[1] : String* = NULL

Monolithic::Helper{documentation =

1) Maintain state information.2) Provide service methods.

3) Encapsulate data storage.}

+False+True

«enumeration»BOOL

+main() : int{concurrent}+cli_entrypoint() : int{concurrent,documentation =1) Interact with user.2) Parse user inputs.3) Dispatch messages.}

Monolithic::Controller{documentation =

1) Parse user inputs and return outputs.2) controlls logical flow of the program.3) match logical flow with method calls.}

UML DIAGRAM


PAGE

2 OF 6PRINTED

5/7/2003 3:42:29 AMNOTES


+login() : BOOL{polymorphic,sequential}+getSessions() : BOOL{polymorphic,sequential}+getCandidates() : BOOL{polymorphic,sequential}+getVotes() : BOOL{polymorphic,sequential}+addCandidate() : BOOL{polymorphic,sequential}+removeCandidate() : BOOL{polymorphic,sequential}+vote() : BOOL{polymorphic,sequential}+login() : BOOL{polymorphic,sequential}+getSessions() : BOOL{polymorphic,sequential}+getCandidates() : BOOL{polymorphic,sequential}+getVotes() : BOOL{polymorphic,sequential}+addCandidate() : BOOL{polymorphic,sequential}+removeCandidate() : BOOL{polymorphic,sequential}+vote() : BOOL{polymorphic,sequential}

-gUsername[1] : String = NULL-gPassword[1] : String = NULL-gLoginSucceeded[1] : BOOL = False-Sessions[1] : String = NULL-Candidates[1] : String = NULL-Votes[1] : String = NULL

Desktop::VoteServer{documentation =

Implements the VoteServerInterface}

+login() : BOOL{polymorphic,sequential}+getSessions() : BOOL{polymorphic,sequential}+getCandidates() : BOOL{polymorphic,sequential}+getVotes() : BOOL{polymorphic,sequential}+addCandidate() : BOOL{polymorphic,sequential}+removeCandidate() : BOOL{polymorphic,sequential}+vote() : BOOL{polymorphic,sequential}

«interface»Desktop::VoteServerInterface


Desktop::Controller{documentation =


UML DIAGRAM


PAGE

3 OF 6PRINTED

5/7/2003 3:42:29 AMNOTES



ServerClient::Controller{documentation =


+login() : BOOL{polymorphic,sequential}+getSessions() : BOOL{polymorphic,sequential}+getCandidates() : BOOL{polymorphic,sequential}+getVotes() : BOOL{polymorphic,sequential}+addCandidate() : BOOL{polymorphic,sequential}+removeCandidate() : BOOL{polymorphic,sequential}+vote() : BOOL{polymorphic,sequential}

ServerClient::VoteClient

+login() : BOOL{polymorphic,sequential}+getSessions() : BOOL{polymorphic,sequential}+getCandidates() : BOOL{polymorphic,sequential}+getVotes() : BOOL{polymorphic,sequential}+addCandidate() : BOOL{polymorphic,sequential}+removeCandidate() : BOOL{polymorphic,sequential}+vote() : BOOL{polymorphic,sequential}+login() : BOOL{polymorphic,sequential}+getSessions() : BOOL{polymorphic,sequential}+getCandidates() : BOOL{polymorphic,sequential}+getVotes() : BOOL{polymorphic,sequential}+addCandidate() : BOOL{polymorphic,sequential}+removeCandidate() : BOOL{polymorphic,sequential}+vote() : BOOL{polymorphic,sequential}

-gUsername[1] : String = NULL-gPassword[1] : String = NULL-gLoginSucceeded[1] : BOOL = False-Sessions[1] : String = NULL-Candidates[1] : String = NULL-Votes[1] : String = NULL

Desktop::VoteServer{documentation =

Implements the VoteServerInterface}+login() : BOOL+getSessions() : BOOL+getCandidates() : BOOL+getVotes() : BOOL+addCandidate() : BOOL+removeCandidate() : BOOL+vote() : BOOL

«interface»Desktop::VoteServerInterface

+login() : BOOL+getSessions() : BOOL+getCandidates() : BOOL+getVotes() : BOOL+addCandidate() : BOOL+removeCandidate() : BOOL+vote() : BOOL

«interface»ServerClient::VoteClientInterface

UML DIAGRAM


PAGE

4 OF 6PRINTED

5/7/2003 3:42:29 AMNOTES


+main() : int+cli_entrypoint() : int

DistributedModel::Controller


DistributedModel::VoteClient


DistributedModel::VoteServer


«interface»DistributedModel::VoteServerInterface


«interface»DistributedModel::VoteClientInterface

RemotingClient RemotingServer-End1

*

-End2

*

RemoteServer and RemoteClientmust be implemented and initializedcorrectly.

The initialization is done by theseobjects during their creation.

RPC: RemoteServer implementsan RPC-compliant interfacethat mirrors VoteServerInterface,and loads VoteServer in memory.RemoteClient acts as a proxyto VoteServer, and internallydoes mothod calls betweenthe two interfaces.

RMI: similar to RPC case.Both RemoteClient and RemoteServermust be implemented as Remoteobjects whose sole purpose isto wire method calls.

CORBA: RemoteServer loads theVoteServer and exposes itsinterface directly to RemoteClient.RemoteClient loads VoteClientand forwards a VoteServerobjec reference to VoteClient,so VoteClient can directlycall methods on the VoteServerinterface.

Web Service: 1) If a WS-compliantinterface is explicitly needed, thenon both server and client sides, remotemethod calls will be translatedbetween two interfaces. 2) Ifa WS-compliant is implicitly needed,then on both server and client sides,interface translation will betransparent as if server/client cantalk to each other directly.

UML DIAGRAM


PAGE

5 OF 6PRINTED

5/7/2003 3:42:29 AMNOTES


Vote::RemotingClient

Vote::WSDL Reader

Vote::SOAP Reader

Vote::SOAP Writer

Vote::XML Serializer

Vote::XML Deserializer

In the case of Web Services,RemoteClient is a Web Serviceconsumer that consumes apublished Web Service.

UML DIAGRAM


PAGE

6 OF 6PRINTED

5/7/2003 3:42:29 AMNOTES


Vote::RemotingServer

Vote::SOAP Reader

Vote::SOAP Writer

WSDL Publisher

Vote::XML Deserializer

Vote::XML Serializer

UDDI Publisher

In case of Web Services,RemoteServer is an activeWeb Service that is optionallypublished on a UDDI server.

xml web services - wichita state university · xml web services page 3 of 21 part i –...

Documents