Web Services Architecture

We canunderstand without difficulty why Web Services are produced if we lookat the computer and software worlds. There are many systems andplatforms out there on the Internet and there are even moreapplications that living on these systems and platforms. If we needmore explanation about this, there are many technologies out there toconnect clients to servers, including DCOM, CORBA and others and WebServices growing on a new and much simpler type of connectivity, basedon open standards such as HTTP, XML and SOAP.

Simply,we can imagine, Web Services a component whose methods you can invokeusing an internet or intranet connection or a Web Service is acomponent that exposes its interface via Web. Web Services build on therecognition of XML in the open arena. Web Services use XML as the wayfor serializing data to receive from, or return to the client. A clientthat can parse XML can use the data returned, even the client and theWeb Service host are using the different operating system, or theapplications are developed with the different programming language. Wewill discuss on Web Services more lately in this article. Let us lookto full story.

WebServices are not necessarily will replace component development;components make a lot of sense in an intranet solution where theenvironment is controlled, and it does not make sense to escape purelyinternal objects through a less efficient web service interface. WebServices make interoperating easy and effective, but they are not asfast as a binary proprietary protocol such as DCOM. The problem withcomponents was facing when distributing them across the Internet. Inthis article, I assume that you have the knowledge of distributedcomponent technology and basic knowledge of middle-tier programming.

A Short History to <st1:city><st1:place>Enterprise</st1:place></st1:city> Programming Model

Theenterprise environment in which present companies now find themselveshas undergone major change over the last few decades. As USA and globalmarkets have opened up, so war has start, and in order to survive,companies have to make better and improved use of the tools at theirarea. In the early days of software world in the workplace,applications were confined to single computers, greatly limiting theproblem domain that they could operate in. Many early desktop solutionsrelied on local copies of the company?s databases being stored on eachcomputer, where they would be accessed and manipulated separately.

As thetechnology improved, and applications became more sophisticated,solutions to this arrangement started to appear based on an onlinecentral database accessed over a network. Often, the workload ofperforming the tasks requested by users is shared between the desktopmachines and the servers. This model knowing as distributed computing.

Manyrecent enterprise solutions cover several distributed applications,where the workload is shared between client and server according to theenvironment of the task and the power of the client machine. Theseapplications, running on fast local networks, are prepared to beextended to provide access through the Internet. The Client-Server termis a little primitive for the networked systems establish in today?sworld of business, but the principal notion of a separation betweenclient and server is still applicable. Many such applications can stillbe thought of as client-server, although their original model is moresophisticated, such as the n-tier arrangement.

<st1:city><st1:place>Enterprise</st1:place></st1:city> Application Integration Architecture

EAIbuilds on proven middleware techniques such as message brokering anddata transformation, and introduces architectural components calledadapters for communication with applications and other data sources.EAI also incorporates business process modeling and workflow, metadatamanagement, security and system administration, and monitoring. Workingin concert, this set of services provides a robust environment forintegrating disparate applications within and across enterprises.

 <st1:city><st1:place>Enterprise</st1:place></st1:city> Distributed Computing

Insteadof running on a single computer, large-scale systems execute on anumber of different machines. One simple reason is to distributeprocessing. Other reasons for distributing functionality amongdifferent physical machines include the ability to separateuser-interface functionality from business logic, increase systemrobustness, and add security features. By separating user-interfacefunctionality from business logic, you can more easily partitionuser-interface development from business logic. This makes developmentand management of the code much easier. Once you have developed yourbusiness logic, you can reuse it later. For example, two differentuser-interface applications can make use of the same business logicwithout changes to the business-logic code.

Robustnessis another important reason for separating the user interface from theback-end business logic. In a client/server application, the server mayservice hundred clients. If one of these clients causes a generalprotection fault, it should not affect the execution of the server orthe other ninety-nine clients. In addition, when you split up userinterface, business, and data logic, you may add security features toyour system. For instance, your server can provide securityfunctionality that authenticates the client each time it connects tothe server. You can even add security logic to authorize everysubsequent request that the authenticated client sends. These reasonsmake distributed computing very elegant.

Thereare very benefits to this model, as we have seen from the substantialincrease in internet companies and internet/intranet applications inthe last few years.

Component Technology

