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 componentsroutine, 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

<?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

<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>

WSDL Sample (contd .. )

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

VENDOR

(.NET)

SOAPPROXY

THIRD PARTY BUSINESS COMPONENT

SOAP SKELETON

EJB

EJB

DATABASE

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

0

20

40

60

80

100

120

140

0 10 20 30 40 50 60 70

No of Iterations

Avg

Res

pons

e Ti

me

(ms)

.

Java Web Service

.NET Web Service

Performance Evaluation: Web Application

No of Iterations (Vs) Response Time (40 users)

WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM

0

20

40

60

80

100

120

140

0 10 20 30 40 50 60 70

No of Iterations

Avg R

esponse T

ime (m

s) .

Java Web Service

.NET Web Service

Performance Evaluation: Web Application

No of Threads (Vs) Response Time WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM

0

10

20

30

40

50

60

70

80

0 20 40 60 80

No of Threads

Avg R

esponse T

ime (m

s)

.

Java WS

.NET WS

Performance Evaluation: Web Service

No of Iterations (Vs) Response Time (20 users) WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM

0

5

10

15

20

25

30

35

40

45

0 10 20 30 40 50

No Of Iterations

Avg

Res

ponse

Tim

e (m

s) .

Java Web Service

.NET Web Service

Performance Evaluation: Web Service

No of Iterations (Vs) Response Time (40 users) WEB SERVER: PRESARIO x1000, 1.8 GHz Centrino®, 512 MB RAM

0

5

10

15

20

25

30

0 10 20 30 40 50

No of Iterations

Avg

Res

pons

e Ti

me

(ms)

.

Java Web Service

.NET Web Service

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 ?