Weisfeld. The object-oriented thought process
Подождите немного. Документ загружается.
264
Chapter 13 Objects and the Internet
to this fact, perhaps the biggest advantage that SOAP has going for it is that it has most of
the major software companies on board with its standard.
As described over and over in this book, one of the major advantages of object tech-
nology is that of wrappers. SOAP can be thought of as a wrapper that, while not an exact
replacement for technologies like DCOM, Enterprise JavaBeans or CORBA, it does
“wrap” them for more efficient use over the Internet.This “wrapping” ability allows com-
panies to standardize their own network communications, even though there may be dis-
parate technologies within the company itself.
Whatever the description of SOAP, it is important to note that, as basic HTML, SOAP
is a stateless, one-way messaging system. Because of this and other features, SOAP is not a
total replacement for technologies like DCOM, Enterprise JavaBeans, CORBA or
RMI—it is a complimentary technology.
In keeping with the theme of this book, the following SOAP example focuses on ob-
ject concepts and not any specific SOAP technology, coding or otherwise.
SOAP
The example presented in this chapter shows the flow of objects through a distributed sys-
tem. A complete sample application is included in the accompanying media but is way too
large to fit in the pages of this book.
For this example, let’s create a Warehouse application.This application utilizes a browser as
the client, which then uses a set of web services to transact business with a Warehouse sys-
tem that resides somewhere on the network.
We use the following model for our SOAP example. Figure 13.11 provides a visual di-
agram of the system.
The file mwsoap.xml is the XML description of the structure of the various transactions
handled by the web services.This description of Invoice. xsd is shown in the following
listing.
mwsoap.xml
Application
Web
Services
Transaction
Warehouse
Figure 13.11 SOAP example.
265
Distributed Objects and the Enterprise
<?xml version=”1.0” encoding=”utf-8”?>
<xs:schema targetNamespace=”http://ootp.org/invoice.xsd”
elementFormDefault=”qualified”
xmlns=”http://ootp.org/invoice.xsd” xmlns:mstns=”http://ootp.org/invoice.xsd”
xmlns:xs=”http://www.w3.org/2001/XMLSchema”>
<xs:element name=”Invoice”>
<xs:complexType>
<xs:sequence>
<xs:element name=”Address” minOccurs=”1”>
<xs:complexType>
<xs:sequence />
<xs:attribute name=”Street” type=”xs:string” />
<xs:attribute name=”City” type=”xs:string” />
<xs:attribute name=”State” type=”xs:string” />
<xs:attribute name=”Zip” type=”xs:int” />
<xs:attribute name=”Country” type=”xs:string” />
</xs:complexType>
</xs:element>
<xs:element name=”Package”>
<xs:complexType>
<xs:sequence />
<xs:attribute name=”Description” type=”xs:string” />
<xs:attribute name=”Weight” type=”xs:short” />
<xs:attribute name=”Priority” type=”xs:boolean” />
<xs:attribute name=”Insured” type=”xs:boolean” />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name=”name” type=”xs:string” />
</xs:complexType>
</xs:element>
</xs:schema>
The Invoice.xsd file describes how an invoice is structured and how applications must
conform to its definitions.This file is, in effect, a schema in the same way that a schema is
used in a database system. Note that, per this Invoice.xsd file, an invoice is comprised of
an Address and Package. Further, the Address and Package are built of attributes like
Description, Weight, etc. Finally, these attributes are declared as specific data types like,
string, short, etc. Figure 13.12 shows graphically what this relationship looks like.
In this example, while the Invoice.xsd file describes how the data is structured, the
mwsoap.xml file represents what the data is.An application, written in a language like C#
.NET,VB .NET,ASP.NET or Java, uses the Invoice.xsd file to construct valid XML files
that are then sent to other applications over the network.These applications would use
the same Invoice.xsd file to deconstruct the mwsoap.xml file for use its use. In many
ways, you can think of the Invoice.xsd file as a sort of contract, in a similar way to the
266
Chapter 13 Objects and the Internet
E
A
A
A
A
A
Package
Description
Weight
Priority
Insured
E
A
A
A
A
(Package)
string
short
boolean
boolean
Address
Street
City
State
Zip
Country
(Address)
string
string
string
int
string
Invoice
Address
Package
name
E
E
E
A
(Invoice)
(Address)
(Package)
string
–
Figure 13.12 Invoice.xsx (visual representation of schema).
concept of a contract in the chapter 8, Frameworks and Reuse: Designing with Interfaces
and Abstract classes.
The following is the mwsoap.xml file that contains specific data embedded in its
SOAP/XML format.
<?xml version=”1.0” encoding=”utf-8”?>
<soap:envelope xmlns:soap=”http://www.w3.org/2001/06/soap-envelope”>
<soap:Header>
<mySOAPHeader:transaction xmlns:mySOAPHeader=”soap-transaction”
soap:mustUnderstand=”true”>
<headerId>8675309</headerId>
</mySOAPHeader:transaction>
</soap:Header>
<soap:Body>
<mySOAPBody xmlns=”http://ootp.org/Invoice.xsd”>
<invoice name=”Jenny Smith”>
<address street=”475 Oak Lane”
city=”Somewheresville”
state=”Nebraska”
zip=”23654”
country=”USA”/>
<package description=”22 inch Plasma Monitor”
weight=”22”
priority=”false”
insured=”true” />
</invoice>
267
Distributed Objects and the Enterprise
</mySOAPBody>
</soap:Body>
</soap:envelope>
Web Services Code
The only piece of the model left to cover is the code applications themselves.The three
classes that correspond to the Invoice, Address and Package are presented in the follow-
ing in C# .NET. Equivalent code is presented in Visual Basic .NET at the end of this
chapter.
It is important to note that the applications can be of any language.This is the beauty
of the SOAP/XML approach. Each application must be able to parse the XML file—and
that it basically the only requirement as seen in Figure 13.13. How an application uses the
data extracted is totally up to the application.
As a result of this approach, the specific language, or platform for that matter, is irrelevant.
Theoretically, any language can perform a parsing operation, and that is basically what is
needed in this SOAP/XML approach.
Of course, as developers it is helpful to take a look at the code directly. In the follow-
ing sections, the C# .NET code is presented to help illustrate how the system described
in Figure 13.12 is implemented.The corresponding VB .NET code is supplied in the
chapter’s code appendix.
Invoice.cs
The following code is the C# .NET implementation of the Invoice class that is repre-
sented in Figure 13.12:
using System;
using System.Data;
using System.Configuration;
using System.Xml;
using System.Xml.Serialization;
Application Program (Parser) Application Program (Parser)
Web
Services
XML File (SOAP) XML File (SOAP)
´
Figure 13.13 Parsing the SOAP/XML file.
268
Chapter 13 Objects and the Internet
namespace WebServices
{
[XmlRoot(“invoice”)]
public class Invoice
{
public Invoice(String name, Address address, ShippingPackage package)
{
this.Name = name;
this.Address = address;
this.Package = package;
}
private String strName;
[XmlAttribute(“name”)]
public String Name
{
get { return strName; }
set { strName = value; }
}
private Address objAddress;
[XmlElement(“address”)]
public Address Address
{
get { return objAddress; }
set { objAddress = value; }
}
private ShippingPackage objPackage;
[XmlElement(“package”)]
public ShippingPackage Package
{
get { return objPackage; }
set { objPackage = value; }
}
}
}
Invoice.vb
The following code is the VB .NET implementation of the Invoice class that is repre-
sented in Figure 13.12:
Imports Microsoft.VisualBasic
Imports System
Imports System.Data
Imports System.Configuration
269
Distributed Objects and the Enterprise
Imports System.Xml
Imports System.Xml.Serialization
<XmlRoot(“invoice”)> _
Public Class Invoice
Public Sub New(ByVal name As String,
ByVal itemAddress As Address, ByVal itemPackage As Package)
Me.Name = name
Me.Address = itemAddress
Me.Package = itemPackage
End Sub
Private strName As String
<XmlAttribute(“name”)> _
Public Property Name() As String
Get
Return strName
End Get
Set(ByVal value As String)
strName = value
End Set
End Property
<XmlElement(“address”)> _
Private objAddress As Address
Public Property Address() As Address
Get
Return objAddress
End Get
Set(ByVal value As Address)
objAddress = value
End Set
End Property
Private objPackage As Package
<XmlElement(“package”)> _
Public Property Package() As Package
Get
Return objPackage
End Get
Set(ByVal value As Package)
objPackage = value
End Set
End Property
End Class
270
Chapter 13 Objects and the Internet
Conclusion
In this chapter, we have covered some of the technology available for using objects in
conjunction with web applications. It is important to differentiate between objects em-
bedded in a web page (such as JavaScript) and objects use in a distributed system.
Distributed objects have evolved quickly over the past several years.There are now
many options in the distributed object market; however, the combination of SOAP and
XML has made the design of distributed systems much more standard.
References
Savitch,Walter. Absolute Java, 3rd ed.Addison-Wesley, 2008. Boston MA.
Walther, Stephen. ASP.NET 3.5 Unleashed. Sams Publishing, 2008. Indianapolis, IN.
Skeet, Jon. C# in Depth:What You Need to Master C# 2 and 3. Manning, 2008. Greenwich, CT.
Deitel, et al. C# For Experienced Programmers. Prentice Hall, 2003. Upper Saddle River,
New Jersey.
Deitel, et al. Visual Basic .NET For Experienced Programmers. Prentice Hall, 2003. Upper
Saddle River, New Jersey.
Conallen, Jim. Building Web Applications with UML.Addison-Wesley, 2000. Boston, MA.
Jaworski, Jamie. Java 2 Platform Unleashed. Sams Publishing, 1999. Indianapolis, IN.
http://www.w3schools.com/media/media_object.asp
http://www.w3.org
14
Objects and Client/
Server Applications
Chapter 13,“Objects and the Internet,” covered the concept of distributed objects. In
that chapter, the Internet was the primary highway that the objects navigated. In this chap-
ter we narrow the scope a bit and explore the topic of sending objects across a
client/server network.
Although objects in a distributed network do not necessarily follow a specific path, an
object on a client/server journey is more of a point-to-point journey—at least in a con-
ceptual sense.
Because many of the concepts described in Chapter 13 apply to this chapter as well,
this chapter focuses primarily on the higher-level concepts of the client/server model.
Client/Server Approaches
As we have seen in several of the previous chapters, XML has had a major impact on the
development technologies used today. For example, a distributed object model can either
be build on proprietary system or use a non-proprietary approach based on technologies
like SOAP/XML.
The same can be said of a client/server model.An application can be built solely on a
proprietary system or on a design using an XML. In this chapter, both models are cov-
ered.We use Java to describe a proprietary approach that will only execute in a Java envi-
ronment, even though Java can be used in a non-proprietary solution as well.
Then, C# .NET will be used to illustrate the XML based approach with the VB .NET
code presented at the end of the chapter.
272
Chapter 14 Objects and Client/Server Applications
Client Server
Object
Figure 14.1 Basic
client/server flow.
Proprietary Approach
In this example, Java is used to illustrate how a direct point-to-point connection is made
over a network.To accomplish this, I use an example that I have been using for many
years, sending an object from a client to a server, possibly changing the object by the
server and then sending it back to the client.
This basic flow is illustrated in Figure 14.1.
In this design, the client creates an object and then sends it to the server.The server cre-
ates a reference to the object to access it.The server then may update the object’s attrib-
utes and then send it back to the client.
Serialized Object Code
We start by creating a simple TextMessage class that contains attributes called name and
message.The class also contains a constructor as well as getters and setters.The complete
TextMessage class is presented in the following code.
import java.io.*;
import java.util.*;
public class TextMessage implements Serializable {
public String name;
public String message;
// TextMessage ‘s Constructor.
TextMessage(String n) {
message = “ “;
name= n;
}
// Objects ‘getter’ function.
public String getName() {
return name;
273
Proprietary Approach
}
// Objects ‘getter’ function.
public String getTextMessage() {
return message;
}
// Objects ‘setter’ function.
public void setTextMessage(String inTextMessage) {
message = inTextMessage;
}
}
This is a pretty simple class.The constructor initializes the name attribute via a parame-
ter and sets the message to blanks.The primary item to notice is that the class is serialized
in a proprietary Java binary format.
Client Code
The client code uses the TextMessage class to create an object and start it on a journey
to the server and back.The client must perform the following tasks:
n
Get the user information
n
Create an object
n
Set the attributes
n
Create a socket connection
n
Create the output streams
n
Write the object
n
Close the streams
The code for this client is presented in the following listing.The comments provide most
of the code commentary.
import java.io.*;
import java.net.*;
/*
* The Client for TextMessage
*/
public class Client {
public static void main(String[] arg) {
try {
String message = “ “;
String name = “ “;