Learning what a web service is and its usefulness Understanding how to send data to an XML web service using the POST and GET methods Parsing the response messages from a web service an
Trang 1// Create a node as a child of the attributed node xmlNewChild (attributedNode, NULL, BAD_CAST “AttributedChild”, BAD_CAST “Attributed Node Child Node”);
// You can also build nodes and text separately then and add them // to the tree later
xmlNodePtr attachNode = xmlNewNode(NULL, BAD_CAST “AttachedNode”);
xmlNodePtr nodeText = xmlNewText(BAD_CAST “Attached Node Text”);
// Add the text to the node xmlAddChild(attachNode, nodeText);
// Add the node to the root xmlAddChild(rootNode, attachNode);
// You can even include comments xmlNodePtr comment;
comment = xmlNewComment(BAD_CAST “This is an XML Comment”);
xmlAddChild(rootNode, comment);
// Write the doc xmlChar *outputBuffer;
int bufferSize;
// You are responsible for freeing the buffer using xmlFree // Dump the document to a buffer
xmlDocDumpFormatMemory(doc, & outputBuffer, & bufferSize, 1);
// Create an NSString from the buffer NSString *xmlString = [[NSString alloc] initWithBytes:outputBuffer length:bufferSize encoding:NSUTF8StringEncoding];
// Log the XML string that we created NSLog (@”output: \n%@”, xmlString);
// Display the text in the textview [self.textView setText:xmlString];
// Free the xml string [xmlString release];
// Clean up // Free the output buffer xmlFree(outputBuffer);
// Release all of the structures in the document including the tree xmlFreeDoc(doc);
xmlCleanupParser();
}
XML and the iPhone SDK ❘ 299
Trang 2300 ❘ CHAPTER 10 WORKING WITH XML ON THE IPHONE
The last thing that you have to do before running the application is add a call to generateXML to
viewDidLoad :
- (void)viewDidLoad {
[super viewDidLoad];
[self generateXML];
}
Now you are ready to build and run the application You should see the XML generated in the
console and displayed in the TextView in the iPhone simulator
Many other features are supported by libxml I strongly encourage you to visit the libxml web site
at http://xmlsoft.org/
MOVING FORWARD
In this chapter, you have learned how to communicate with remote servers over the Internet using
the Cocoa URL Loading System You implemented the NSURLConnection delegate methods to
handle asynchronous loading of data from the Web Then, you learned how to parse the XML that
you receive as a response to a remote method call Finally, you learned how to generate dynamic
XML documents
This chapter lays the foundation for integration with XML web services The next chapter explores
communication with XML web services; you build a sample project that queries a web service and
then processes the response in an interesting way
Trang 3Integrating with Web Services
WHAT ’ S IN THIS CHAPTER?
Learning what a web service is and its usefulness Understanding how to send data to an XML web service using the POST and GET methods
Parsing the response messages from a web service and using the resulting data from within an iPhone SDK application
Building location - based applications using the GPS functionality
in the Core Location framework and the mapping capability of the MapKit framework
In the previous chapter, you learned how to ask for data from a web server by sending HTTP requests You also learned about XML and how to parse the XML that you receive from web servers in response to your HTTP requests In this section, you will take that knowledge a step further by integrating your application with Internet - based web services
In this chapter, you will learn about web services and how to use them in your iPhone and iPad applications You will also explore a couple of other interesting features of the iPhone SDK, including MapKit and Core Location
This chapter builds on the knowledge that you gained from the last chapter to integrate iPhone SDK applications with web services I will cover the use of the GET and POST HTTP methods
to send data to a web service You will then build a couple of sample applications that use web services as an integral part of the program
NETWORK APPLICATION ARCHITECTURE
When you set out to start work on a new project, one of your fi rst decisions involves designing the architecture of your application and determining how the parts of your system will work together Most data - oriented applications will involve a database, and all iPhone applications
➤
➤
➤
➤
11
Trang 4302 ❘ CHAPTER 11 INTEGRATING WITH WEB SERVICES
will include a user interface In order to get a better understanding of how to design applications
where the iPhone and database need to communicate, you will take a brief look at a couple of
typical network application architectures
Two - Tier Architecture
The simplest network application architecture consists of a database and an interface Architects refer
to this design as two - tier or client - server architecture You can see this design in Figure 11 - 1 In this
design, the client application resides on the mobile device or computer, and implements the application
interface Additionally, the client software includes the implementation of the business rules that
govern the functionality of the application The server tier is generally an enterprise database such as
Oracle, SQLServer, or MySQL, which can share its data with many connected clients
Server
Client
Client
Client
You see this type of client - server architecture when you look at web servers, particularly web servers
that serve simple HTML web pages The client in this design is your web browser and the server
is the web server Many clients connect to the same web server to get data The client web browser
hosts the user interface and the logic to display the HTML data
This architecture is most appropriate for simple applications However, as the business rules for
your application become more complex, you will likely outgrow this design In order to maintain
encapsulation of functionality, the client should be responsible for displaying data and the server
Trang 5for storing it If there are minimal rules that govern the logic and data of the application, you could implement them either in the database or on the client
As the number and complexity of the rules that defi ne the functionality of your application increase, you will need to decide where you want to implement those rules You could implement them on the client If your client software were a “ thick ” desktop application, changing rules would mean
re - deploying your application to your clients If the client is a “ thin ” web - browser based client, you are constrained by the capabilities and performance of the browser and client - side languages such as JavaScript
As the business rules of your application get more complex, you will often need to add a third tier
to your application architecture It is in this tier where the business rules reside In this design, you can decouple your business rules from both the display logic of the client software and the storage system of the database
Three - Tier Architecture (n - tier)
As you learned in the last section, you need to consider your application ’ s ability to maintain a complex set of business rules in your design As you design your system, you need to consider the complexity of the rules that govern your application and the likelihood that these rules could change
For instance, if you are building an order entry system, you need to consider the fact that customer discount percentages could change You may not want to code these percentages into the user interface layer of your application because any changes to this data would require a redeployment of your software In instances like this, it is common for the designer to pull these business rules out of the interface and place them in their own logical software layer The client - server design then evolves into
a three - tier (or n - tier if more than one business layer is necessary) architecture (see Figure 11 - 2)
Application Server Database Server
Client
Client
Client
Network Application Architecture ❘ 303
Trang 6304 ❘ CHAPTER 11 INTEGRATING WITH WEB SERVICES
In a three - tier design, the application architect moves the business logic in to its own logical and
perhaps physical process You can therefore decouple the business rules from the user interface
and the database This gives the designer more fl exibility when it comes to designing the database,
the interface, and the business logic It also effectively encapsulates each of these important features
of a system It is easier to manage the business logic of your system if you do not tightly couple
this code to the database or the user interface This simplifi es making changes to any one of the
layers of the design without affecting any of the other layers In this design, all of the rules that
govern what data can be added to the database and specifi c calculations that are performed on
that data are moved out of the interface layer into their own tier Many commercial application
servers such as WebLogic, Apache Tomcat, and WebSphere perform this function
Application Communication
Client applications need to be able to talk to the business tier or application server and the
application server needs to be able to talk to the database
Typically, the application server and database reside on the same local network, although this is
not necessary These two layers generally communicate through an interface layer that knows how
to call functions in the database A common interface API for database communication is Open
Database Connectivity (ODBC) Most programming languages provide support APIs for connecting
to databases as well The Microsoft NET platform provides an API called ADO.NET while the
Java system provides JDBC
For the client to business - tier communication, the designer can implement connectivity using a
variety of methods depending on the languages and operating systems used in the implementation
In the past, designers of Windows systems would have used DCOM or Distributed Component
Object Model This technology allowed components on different computers to talk to each other
In a Java - based system, the designer could choose a similar technology called Java Remote Method
Invocation (RMI) In this system, objects running in one Java virtual machine can call methods
on objects in another virtual machine CORBA, or Common Object Request Broker Architecture,
is another technology that enables remote machines to execute methods and share data with
one another The advantage of CORBA is that it is language independent There are CORBA
implementations for most major computer languages and operating systems
A more current technology enables the designer to implement the functionality of the business tier
as a web service With this technology, the designer can expose the business logic of the application
using a web server Client software can then use well - known methods of the HTTP protocol to
access the services exposed by the application server
INTRODUCING WEB SERVICES
When you use a web browser to visit your favorite web site, you begin by sending a request to the
site ’ s server If all goes well, the server accepts your request and returns a response The response
that you get is text in the form of HTML, which your browser renders into the page that you see on
your screen
Trang 7Consumers of the HTML that a web server sends are generally people that view the HTML using a browser Web services, on the other hand, respond to requests by sending back data that is intended for computers to consume
Typically, most web services default to returning response data to you using XML With some web services, however, you can request that your data be returned in other formats, such as JSON (JavaScript Object Notation) JSON is a text - based format, like XML Unlike XML, however, JSON can be used directly in browser - based web applications that are backed by JavaScript code Coverage of JavaScript is beyond the scope of this book, as is using JSON in browser - based applications What you should know though is that there are parsers available to consume JSON response data for many languages, including Objective - C
In the previous chapter, you looked at a snippet of XML that could be used to add an address entity
to an address book application:
address >
< name > John Smith < /name >
< street > 1 Ocean Blvd < /street >
< city > Isle Of Palms < /city >
< state > SC < /state >
< zip > 29451 < /zip >
< /address >
Here is the JSON representation of the same address:
{ “name”: “John Smith”, “street”: “1 Ocean Blvd”, “city”: “Isle Of Palms”, “state”: “SC”,
“zip”: “29451”
} Unlike XML, whose structure is defi ned by its users, JSON relies on data structures defi ned in JavaScript Specifi cally, JSON can use one of two data structures: the Object or the Array Because these data structures are common in almost all modern languages, it is easy to convert JSON messages into data structures that can be used in almost any language The Object consists of a set
of name - value pairs, and the Array is a list of values
Application architects can design web services to act as the application server for their particular application Third parties also build web services to provide specifi c services to their clients In this chapter, you will develop two applications that use third - party web services from Yahoo! to implement some interesting functionality The fi rst service allows you to submit queries and returns the results based on proximity to the location of the search The second service accepts a long string
of text and returns a list of the most important words in the text
In general, web services provide a way to expose some complex logic by using the simple and well known interfaces of the Web
For example, a designer can easily expose an external interface to a database by building a web service that allows clients to create records or query the data store Consider the product catalog
Introducing Web Services ❘ 305
Trang 8306 ❘ CHAPTER 11 INTEGRATING WITH WEB SERVICES
from Part I of this book You could build a web service that exposes an interface that accepts orders
and enters them directly into the back - end database You could then build an iPhone order entry
application that uses this web service to allow your sales force in the fi eld to submit orders
You can develop web services using many languages and frameworks such as Java, Microsoft.NET,
and Ruby on Rails Because of the variation in languages and platforms available, building a web
service is beyond the scope of this book This chapter teaches you how to integrate your application
with existing web services
SOAP Messaging
There are two predominant protocols used for exchanging data with web services: SOAP and REST
You will look at SOAP in this section and examine REST in the next
Microsoft originally developed SOAP (Simple Object Access Protocol) in the late 90s and the W3C
standards body has standardized the protocol The designers built SOAP to be platform - and
language - agnostic in order to replace technologies such as CORBA and DCOM The designers
chose XML as the format for the messages in an effort to avoid some of the problems associated
with the binary - based messaging systems that SOAP would replace
Unlike CORBA and DCOM, the designers of SOAP decided to send messages using the HTTP
protocol, which makes network confi guration easy If users could see each other over the Web using
a browser, they could send messages to each other using SOAP
SOAP messages share a common element with other messaging formats such as HTML in that
the message contains a header and a body The header contains details about the type of message,
format of the data, and so on The body holds the “ payload ” or the data that the user intends to
transmit
One issue with using SOAP is the complexity of the messages In order to transmit a little bit of
data, users of SOAP often need to transmit long messages For example, here is the SOAP request
message that you would send to the eBay SOAP API to obtain the offi cial eBay time (from eBay.com:
using the eBay API to get the offi cial eBay time):
< ?xml version=”1.0” encoding=”utf-8”? >
< soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” >
< soapenv:Header >
< RequesterCredentials soapenv:mustUnderstand=”0”
xmlns=”urn:ebay:apis:eBLBaseComponents” >
< eBayAuthToken > ABC 123 < /eBayAuthToken >
< ns:Credentials xmlns:ns=”urn:ebay:apis:eBLBaseComponents” >
< ns:DevId > someDevId < /ns:DevId >
< ns:AppId > someAppId < /ns:AppId >
< ns:AuthCert > someAuthCert < /ns:AuthCert >
< /ns:Credentials >
< /RequesterCredentials >
< /soapenv:Header >
< soapenv:Body >
< GeteBayOfficialTimeRequest xmlns=”urn:ebay:apis:eBLBaseComponents” >
Trang 9< ns1:Version xmlns:ns1=”urn:ebay:apis:eBLBaseComponents” > 405 < /ns1:Version >
< /GeteBayOfficialTimeRequest >
< /soapenv:Body >
< /soapenv:Envelope >
This is quite a verbose message, especially considering that you are not even passing in any parameters Although the API simply returns a timestamp that represents the current time, it is also quite verbose:
< ?xml version=”1.0” encoding=”utf-8”? >
< soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” >
< soapenv:Body >
< GeteBayOfficialTimeResponse xmlns=”urn:ebay:apis:eBLBaseComponents” >
< Timestamp > 2005-05-02T00:07:22.895Z < /Timestamp >
< Ack > Success < /Ack >
< CorrelationID >
00000000-00000000-00000000-00000000-00000000-00000000-0000000000 < /CorrelationID >
< Version > 405 < /Version >
< Build > 20050422132524 < /Build >
< /GeteBayOfficialTimeResponse >
< /soapenv:Body >
< /soapenv:Envelope >
While SOAP offers far more functionality than simple method calling, you can see why developers often mock the name “ Simple ” Object Access Protocol Designers that simply needed to pass data between application layers or make basic method calls found that SOAP was overkill This led to the development of a simpler messaging protocol called REST
The REST Protocol
REST stands for REpresentational State Transfer The designers of REST wanted to be able to call web service functions using the simple and well - known methods exposed by the HTTP protocol:
GET and POST The goal was to make it easy to invoke remote functions and provide response data
in a more manageable format
REST uses a simple URI scheme to communicate with web services Developers who are comfortable using HTTP to make requests over the Web already know how to call REST services
Typically, a client application can simply issue an HTTP GET request to a URL to make a method call The developer can pass parameters to the call using querystring parameters as if simply passing parameters to a regular web site
Because REST is not standardized, it is possible that the client will receive response data from a REST based service in an arbitrary format However, XML is commonly used Typically, REST based web services can also return data using the JSON format instead of XML This is preferable
if you are developing Web - based applications
In order to be able to easily determine the intent of a call, the HTTP GET method is used to query for data, and the HTTP POST method is used when you want to modify data such as in an INSERT
Introducing Web Services ❘ 307
Trang 10308 ❘ CHAPTER 11 INTEGRATING WITH WEB SERVICES
or UPDATE to a database This makes it easy to determine if the caller intends to simply query the
service for data or make changes to the data managed by the service
It is very easy to build simple web services using REST If you already know how to implement
server - side web scripts, REST implementations are typically straightforward Both of the examples
in this chapter will call web services based on the REST protocol All of the concepts in this
chapter are equally applicable if your application needs to call a SOAP - based service The only real
difference is the format of the message that you are sending and the format of the response message
EXAMPLE 1: LOCATION - BASED SEARCH
One of the great features of the iPhone and iPad 3G is the GPS Developers are able use GPS to
determine the current location of the device and build applications that use this data to provide a
wealth of information to users This leads to some very creative applications
In the fi rst example in this chapter, you will take advantage of this capability of the device You
will use the Core Location framework to determine the current position of the device Then,
you will allow the user to input search terms into the application You will then call a Yahoo! web
service using the REST protocol and the HTTP GET method to obtain businesses that meet the
search criteria and are close to the current location Finally, you will use the MapKit framework to
display the returned data on a map
LocationSearch application
Don ’ t worry if you don ’ t have an iPhone When you use Core Location with the iPhone simulator, the simulator conveniently returns the latitude and longitude
of Apple headquarters in Cupertino, California.
The fi nished application will look like Figure 11 - 3
Starting Out
Now that you have an idea of what the application will do and how it
will look, let ’ s get started The fi rst step, as always, is to open Xcode
and create a new project Because there will be only one view, you
should create a new View - based application Call the new application
LocationSearch
You will be using the Core Location and MapKit frameworks in this
example These frameworks are not included in iPhone projects by
default, so you will have to add references to the frameworks to the
project Right - click on the Frameworks folder in the Groups & Files pane
in Xcode From the pop - up menu, select Add ➪ Existing Frameworks
In the dialog that opens, select the CoreLocation.framework item
and click the Add button Repeat this procedure to add the MapKit
.framework framework to your project as well