Docstoc

PROBLEM STATEMENT

Document Sample
PROBLEM STATEMENT Powered By Docstoc
					 A Cross-Platform Component Based
 Ecommerce Framework in .NET

                       Vishwak Rajgopalan


Under the guidance of


Dr. Daniel Andresen (Major Professor)
Dr. Mitchell Neilsen
Dr. Gurdip Singh
Overview
   Problem Statement
   Solution
   Advantages of cross-platform business components
   Role of web services in cross-platform integration
   Web Services concepts
   System Overview
   System Architecture
   System Implementation
   Performance Evaluation
   Lessons Learnt
   Conclusion
   Future Work
Problem Statement

 Integrating homogeneous components
  routine, relatively smooth

 Integrating cross-platform components
  The Real Challenge?
Solution
Develop an architecture that

 is based on open standards

 is platform and language independent

 emphasizes on a mode of communication understandable to both
  systems
Advantages

 Reduces software development lifecycle

 Eliminates time spent in testing and debugging the
  application

 Decreases “Time-to-Market” aspect of the web application
Why Web Services ?

 XML based lightweight middleware infrastructure

 Based on open standards – SOAP, UDDI, WSDL

 Systems that understand HTTP are capable of exposing and
  consuming web services
Web Services Based Architecture


 Web Services are the middleware that integrate heterogeneous
  systems over internet/intranets
 Web Services Buzzwords

 SOAP (Simple Object Access Protocol)
    - protocol for transmitting and receiving XML messages over HTTP

 WSDL (Web Services Description Language)
   - describes the interface of a Web Service in a standardized way


 UDDI (Universal Description, Discovery and Integration)
    - provides a worldwide registry of web services for advertisement,
   discovery, and integration purposes
SOAP


 Simple Object Access Protocol

 Provides a standard packaging structure for transporting XML
  documents over HTTP, FTP and SMTP.

 Defines encoding and binding standards for encoding non-XML
  RPC invocations in XML for transport

 Provides a standard transport mechanism that allows
  heterogeneous clients to interoperate
SOAP Message Structure
Sample SOAP Message

      <soap:Envelope>

      <soap:Header>
       …………………………………………….
      </soap:Header>

        <soap:Body>
           <w:GetSecretIdentity
               xmlns:w="http://www.wrox.com/heroes/">
              <w:codename>XSLT-Man</w:codename>
           </w:GetSecretIdentity>
         </soap:Body>

      </soap:Envelope>
WSDL


 Web Services Description Language

 standardizes how a web service represents the input
  and output parameters of an invocation, the function’s
  structure, the nature of the invocation

 allows disparate clients to understand how to interact
  with a web service
WSDL Sample
<?xml version="1.0" encoding="utf-8" ?>
<definitions>
<types>                                                                                      Describes the custom or complex datatypes
<s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
<s:element name="ValidateCardNumber">
<s:complexType>
<s:sequence>
 <s:element minOccurs="0" maxOccurs="1" name="cardNumber" type="s:string" />
 </s:sequence>
 </s:complexType>
 </s:element>
<s:element name="ValidateCardNumberResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="ValidateCardNumberResult" type="s:boolean" />                number and type of return values
 </s:sequence>
 </s:complexType>
 </s:element>
 </s:schema>
 </types>
<message name="ValidateCardNumberSoapIn">
          <part name="parameters" element="s0:ValidateCardNumber" />
 </message>
<message name="ValidateCardNumberSoapOut">                                                          names of the input amd output SOAP
                                                                                                    messages
<part name="parameters" element="s0:ValidateCardNumberResponse" />
</message>
WSDL Sample (contd .. )
<portType name="Service1Soap">
<operation name="ValidateCardNumber">
 <input message="s0:ValidateCardNumberSoapIn" />
 <output message="s0:ValidateCardNumberSoapOut" />
 </operation>
 </portType>
<binding name="Service1Soap" type="s0:Service1Soap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
   <operation name="ValidateCardNumber">
      <soap:operation soapAction=http://tempuri.org/ValidateCardNumber
              style="document" />
           <input>
                  <soap:body use="literal" />                                                describes the style,
          </input>                                                                           encoding, and
          <output>                                                                           transport medium
           <soap:body use="literal" />                                                       of the SOAP
         </output>                                                                           messages
 </operation>
 </binding>
<service name="Service1">
<port name="Service1Soap" binding="s0:Service1Soap">
 <soap:address location="http://localhost:7070/BooksOnline/Service1.asmx" />         entry point to the
 </port>                                                                             web service
 </service>
 </definitions>
UDDI


 Universal Discovery, Description and Integration

 standardized method for publishing and discovering
  information about web services

 open framework for describing services, discovering
  businesses, and integrating business services

 focuses on the process of discovery
Web Service Invocation
System Description

 Web-based shopping portal catering to books


 Web Application implemented in Microsoft .NET


 Generic functionalities are third party business components
  implemented as EJB’s.
Third – Party Business Components

 Tax Calculation Service

 Shipping Cost Calculation Service

 Credit Card Validation Service
  - Based on Luhn Algorithm
