Date post: | 26-Dec-2015 |
Category: |
Documents |
Upload: | kerry-hutchinson |
View: | 213 times |
Download: | 0 times |
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 ?