1 / 14

Engineering Web Based Legacy Systems

Engineering Web Based Legacy Systems. Distributed Computing – CS843. By Kanchana Eramudugoda. Content. What is a Legacy System? Typical Problems Associated with it Standards for Service Web Migrating to Web-based Migrating Components in to Network Environment.

Télécharger la présentation

Engineering Web Based Legacy Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Engineering Web Based Legacy Systems Distributed Computing – CS843 By Kanchana Eramudugoda

  2. Content • What is a Legacy System? • Typical Problems Associated with it • Standards for Service Web • Migrating to Web-based • Migrating Components in to Network Environment

  3. What is a Legacy System? "A computer system or application program which continues to be used because of the prohibitive cost of replacing or redesigning it and despite its poor competitiveness and compatibility with modern equivalents." Examples : IBM AS/400 IBM Mainframe Tandem

  4. Problems Associated with Legacy Systems • They are very difficult and may not easy to expand • It typically runs on absolute hardware, which is expensive and hard to maintain • Maintaining the software is expensive; Due to lack of documentation and lack of understanding of the internal working of the system, tracing can be costly and time consuming

  5. Standards For Service Web (SOAP, WSDL,UDDI) • Simple Object Access Protocol - SOAP • is an XML based messaging protocol. It usually used for exchanging information and Remote Procedure Call over HTTP(not necessary) • SOAP consists of 4 parts • 1. SOAP Envelope – defines the content of the message • 2. SOAP Encoding rules – defines the serialization mechanism • 3. SOAP RPC Representation – How to make calls and responses • 4. Protocol Binding – HTTP, SMTP

  6. Some sample Skeleton of SOAP <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... </soap:Header> <soap:Body> ... ... <soap:Fault> ... ... </soap:Fault> </soap:Body> </soap:Envelope> • Few Things to Consider When Writing a SOAP • Message MUST be encoded using XML • Message MUST use the SOAP Envelope namespace • Message MUST use the SOAP Encoding namespace • Message must NOT contain a Document Type Definition (DTD) reference • Message must NOT contain XML Processing Instructions

  7. Web Services Description Language - WSDL • is a XML language for describing web services as a set of endpoints (ports) of message exchange. Each endpoint consists of, Definitions of operations , messages, binding protocol and message format. • WSDL is a document written in XML. The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes. • A WSDL service definition applies several layers of abstraction. There are six layers: 1.Data types that the service operates on 2. Message types the service can receive/send 3. How these messages combine into operations 4. What protocols the service will bind to 5.WSDL ports (operation + protocol) 6. A service on a given port

  8. Main Structure of the WSDL Document Sample Code <definitions> <types> ….. definition of types........ (The data types used by the web service ) </types> <message> …. definition of a message.… (The messages used by the web service ) < /message> <portType> …. definition of a port...... (The operations performed by the web service – just like a module or class ) </portType> <binding> ….. definition of a binding.... (The communication protocols used by the web service ) </binding> </definitions> message name="getTermRequest"> <part name="term" type="xs:string"/> </message> <message name="getTermResponse"> <part name="value" type="xs:string"/> </message> <portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation></portType>

  9. Universal Description, Discovery, and Integration - UDDI • is the building block that businesses can use to quickly, easily, and dynamically find and transact with each another, using their preferred applications. • UDDI functions include: • Service Provider • Provides and publishes e-business web services • Service Registry • SOAP-activated web service yellow pages • Service Requester • Finds required services and binds client to those services

  10. Migrating Components in to Network Environment • Representation of data/interface using XML • XML Representation of Component Interface <?xml version="1.0"?> <Config Package=”AVL”> <Component name=”AVL” href=http://www.swen.uwaterloo.ca/BookStock> <typedef> <srcType name=”char”/> <targetType name=”ubi_trBool”/> </typedef> <Interface name=”SampleRec” srcClass=”SampleRec”> <Operation> <Return type=”void”/> <OpName name=”putName” srcMethod=”putName”/> <Params> <Param name=”val” dir=”in” type=”char*”/> </Params> </Operation/> <Operation> <Return type=”char*”/> <OpName name=”getNameString” srcMethod=”getName”/> <Params> <Param name=”i” dir=”in” type=”int”/> </Params> CORBA IDL module AVL{ iinterface corba_SampleRec; typedef char corba_ubi_trBool; interface corba_SampleRec{ void putName(in string val); string getName(); void putNode(in corba_ubi_btNode val); corba_ubi_btNode getNode(); long getDataCount(); void putDataCount(in long aval); };

  11. Web Clients HTTP/SOAP Web Server HTTP GET/POST Application Server Servlet Engine SOAP runtime SOAP/CORBA IDL Translator CORBA Server CORBA Components • Wrapping CORBA objects with SOAP • Enabling of access to CORBA objects with out installing the ORB runtime capability on the clients side, thin client s or lightweight clients, is much harder. Therefore to make it easy SOAP protocol is used as a messenger between CORBA objects and the web services. Process the HTTP/GET or POST requests Interpretation and Dispatching of messages It is a Collection of Java Beans; Encapsulate all the services including serialization and de-serialization

  12. struct EchoData {       long     aLong;       boolean  aBool;       string   aString;   };    EchoData getData( in long l, in boolean b, in string s) SOAP interface XML with the corresponding CORBA IDL definitions. <esd:CType name="EchoData">  <esd:item name="aLong" type="xsd:int" builtin="true" array="false" inout="false"/>  <esd:item name="aBool" type="xsd:boolean" builtin="true" array="false" inout="false"/>  <esd:item name="aString" type="xsd:string" builtin="true" array="false" inout="false"/> </esd:CType>  <esd:Method name="getData">   <esd:InParam name="GetDataRequest">     <esd:item name="l" type="xsd:int"     builtin="true" array="false" inout="false"/>     <esd:item name="b" type="xsd:boolean" builtin="true" array="false" inout="false"/>     <esd:item name="s" type="xsd:string"  builtin="true" array="false" inout="false"/>   </esd:InParam>   <esd:OutParam name="GetDataResponse">    <esd:item name="return" type="typens:EchoData" builtin="false" array="false" inout="false"/>   </esd:OutParam> </esd:Method>

  13. Conclusion • It is beneficial to engineering web based legacy system. Because • Allows the company to take advantage of the latest technologies available • Web-based applications and services promise more flexible, efficient and cost-effective operationsthan the legacy systems that are showing signs of age and years of patching and fixing.

  14. Questions ?

More Related