Transcription
INTERNATIONAL SCIENTIFIC CONFERENCE15 – 16 November 2019, GABROVODATA EXCHANGE USING WSO2 ENTERPRISE SERVICE BUSStefan Pitulić1, Slaviša Ilić2, Siniša Ilić1, Dragana Radosavljević11Faculty of Technical Sciences, K. Mitrovica University of Priština, Serbia2Faculty of Informatics and Computing University Singidunum, SerbiaAbstractIn this paper the advantages of using Enterprise Service Bus in data exchange using SOAP and RESTful webservices on particular examples are presented. The WSO2 open source ESB is used to connect different Web servicesdeployed on different endpoints. Also, the possibility of transformation of messages used in data exchange betweendifferent web services is demonstrated in WSO2 API.Keywords: ESB, connecting web application to ESB, connecting SOAP and RESTful to ESB.INTRODUCTIONMany applications from time to time requirethe data from external resources and fromvarious services. Usually this communication isrealised on the Intranet or Internet.Nowadays, data exchange is performedusing the Web Services, whose main objectiveis to provide a service abstraction that allowsinteroperability between applications builtusing disparate platforms and environments [1].Such architecture is known as Service OrientedArchitecture (SOA). The data is mainlyexchanged using XML message formats, andthe services are interconnected by a P2P (pointto point) connection. Complexity arises whenthere is a need to interconnect a large numberof services within some organisation (company,clusters of companies, e-government of acountry, etc.).A typical scenario is that an enterprise runshundreds or thousands of applications, whichcould be custom built, acquired from a thirdparty or parts of legacy systems [2]. Then eachservice requires one communication interfacewith another service. Sometimes it is very hardand time consuming to establish such (multiplepoint to point) connections and reconfigureactive network equipment. Also, there is aproblem how to configure connection andaccess security for each new connection nodewith the data source.The solution to this problem is to create asingle interface - a single point of access for allcommunication services and this interface isactually the Enterprise Service Bus (ESB).With the advent of the ESB there is now a wayto incorporate web services into a meaningfularchitecture for integrating applications andservices into a backbone that spans theextended enterprise in a large-scale fashion [1].In this way, all web services and applicationscan request and receive the data in a supportedmessage format, and each node (whereapplications are deployed) will be connectedvia one interface to that unique access point(ESB).All messages exchanged between theservices are transmitted via an ESB that acts asa courier. The ESB can receive messages fromone service, pack and forward them to anotherservice, and/or return a message (response) tothe sender.In a general case a set of applications in aproduction environment may be built indifferent platforms and share data in differentformats. Some applications may be parts oflarger applications that use pre-defined formatof messages and protocols, some otherapplications may use modern messages andprotocols. That is the reason why ESB isdesigned to handle many different messageformats and protocols and is able to: checkmessages, change their format, filter them,redirect them to different endpoints, processand change the content of initial messages, etc.In addition to being the main point ofmessage mediation, the ESB also providessecurity at the highest level, and it also has theInternational Scientific Conference “UNITECH 2019” – Gabrovo281
ability to log events. The ESB enables easyintegration of various services without a needfor a user to write a source code.Some of the well-known commercial ESBsolutions are: Microsoft BizTalk Server, OracleEnterprise Service Bus, IBM Integration Bus.In this paper, the implementation of the opensource solution WSO2 is presented.The main goal of this paper is to presentusage of WSO2 ESB [3] and connecting of theRESTful (Representational state transfer) andSOAP (Simple Object Access Protocol) WebServices on particular examples.SOAP AND RESTFULL WEB SERVICESSOAP is a standard protocol proposed by theW3C [4,5] to interface Web Services, and thatextends the remote procedure call (XML-RPC).Thus, SOAP can be considered as an evolutionof XML-RPC protocol, much more completeand mature, that allows to perform remoteprocedure calls to distributed routines (services)based on an XML interface as interfacinglanguage. Thus, SOAP clients can access toobjects and methods that are residing in remoteservers, using a standard mechanism that makestransparent the details of implementation, suchus the programming language of the routines,the operating system or the platform used bythe provider of the service. At the moment,there exist complete implementations of SOAPfor Perl, Java, Python, C and other languages[6].SOAP sends and receives messages usingXML [7-9], wrapped HTTP-in headings. Theinterfaces of the methods that can be accessedusing SOAP services are specified by a WebServices Description Language (WSDL) [10,11]. Using an WSDL file, that it is based on aneutral language such as XML, the service canbe specified for different languages, so that aJava client can access a Perl server.REST is a style of software architecture fordistributed hypermedia systems such as theWorld Wide Web. The term RepresentationalState Transfer was introduced and defined in2000 by Roy Fielding in his doctoraldissertation [12, 13]. Fielding is one of theprincipal authors of the Hypertext TransferProtocol (HTTP) specification versions 1.0 and1.1 [14, 15].282REST-style architectures consist of clientsand servers. Clients initiate requests to servers;servers process requests and return appropriateresponses. Requests and responses are builtaround the transfer of representations ofresources. A resource can be essentially anycoherent and meaningful concept that may beaddressed.Although REST was initially described inthe context of HTTP, is not limited to thatprotocol. RESTful architectures can be basedon other Application Layer protocols if theyalready provide a rich and uniform vocabularyfor applications based on the transfer ofmeaningful representational state. RESTfulapplications maximize the use of the preexisting, well-defined interface and other builtin capabilities provided by the chosen networkprotocol, and minimize the addition of newapplication-specific features on top of it.CREATION OF TESTINGENVIRONMENTIn order to test the usage of WSO2 ESBseveral endpoints with web services are created.Two SOAP Web Services (WS): “BibService”and “ServiceB”, each with several functions arecreated,andoneRESTfulWS(“TutorialService”) with four functions. Also,two client applications were built: one forexchanging data with SOAP WS and one forretrieving, inserting, updating and deleting datausing the RESTful web services.Initially, client applications were connectingto the WS directly in a peer to peer fashion andwere used to issue the request to an endpointdemanding the data from a WS deployed at thatendpoint. Our goal was to modify clientapplication to issue request to the ESB (not to aparticular endpoint) for a specific WS andreceive data from ESB regardless from whichendpoint data actually were coming from. Foreach WS appropriate API had to be developedand implemented in ESB in order to processrequest from a client application, create ownrequest to the particular endpoint, receive datafrom a web service and transfer those data to aclient application in desired format.For issuing the WS request (beside clientapplications we developed) we used alsoSoapUI (https://www.soapui.org/) applicationInternational Scientific Conference “UNITECH 2019” – Gabrovo
for testing requests and responses to and fromWeb Services.Creation of SOAP Web Services forexperiment 1All Web Services in the experiment werecreated using the Microsoft .Net platform. Thefirst SOAP WS “BibService” was designed toexchange data related to small library. Theservice was connected to the MS AccessDatabase and the functions of this WS were: AddBook(pWriterID, pBookTitle), GetWriterID(pWriterName), ShowAllWriters(), and ShowWritersAndBooks().The second SOAP WS “ServiceB” wasdesigned to exchange data related to BookWriters, it is also connected to (another) MSAccess database and there was only onefunction: GetNumberOfBooks(pWriterID)The initial architecture for experiment 1 ispresented in Fig. 1.Fig. 2. Request from SoapUI to the function GetWriterId of WSBibServiceIts purpose was to test aforementionedfunctions on an initial array of strings. Theinitial architecture of test environment forexperiment 2 is presented in Fig. 3Fig. 1. Initial architecture of test environment for experiment 1When implementing .Net web services,WSDL description for the developed WS canbe downloaded from the web address http://hostname/WebServiceName.asmx?WSDL. TheWSDL file can be later uploaded to the SoapUIfor proper configuring application to issuerequest to that Web Services.The request and response messages forfunction GetWriterID (using parameterpWriterName “Desanka Maksimovic”) ofWS “BibService” in SoapUI application arepresented in Fig. 2.Creation of RESTful Web Services forexperiment 2One RESTful WS [16] with four functions:POST, GET, PUT, DELETE was developedand deployed. This Web Service was notconnected to the database.Fig. 3. Initial architecture of test environment for experiment 2CONNECTING WEB SERVICES TO ESB AND APICOMPONENTSAs stated above, the WSO2 ESB(https://wso2.com/) solution was used toconnect the Web Services and create neededAPIs. WSO2 uses modified Eclipse version forbuilding the APIs and configuring endpoints.Because the ESB has to communicate withavailable Web Services, each WS has to bedefined for access within the ESB. For thispurpose, the names of WS, appropriateendpoints (Web URLs) and WDSL files had tobe defined in ESB API as well as the context ofAPI. In order to create an WSO2 API, certainobjects called mediators (the building blocks ofeach API) were used. Mediators were definedin the development environment, the number ofInternational Scientific Conference “UNITECH 2019” – Gabrovo283
them was large. The mediators used in ourexperiments were:Log mediator - the object that shows eventsfor all messages that pass through ESB WSO2API.Send mediator – the object that sends amessage to some Endpoint. For each message aMessage ID will be assigned.Property mediator - the container ofvariables. It can set or unset the value of somevariable. It can also extract some content from amessage (i.e. from XML, JSON, Envelope,etc.).PayloadFactory mediator - the object thattransforms the content of a message.Call mediator - the object that is used tosend a message outside of ESB-a to someendpoint. The response is then received back tothe working area (called Synapse) of the WSO2ESB.Respond mediator - the object that stopsthe message processing within the Synapse andsends back the message to the client as aresponse.response of the later WS would be thenreturned back to the client application.The architecture of the experiment 1 ispresented in Fig 4.In this scenario the client application issuesrequest to the ESB by sending message m1wn(Message 1 contains WriterName). The ESBprocesses the request and sends a messagem1wn (with a Writer Name received from aclient request) to the WS “BibService”;“BibService” responds and sends back themessage m1id response to the ESB thatcontains value of WriterID.Implementation of the Experiment 1(connecting SOAP Web Services to ESB)The goal of experiment 1 was to connectclient application to ESB and create request fornewfunctionGetNumberOfBooks(pWriterName) (function with the same nameof WS BibService has parameter pWriterID).The new function (created in WSO2 API)would firstly call function GetWriterID fromthe WS “BibService” and after receivingresponse (the value WriterID) would callfunction GetNumberOfBooks from the WS“ServiceB” by passing the parameter WriterIDobtained from “BibService” previously. TheThe ESB transforms received envelope inmessage m1id (extracts the WriterID value) andcall another WS “ServiceB” by sending themessage m2id request (with WriterID receivedin m1id), receives the response m2nob(Message 2 Number of Books) and passes theresponse to the client application.In Fig 5, the architecture of created API forexperiment 1 (by combining and configuringthe appropriate mediators) is presented.From Fig. 5 two sequences of objects can beseen: first group in upper part with arrowsgoing from “Resources” object and secondgroup in lower part with arrows going to“Resources” object.Fig. 4. The final architecture of SOAP services in experiment 1Fig. 5. Mediation components of API for experiment 1284International Scientific Conference “UNITECH 2019” – Gabrovo
The objects in the first group receive requestfrom a client application and send the request to“BibService” WS, and the second group receiveresponse from “BibService” WS, create requestto “ServiceB”, receive response from“ServiceB” and send response to a clientapplication.The first mediator in the first group is Logmediator requestLog that logs the request eventand passes the received SOAP envelope to theSend mediator that forwards the messagecontent to the endpoint “BibService”.In the second group of mediators, theProperty mediator WriterID extracts the valueof WriterID from “BibService” response andpasses it to the Factory mediator XMLreq thatcreates format of envelope for the Web Service“ServiceB” and function GetNumberOfBooks.The created message is then sent to the“ServiceB” endpoint via Call mediator. Theresponse message from “ServiceB” is receivedby Log mediator responseLog and sent back toa client application through the Send mediator.If error occurs, a developer may put mediatorsin the red rectangle at the bottom of Fig. 5 tohandle that error.When API is created, it should be deployedin ESB server through the ManagementConsole as Carbon application in a format ofComposite Application Project. The API calledGetNumberOfBooks is thus deployed in theManagement Console.Implementation of the Experiment 2(connecting RESTful Web Services to ESB)The goal of experiment 2 was to connectclient application with existing RESTful WebServices via ESB and receive required data inJSON format. A client application needed toexchange data with ESB instead to exchangedata with each WS deployed on specificendpoint. In this case, the ESB was configuredto return back response to a client application inJSON format by reformatting data receivedfrom RESTful WS in XML format.The desired configuration is presented inFig. 6.Fig. 6 – Desired architecture for RESTful serviceIn this scenario a client application had tosend request to the ESB (POST request by ID),the ESB had to forward request to the RESTfulWS, receive response from the RESTful WS(POST response), transform the format of dataand send back to a client application (POSTresponse).Unlike in SOAP Web Services, in RESTfulservices the context is more dynamic. There areGET, POST, and DELETE methods, so moreResource objects should be defined. In this caseonly GET method is described. The task ofGET function in “TutorialService” WS was toreturn the string from the string array atrequired position in XML format.Fig. 7. Mediation components of API for experiment 2International Scientific Conference “UNITECH 2019” – Gabrovo285
In Fig 7, the architecture of created API forexperiment 2 (by combining and configuringthe appropriate mediators) is presented.Like in SOAP API, the first group ofmediators receive request from a clientapplication and send the request to RESTfulWS, and the second group receive responsefrom RESTful WS and send response to a clientapplication.The first Property mediator (ID) extractsfrom the context of POST request the parameter-sequence number of the string in an array, andpasses request to the Log mediatorGetLogByID. Log mediator logs the requestevent and passes the received POST request tothe Send mediator that forwards the messagecontent to the endpoint GetWSRest (it isactually “TutorialService” WS). The Logmediator ResponseLog logs the response eventand passes it to the Property mediatorBodyOfEnvelope that extracts the return valuefrom the received envelope. The envelope isthen passed to the PayLoadFactory mediatorConvertToJSON, that converts envelopecontent from XML to JSON. The Log mediatorPropertyLog logs the content of the parametersin the envelope, and the created response is sentback to a client application via Respondmediator. The request and response messages toand from this API is tested via SoapUIapplication.CONCLUSIONIn modern age many applications canexchange data with another applicationsregardless of platforms they were developedand implemented using the Web Services (WS).The advantage of using WS is that data can beexchanged in a standard format (usually XMLor JSON).When the number of applications thatexchange data, becomes large, it is easier tocreate a single point of access for allcommunication services rather than to establishmultiple point to point connections. Thisbackbone interface is actually the EnterpriseService Bus (ESB).In this paper we presented a usage of WSO2,the open source ESB solution for handlingSOAP and RESTful Web Services anddemonstrated on particular examples howWSO2 can handle multiple WSs in one request286and response to a client and how WSO2 canprocess and transform response messagessuccessfully.ACKNOWLEDGMENTThis work has been supported by the Ministryof Science and Technological Development ofthe R. of Serbia under Project No.TR-35026.REFERENCE[1] Chappell D. Enterprise Service Bus O'Reilly,2004.[2] Menge F. Enterprise Service Bus, Free and opensource software conference, 2007.[3] Indrasiri K. Beginning WSO2 ESB, FirstEdition, 2016.[4] Box D, Ehnebuske D, Kakivaya G, Layman A,Mendelsohn N, Nielsen H, Thatte S, and Winer D.Simple Object Access Protocol (SOAP) 1.1, SOAP, 2019.[5] Avila P. SOAP: revolucion en la red, Linuxactual, no. 19, pp. 55–59, 2001.[6] SOAP software, available at:http://www.soaprpc.com/software , 2011.[7] Ray E. T, Learning XML: creating selfdescribing data. O Reilly, January 2001.[8] Harold E. R. XML Bible. IDG Books worldwide,1991.[9] Box D. Inside SOAP, available ex.html , 2019.[10] Ryman A. Understanding web services,available ent4362?OpenDocument&p 1&BCT 1&Footer 1, 2011.[11] Vasudevan V. A web services primer, bservices/index.html , 2011.[12] Fielding R. Architectural Styles and the Designof Network-based Software Architectures, Doctoraldissertation, University of California, Irvine, 2000.[13] Fielding and Taylor R. Principled Design ofthe Modern Web Architecture, ACM Transactionson Internet Technology (TOIT) (New York:Association for Computing Machinery) 2 (2): 115150, f.org/html/rfc1945 , 2019.[15] HTTP/1.1, RFC 2616, available at:http://tools.ietf.org/html/rfc2616 , ru99.com/restful-webservices.html, 2019.International Scientific Conference “UNITECH 2019” – Gabrovo
solutions are: Microsoft BizTalk Server, Oracle Enterprise Service Bus, IBM Integration Bus. In this paper, the implementation of the open-source solution WSO2 is presented. The main goal of this paper is to present usage of WSO2 ESB [3] and connecting of the RESTful (Representational state transfer) and SOAP (Simple Object Access Protocol) Web