Allthese mean, that the distributed computing uprising was taking place,importance of component technology was also rising. The idea supportsthis technology was interface based programming. A component wouldpublish a particular interface that could be used to interact with it.This interface was a contract that was guaranteed to remain in place.Other developers could, develop using these interfaces; confident thatfuture changes to the component would not break their code.

Thecomponent interfaces were in a binary standard, giving developers thechoice to use different programming languages for the component and theclient. COM/DCOM and CORBA have done very well in this arena.

="smallb
lack">On theother hand, Web Services are not necessarily going to replace componentdevelopment. Components make a lot of sense in an intranet solutionwhere the environment is controlled, and it does not make sense toexpose purely internal objects through a less efficient web serviceinterface. Web Services make interoperating easy and effective, butthey are not as fast as a binary proprietary protocol such as DCOM.

Distributedobject computing extends an object-oriented programming system byallowing objects to be distributed across a heterogeneous network, sothat each of these distributed object components interoperate as aunified total. These objects may be distributed on different computersthroughout a network, living within their own address space outside ofan application, and yet appear as though they were local to anapplication. <o:p></o:p>

Three of the most popular distributed object paradigms are Microsoft's Distributed Component Object Model (DCOM), OMG's Common Object Request Broker Architecture (CORBA) and JavaSoft's Java/Remote Method Invocation (Java/RMI).Now we will have some more information about COM/DCOM, COM+ and CORBAfor clean understand component and distributed programming techniques.

COM/DCOM, COM+

Component-baseddevelopment has become the software concept, with its own conferences,magazines, and consultants. However, the original component technology,and the one that is by far the most widely used, is Microsoft'sComponent Object Model (COM). Introduced in 1993, COM is now a maturefoundation for component-based development, and it is the rareapplication for Windows and Windows NT that does not use COM in someway. With its integrated services, and its excellent tool support fromMicrosoft and others, COM makes it easy to develop powerfulcomponent-based applications.

Fromits original application on a single machine, COM has expanded to allowaccess to components on other systems. Distributed COM (DCOM),introduced in 1996, makes it possible to create networked applicationsbuilt from components. Available on various versions of UNIX, IBMmainframes, and other systems, DCOM is used today in applicationsranging from innovative medical technology to traditional accountingand human resources systems. Once a bleeding edge technology,distributed components have gone mainstream, and the primarytechnologies enabling this are COM and DCOM.

A COM server can create object instances of multiple object classes. A COM object can support multiple interfaces,each representing a different view or behavior of the object. Aninterface consists of a set of functionally related methods. A COMclient interacts with a COM object by acquiring a pointer to one of theobject's interfaces and invoking methods through that pointer, as ifthe object resides in the client's address space. COM specifies thatany interface must follow a standard memory layout, which is the sameas the C++ virtual function table. Since the specification is at thebinary level, it allows integration of binary components possiblywritten in different programming languages such as C++, Java and VisualBasic. <o:p></o:p>

Theevolution of Microsoft component services continues with COM+. Byenhancing and extending existing services, COM+ further increases thevalue these services provide. COM+ includes: <o:p></o:p>

?         A publish and subscribe service- Provides a general event mechanism that allows multiple clients to"subscribe" to various "published" events. When the publisher fires anevent, the COM+ Events system iterates through the subscriptiondatabase and notifies all subscribers. <o:p></o:p>

?         Queued components- Allows clients to invoke methods on COM components using anasynchronous model. Such as model is particularly useful in onunreliable networks and in disconnected usage scenarios. <o:p></o:p>

?         Dynamic Load balancing – Automatically spreads client requests across multiple equivalent COM components. <o:p></o:p>

?         Full integration of MTS into COM- Includes broader support for attribute-based programming,improvements in existing services such as Transactions, Security andAdministration, as well as improved interoperability with othertransaction environments through support for the Transaction InternetProtocol (TIP). <o:p></o:p>

COM+builds on what already exists?it is not a revolutionary departure.Microsoft component services provide an infrastructure for buildingenterprise applications, and enterprises seldom welcome revolutions intheir infrastructure. However, software technology cannot stand still.The goal, then, must be to provide useful innovations that make iteasier to create great applications without disrupting what is alreadyin place. By extending and further unifying the existing componentservices, COM+ does exactly this.<o:p></o:p>

Takenas a whole, Microsoft component services provide a powerful, flexible,and easy-to-use platform for building distributed applications. Nothingelse available offers the same level of integration, broad toolsupport, and solid services.