Technologies used

   ASP.NET, ADO.NET, C#
   ASP.NET WebMethod Framework
   J2EE 1.3.1 (EJB)
   AXIS 1.1 Framework
   JBOSS 3.2.3
   IIS 5.0
   Microsoft ACT
   Apache JMeter
System Overview
System Architecture


   VENDOR              THIRD PARTY BUSINESS
                       COMPONENT


                                              EJB
     VENDOR     SOAP    SOAP
      (.NET)   PROXY    SKELET                      DATABASE
                        ON
                                              EJB
Class Diagrams
Buyer Class Diagram
Class Diagrams (contd..)
Vendor Class Diagram       Vendor Module
                           5 classes
Use Case: Buyer
Use Case: Vendor
Sequence Diagram: Tax Calculation
Sequence Diagram: Shipping Cost Calculation
Sequence Diagram: Credit Card Validation
Demo
Performance Evaluation: Web Application
 No of Iterations (Vs) Response Time (20 users)
                   WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM
   .




                            140
   Avg Response Time (ms)




                            120

                            100

                            80                                                    Java Web Service
                            60                                                    .NET Web Service

                            40

                            20

                             0
                                  0   10   20     30       40      50   60   70
                                                No of Iterations
Performance Evaluation: Web Application
 No of Iterations (Vs) Response Time (40 users)
                            WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM


                            140
   .




                            120
   Avg Response Time (ms)




                            100

                             80
                                                                                  Java Web Service
                                                                                  .NET Web Service
                             60

                             40

                             20

                             0
                                  0   10   20     30       40      50   60   70
                                                No of Iterations
Performance Evaluation: Web Application
 No of Threads (Vs) Response Time
    WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM


                                   80
          .




                                   70
          Avg Response Time (ms)




                                   60

                                   50
                                                                           Java WS
                                   40
                                                                           .NET WS
                                   30

                                   20

                                   10

                                   0
                                        0   20        40         60   80
                                                 No of Threads
Performance Evaluation: Web Service
 No of Iterations (Vs) Response Time (20 users)
    WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM
    .




                             45
                             40
    Avg Response Time (ms)




                             35
                             30
                             25                                         Java Web Service
                             20                                         .NET Web Service
                             15
                             10
                             5
                             0
                                  0   10   20          30     40   50
                                           No Of Iterations
Performance Evaluation: Web Service
 No of Iterations (Vs) Response Time (40 users)
    WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM
       .




                                30
       Avg Response Time (ms)




                                25

                                20
                                                                           Java Web Service
                                15
                                                                           .NET Web Service
                                10

                                5

                                0
                                     0   10   20           30    40   50
                                              No of Iterations
Results

 The web application irrespective of the type of web service it
  consumed showed similar performance.
 For web application CPU usage was at 90% - 95%
 Theoretically, a web application consuming a .NET web service should
  perform better.
 Individually, a .NET web service showed better performance over a
  Java web service as expected.
 For individual web services CPU usage at 70% - 75%
Analysis

 High CPU usage (95%) and page fault rates
  overshadowed gains obtained from consuming a .NET
  web service as opposed to a Java web service

 For individual web services, gains from the .NET web
  service overshadowed CPU usage (75%) and page fault
  rates
Implementation Issues
 Making wsdl files generated by AXIS accessible to the
  .NET system
 Setting up the requisite permissions to allow the .NET
  system access to host web pages on the notebook.
 Insufficient documentation on interoperability between
  .NET and J2EE technologies.
 JBoss .NET or AXIS ?
 Working simultaneously with both .NET and J2EE API’s.
Lessons Learned

 Cross-platform component integration through web
  services

 Java and .NET API’s available for exposing business
  components as web services.

 Role of JBoss and Axis in deploying stateless EJB’s as
  web services
Conclusion
 Microsoft .NET and Axis need optimizations to identify
  and expose cross-platform components as web services

 Cross-platform integration reduces the communication
  speed of the web application.

 Cross-platform integration not suitable for web applications
  that require speedy communication with business
  components
Future Work
 Improving security by using extending SOAP headers to
  carry authentication information
 Including and exposing package tracking facilities as web
  services to obtain real-time data on orders.
 Using the API’s provided by .NET and J2EE for working
  with XML for analyzing inventories, and generating order
  invoices
 Organizations working on extending JSR to bring stateful
  beans and CMP’s under the purview of web services
References

   http://www.msdn.com
   http://ws.apache.org/axis
   http://www.onjava.com/pub/a/onjava/2002/06/05/axis.html
   http://www.thirdm.com/articles/alesso.htm
   http://jakarta.apache.org/jmeter/usermanual/index.html
   http://helponline.oracle.com/jdeveloper
   http://www.research.ibm.com/journal
   http://javaboutique.internet.com/tutorials/JMeter/
   http://www.jboss.org/index.html?module=bb
   http://nagoya.apache.org/wiki/apachewiki.cgi?AxisProjectPages/DotNetInterop
 http://www.vbip.com/books/1861005091/chapter_5091_01.asp
Questions ?

				
DOCUMENT INFO