CORBA

Youmay read this on several CORBA articles; CORBA is a distributed objectframework proposed by a consortium of hunderds companies called theObject Management Group (OMG). The core of the CORBA architecture isthe Object Request Broker (ORB) tha

t acts as theobject bus over which objects transparently interact with other objectslocated locally or remotely. A CORBA object is represented to theoutside world by an interface with a set of methods. A particularinstance of an object is identified by an object reference. The clientof a CORBA object acquires its object reference and uses it as a handleto make method calls, as if the object is located in the client'saddress space. The ORB is responsible for all the mechanisms requiredto find the object's implementation, prepare it to receive the request,communicate the request to it, and carry the reply if any back to theclient. The object implementation interacts with the ORB through eitheran Object Adapter (OA) or through the ORB interface. <o:p></o:p>

?         CORBA objects can be located anywhere on a network.

?         CORBA objects can interoperate with objects written on other platforms.

?         CORBA objects can be written in any programming language for which there is a mapping from IDL to that language.

Developersuse CORBA to distribute applications across client-server,peer-to-peer, 3-tier, n-tier, Internet/Intranet etc. networks. Insteadof having hundreds of thousands of lines of code running on mainframecomputers with dumb terminals, smaller, more robust applications thatcommunicate between file servers and workstations are now necessary. Tokeep this distribution of applications simple, a plug-and- playarchitecture is necessary to distribute the client-server (CS)applications. Although the computing trend seems to be towardsthe peer-to-peer computing. The developer then can write apps that workindependently across various platforms and diverse networks. The idea behind CORBA is a software intermediary that handles and disperses access requests on data sets. This intermediary is referred to as an Object Request Broker (ORB).The ORB interacts and makes requests to differing objects. It sits onthe host between the data and the application layer (that is, one levellower than the application layer (level 7 in the OSI model). An ORBnegotiates between request messages from objects or object servers andthe affiliated data sets.

Limitation of DCOM and CORBA

Perhaps,we can talk about all other distributed object technologies such asSun?s RMI (Remote Method Invocation) protocol. However, this article?sobjective is not talk all detail about existing technologies.Therefore, we choose two strongest alternatives to discuss what theproblem on existing gear was. In that case, let us talk about why weneed a new technology. Unfortunately, existing technologies have somecruel limitations that have dissatisfied or at least more complex,several existing projects.

Thebiggest problem about DCOM and CORBA were both are platform specific.Both were not easy integrating with each other. You may create a kindof bridge that process translates messages from one to other. However,this system already has some difficulty because of DCOM and CORBAfunctionality, data types etc. An important key barrier iscommunication over the Internet. The distributed communicationtechnologies described earlier have a symmetrical requirement, meaningthat both ends of the communication link would typically need to haveimplemented the same distributed object model. In Internet, nobody canpromise that both ends of the communication link will have implementedthe same distributed object model. Promising this on the Internet isrisky and normally just impossible.

Anotherissue about limitation is Firewalls and Proxy servers. DCOM and CORBAare not firewall and proxy friendly. Both architectures typically forcethem to listen to port numbers, which this is may not be withoutproblems or usually known. The challenge with proxy servers is thatclients using these protocols typically require having a directconnection to the server. In general, firewalls does not givingpermission (in case of security) keeps open many ports, except someusually used ones. For instance, these ports are HTTP and SMTP.

Furthermore,as CORBA and DCOM are respectable protocols, the business world has notyet moved completely to one in exacting. All sides pointing out theother?s shortcoming mark the lack of worldwide commerce recognition.With other words, some models, for example DCOM, CORBA as well as RMIfor Java, work very well in an intranet environment. These technologiesprovide components to be invoked over network connections, as a result,make possible distributed application development. In a pureenvironment each of these works well, but interoperating with the otherprotocols, none is very successful. For example, using DCOM, Javacomponents cannot be called, and COM objects cannot be invoked usingRMI. Attempting to use these technologies over the Internet presentseven more difficulty. Firewalls often block access to the requiredTCP/IP ports, and because they are proprietary formats both the clientand server must be running compatible software.

An Architectural Overview to Web Services

Althoughthis time we talked about several issues about Web Services also talkedabout is the Web Services shortly. One of the most important rewards ofthe XML Web services architecture is that it allows programs developedin different programming languages on different platforms tocommunicate with each other in a standards-based technique. There aretwo different methods to work with Web Services; to allow access tointernal system functionality, exposing them to the outside world andas a client, or consumer of external Web Services. In this model, WebServices are used to access functionality from any tier in anapplication. This provides the possible of any distributed systemexposed on the Internet to be incorporated into a custom application.

Ingeneral, the architecture of a Web Service divided into five logicallayers such as Data Layer, Data Access Layer, Business Layer, BusinessFa?ade and Listener. The Listener is nearest to client, and the layerfurthest from the client is the data layer. The business layer isfurther divided in to two sub layers named Business logic and

Businessfa?ade (this mean is an elevation at front side). Any physical datathat the Web Service requires is stored in the data layer. Above thedata layer is the data access layer, which presents a logical vision ofthe physical data to the business logic. The data access layer isolatesbusiness logic from changes to the underlying data stores and ensuresthe integrity of the data. The business fa?ade provides a simpleinterface, which maps directly to operations exposed by the WebService.

Businessfacade block is constantly used to provide a dependable interface tothe underlying business objects and to isolate the client from changesto the underlying business logic. When it is present, it liveswhichever involving the client and the business logic or involving theWeb service projects and the business logic layers.

Thebusiness logic layer provides services for the business fa?ade?s use.All the business logic might be implemented by the business fa?ade in asimple Web Service, which would interact directly with the data accesslayer. Web Service client applications interact with the Web Servicelistener. The listener is responsible for receiving incoming messages,which contain requests for services, parsing the messages, anddispatching the requests to the appropriate methods in the businessfa?ade.

This architecture is very similar to the n-tierapplication architecture defined by Windows DNA. The Web Servicelistener is equivalent to the presentation layer of a Windows DNAapplication. The listener is responsible for packaging the responsefrom the business fa?ade into a message and sending that back to theclient, if the service returns a response. The listener also handlesrequests for Web Service contracts and other documents about the WebService. By adding a Web Service listener parallel to the presentationlayer and providing it the access to the existing business fa?ade, itis easy to migrate a Windows DNA application to a Web Service. Whileweb browser clients can continue to use the presentation layer webService client applications will interact with the listener. 

<o:p> </o:p>

Web Services Stack

We canstart to talk with HTTP (HyperText Transfer Protocol); with thiscommunication protocol, it is possible to send information from onepoint on the Internet to another point. The information that is sentover the wire can be structured by using XML (eXtensible MarkupLanguage). The XML protocol defines the format and the semantics of theinformation. XML is a fundamental foundation for the later layers. SOAP(Simple Object Access Protocol) is a protocol that defines how toinvoke function calls from objects that live in different environments.

Duringusing SOAP, it is possible to defeat problems that are move up whentrying to integrate different operating systems, object models, andprogramming languages. With SOAP, it turns into possible for the firsttime to easily integrate different category of business processes.

HTTP,XML, and SOAP can be seen as the core layers for Web Services. Theselayers define how Web Services have to interact with each other. Thesethree protocols have been accepted by the W3C (World Wide WebConsortium, http://www.w3.org/) as standards.

Theprotocol WSDL (Web Services Description Language) describes how tocommunicate with a Web Service. In the WSDL definition, different typesof communication (bindings) are allowed. Its one thing to havedeveloped a Web Service, but it is another to earn money with it aswell. In order to do this, we need a central market place where we canpublish our Web Service, so other parties can find it and use it. Thisis where UDDI (Universal Description, Discovery and Integration) comesin.

WebServices technology can be generally classified into three keyassemblies, Description Stack, Discovery Stack and Wire Stack. Thedescription stack deals with a wide range of technologies that describeWeb Services in order to facilitate their common use for businessprocess modeling and workflow composition in B2B relationships. Thediscovery stack deals with technologies that allow for directory,discovery, and inspection services. The wire stack consists oftechnologies that provide the steam for the runtime engines of WebServices.

Building Blocks

Let usstart like this; Web Services are building blocks for constructingdistributed Web-based applications in a platform, object model, andMultilanguage manner. Web Services are based on open Internetstandards, such as HTTP and XML, and form the basis of Microsoft'svision of the programmable Web. What are the ?Building Blocks? SOAP,WSDL and UDDI.

SOAP

Let?s, we will put general information over SOAP as a fundamental building block of Web Services.

SOAP isa standard way of serializing that the information needed to invokeservices located on remote systems as a result, which the informationcan be sent over a network to the remote system in a format the remotesystem can understand, regardless of what platform the remote serviceruns on or what language it is written in. Fundamentally, SOAP is anXML-based protocol that is designed to exchange structured and typedinformation on the Web. SOAP can be used in combination with a varietyof existing Internet protocols and formats including HTTP, SMTP, andMIME and can support a wide range of applications from messagingsystems to RPC.

SOAPaddresses the issue of passing information to and from remoteapplications through firewalls.  Firewalls, as the paper points out,often prohibit remote communication through ports other than somepredefined, well-known ports, reserved for a specific purpose.  Thisbecomes an issue as most distributed protocols do not use assignedports, but dynamically select them.  The solution, as implemented byMicrosoft's SOAP technology, is to pass a call to a remote processthrough port 80, the port assigned for HTTP traffic.  The remote callsare attached on top of the HTTP protocol using XML to define the formatof the request or response messages. Among the advantages of thistechnology is clearly the ease at which firewall complications can beavoided.  Cross platform compatibility also comes to mind, althoughthis wasn't discussed beyond a passing comment in the article.  Adrawback might be in some inefficiency as port 80 is a commonly usedport used for all web traffic through the server.<o:p></o:p>

SOAPhas been developed to solve an aging problem with developingapplications for the Internet: interoperability. Imagine a world whereyou can access objects and services on remo

te (or local) servers in aplatform-independent manner. Today?s world is infected with differentoperating systems, different firewalls, different methods of makingremote procedure calls, and different platforms. In order tointeroperate across the Internet both the client and server need tounderstand each others security types and trusts, service deploymentschemas, and implementation details, not to mention speak the sameplatform language (e.g. COM to COM, ORB to ORB, EJB to EJB, etc.).  WithSOAP, an end to all of this platform-specific confusion has arrived.Based on the already industry wide accepted IETF HTTP standard and W3CXML standard, SOAP bridges the opening between competing object RPCtechnologies and provides a light-weight messaging format that workswith any operating system, any programming language, and any platform.

There are three main parts in the SOAP architecture.<o:p></o:p>

?         An envelope that describes the contents of a message and how to process it.

?         A set of encoding rules for expressing instances of application-defined datatypes.

?         A convention for representing remote procedure calls and responses.

<o:p> </o:p>

Simplydeclared, SOAP provides a technique to access services, objects, andservers in a completely platform-independent mode. By SOAP, you willcapable of query, invoke, communicate with, and otherwise handleservices provided on remote systems without regard to the remotesystem?s location, operating system, or platform.

SOAP byitself provides a way to exchange messages with Web Services, but itdoes not provide a way to find out what messages a Web Service mightwant to exchange. It also, does not give you any way of finding WebServices or negotiating with them. <o:p></o:p>

WSDL<o:p></o:p>

The WebServices Description Language (WSDL) along with SOAP, form theessential building blocks for Web Services. WSDL is an XML-based formatfor describing Web Services. It describes which operations Web Servicescan execute and the format of the messages Web Services can send andreceive. A WSDL document can be consideration of as a contract betweena client and a server. With WSDL-aware tools, you can also automatethis process, enabling applications to simply integrate new serviceswith little or no manual code. WSDL therefore represents a cornerstoneof the web service architecture, because it provides a common languagefor describing services and a platform for automatically integratingthose services.

Whilemost WSDL documents are used in RPC-style request/response pairs, WSDLas well supports one-way messages. WSDL supports the same four types ofoperations that SOAP messages accomplish that request-response,solicit-response, one-way, and notification.

UDDI

UDDI (Universal Description, Discovery, and Integration) is the building block that will enable businesses to quickly, easily and dynamically find and transact businesswith one another using their preferred applications. With differentway, UDDI is an XML-based registry for businesses worldwide to listthem on the Internet. Its ultimate goal is to streamline onlinetransactions by enabling companies to find one another on the Web andmake their systems interoperable for e-commerce. UDDI is often comparedto a telephone book's white, yellow, and green pages. The projectallows businesses to list themselves by name, product, location, or theWeb services they offer. <o:p></o:p>

TheUDDI focus is on providing large organizations the means to reach outto and manage their network of smaller business customers. The biggestissues facing UDDI are ones of acceptance and buy-in from businessesthemselves, and implementation issues of scalability and physicalimplementation.

TheUDDI Consortium, established by hundreds of companies, emerged inresponse to a series of challenges posed by the new Web Services model.These challenges included the how do you discover Web Services, howshould information about Web Services be categorized. These challengesalso included how do you handle the global nature of Web Services, howdo you provide for localization and how can interoperability beprovided, both in the discovery and invocation mechanisms. In addition,it included how you could interact with the discovery and invocationmechanisms at runtime.

Infavor of UDDI to provide the foundation for Web Services registries,therefore, it had to serve two primary roles within the Web Servicesmodel such as Service publication and service discovery.

Describing Web Services

We justtalk about WSDL, now we will discuss describing Web Services as anintroduction. We will not go deeply issues in this article, becausethis article already considering you have minimum more than beginnerinformation.

DescribingWeb Services needs a language such as WSDL. Since SOAP?s conception,the designers planned for it to support a type system the one theychose was XML Schema. The SOAP specification enables you to describetype information in one of two manners. The first way relies on the useof the xsi: type attribute within your SOAP messages. In this manner,each message can be self-describing so that the receiving endunderstands how to interpret the message parameters and theirassociated types.

Thesecond manner enables the sender and receive

r to rely on some from ofschema to be referenced from an external but unspecified source. Inthis manner, the sender and the receiver are interacting based on awell-defined contract of types.

An XMLschema alone does not inform all the information that we needconcerning a Web Services. However, SOAP serialization is troubled, andXML schema datatype is sufficient. On the other hand, other feature toWeb Services need to be addressed therefore, WSDL was created.

WSDL isan XML language, which uses several layers of abstraction to describeWeb Services in a modular technique. Furthermore, WSDL has a vocabularythat enables us to create independent datatype definitions, abstractmessage definitions, and service definitions. After they are defined,the abstractions can be bund to concrete message formats, transportprotocols, and endpoints to complete the overall package.

Essentially,WSDL defines an XML grammar that describes Web Services as collectionsof communications endpoints that are able to exchange messages witheach other. However, the Microsoft implementation requires another fileto map the invoked Web Service operations to COM object method calls.This additional file is expressed in the Web Services Markup Language(WSML), which is Microsoft?s proprietary language for this particularpurpose. Besides, the Microsoft SOAP Toolkit generates WSML filesautomatically.

Publishing Web Services

Whatdoes mean publishing Web Services? UDDI uses WSDL as a descriptionlanguage. WSDL documents can be organized as service implementation andservice interface documents. The service implementation document mapsto the UDDI businessService element, while the service interfacedocument maps to the tModel elements. The first step in publishing aWSDL description in a UDDI registry is publishing the service interfaceas a tModel in registry.                                   <o:p></o:p>

TheUDDI registry is not only run by Microsoft also IBM and Ariba are alsocontrolling repositories. This means that if we post information withone, then it is replicated on all databases held by those companies.Each of the independent repositories have the same interface to giveany outside organization or individual the opportunity to postinformation to UDDI using the UDDI Publish Web Service and search UDDIusing the UDDI Inquire Web Service.

Oncethe tModel has been published, businesses that wish to provide servicesas defined in the tModel implement Web Services based on the WSDLdefinition. These services are accessible through a URL, and businessesthen publish this information in the UDDI registry ? the service URL iscontained in the Binding Template of the service that the businesspublishes.

ThePublishing allows several activities such as registration of newbusiness and services, deletion of existing services of businesses andmanagement of security on the business data. The Publisher API isintended for software programmers or Independent Software Vendors whowould like to publish their web services to a UDDI node.

UDDIdata structure has two functions that they named save and delete. Thesefunctions from the Publication API that allows the user to modifyexisting entries in the registry and create new ones by using the savefunctions. The delete functions completely remove the given datastructure. This API is used primarily as a means of creating andupdating business and service information that the end user isauthorized to modify.

Althoughthe UDDI registry allows you to access all the functionally ofpublishing and finding services programmatically through XML and SOAP,IBM and Microsoft supply a Web Interface as well so that you can accessall this functionality from a Web browser.

Thisarticle only intends to give you a sophisticated overview of WebServices, WSDL, UDDI and related objects to help you to understandfuture articles. You learned how to work a Web Service. You alsoreceived a high-level overview of Web Services Architecture. On theother hand, you had some introduce information about describing andpublishing Web Services.