 |
|
|
Nearly every IT industry magazine and business management publication these days contains at least one article promoting the virtues and benefits of Web services and SOA.
Internet industry leaders such as Amazon, eBay, Google, and FedEx offer publicly-available Web services as APIs into desirable data and familiar functionality. For instance Amazon.com offers Web services for its product search, cart system, and wish lists, eBay Web services expose item search, bidding, and auction creation, Google Web services offer access to Web search, cache, and spelling applications, and FedEx Web services connect to its package shipping and tracking systems.
Analysts predict businesses could save billions of dollars by implementing Web services and SOA but say less than 20% of companies have gained significant experience with these technologies so far.
Despite the grand goals, positive predictions, and highly touted success stories, it's clear Web services have not yet become the universal idiom of enterprise IT operations. The chain of programming languages, industry standards, and diverse technologies involved in creating an end to end Web service can be intimidating even to skilled and experienced professionals. Fortunately, those approaching the creation of Web services for the first time can benefit from highly evolved tools offering a visual development approach to quickly ramp up productivity.
The Altova® MissionKit™ 2008 offers a robust solution, including the following Web services functionality: - Graphical XML Schema editor for embedding schema in WSDL files
- Visual WSDL design with corresponding WSDL code generation
- Automatic SOAP message generation based on WSDL definitions
- Universal SOAP client for sending and receiving SOAP messages
- SOAP debugger for testing and perfecting client and server Web services implementations
- Graphical Web services implementation and mapping to XML, database, EDI, and flat file data sources
- Automatic Web services code generation in Java and C#
Before we look at the benefits offered in the Altova® MissionKit™ 2008, let’s dig deeper into the challenges of Web services development.
Since there is still uncertainty surrounding Web services, let's start with a definition. The W3C describes a Web service as:
“ . . . a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”
In other words, the expression “Web services” describes a loosely coupled, platform- and language-independent set of Web-based communication protocols that form a simple, interoperable message format for interconnecting applications and sharing data.
Web services were conceived based on standards that encourage implementation over the Internet in a publicly available manner. However, enterprises can also apply Web services technologies on an intranet or in another closed environment; for instance, to allow a company's own sales force to query an inventory system for product availability before writing an order. Starting out with an internal project can be a good way to gain familiarity and build skills before embarking on a large scale Web services architecture plan.
Web services are defined in WSDL, which stands for Web Services Description Language. WSDL is written in XML. A WSDL file describes the location of the service (URL), the operations the service performs, and the specific communications methods the Web service employs. If the data to be passed has a complex structure, the WSDL also contains a definition of the data types within the Web services messages (schema).
Web services use XML to encode and decode information and SOAP (Simple Object Access Protocol) to transport messages using open internet standards.
So working from the core out, an XML Schema is embedded in a WSDL, which also contains definitions of the operations and access methods of the Web service. The WSDL itself is stored and retrievable from the server running the Web service, so a client application running on any platform and implemented using any programming language can read the WSDL over the internet and learn the rules it must obey, and the format of the messages to and from the Web service.
Here's the sequence of events that occurs in the execution of a typical Web service, annotated with the technologies involved at each step: - The Web services client issues a request (defined by the WSDL, formatted in XML, delivered via SOAP).
- Web Service infrastructure (Web server) hands the request to the Web service implementation (compiled from Java or C# source code).
- The Web service implementation communicates with an information repository (typically a relational database via SQL, but could also be a native XML or other data source).
- The Web service implementation forms the data returned by the repository into a syntactically correct response (XML defined by the WSDL).
- The Web server sends the properly-formed response to the client (XML over SOAP).
But that's not the sequence developers would want to follow when constructing a new Web service. Instead, the developer (or team of developers) might work in this order:
- Consider the business requirements to be accomplished by Web services. What will be requested by the client and what information will be supplied in the response to best meet the business goals?
- Analyze the current structure of the data in the data repository (or how best to structure a new database if one does not exist!).
- Construct or derive an XML Schema describing the necessary data structures that is optimized for Web services.
- Embed the schema in a WSDL file and specify the communication protocols to fully define the Web services.
- Write implementation source code to communicate with the database.
- Compile the source code and deploy the implementation on a server.
- Create an HTML web form or simple client application to interact with the service.
- Test, debug, rewrite . . . repeat as necessary.
Altova tools work together in concert to automate many of the complex steps in Web services development and offer new opportunities to test and debug along the way. Developers who use the Altova solution can concentrate on the business rules and logic, and rapidly create reliable Web services without becoming mired in source code or the arcane implementation details of the other technologies required. 
The complementary features of XMLSpy® 2008 and MapForce® 2008 combine in the Altova® MissionKit™ 2008 to flatten hurdles and accelerate progress at every step of Web services development.
Analyze the data and create an XML Schema
XMLSpy® 2008, the industry standard XML development environment, can automatically derive an XML Schema from a database content model or an XML instance document. You simply point XMLSpy at your data source and it automatically builds an XML schema to embed within your Web service.
Optimize the XML Schema for a Web service
The XMLSpy Schema Editor displays your schema in a clear graphical hierarchy so you can easily and quickly identify the relationships and understand the structure of the data source.
Optimizing your schema may be as trivial as making the service's key element global or as significant as protecting confidential data. Either way XMLSpy makes it easy.
For instance, in the latter case, your product database could include your company's cost for each SKU while you only want to reveal product descriptions and retail pricing. Using XMLSpy you can simply trim confidential elements so they won't be included in the Web service, or copy and paste only relevant parts to create a new schema optimized for the Web service.
Embed the schema and graphically define the WSDL file
Altova XMLSpy contains a WSDL editor that allows you to create, visualize, graphically edit, and validate any WSDL file.
Using the XMLSpy File/New menu selection you create a template for a new WSDL. Next, simply paste in your optimized schema in text view, then switch to graphical WSDL view to define operations, port types, bindings and services. Working in graphical view lets you avoid syntax errors that often occur in manual coding.
Map data sources and generate the Web service implementation code
When your WSDL design is complete, MapForce® 2008, the premier data integration and Web services implementation tool, offers a visual drag-and-drop mapping utility to connect the WSDL operations to their respective data sources. Then, once you've defined the mappings (and tested them using SOAP request documents created by XMLSpy) MapForce generates source code for your Web service in either Java or C#. In either programming language, MapForce creates a complete, ready to compile project.
Test the deployed Web service
Whether your Web service runs on an Apache or Microsoft Web server, you can use XMLSpy as a client to generate a SOAP request for it. You can edit the request parameters, send it to the server, then capture and examine the Web service reply. If you need to examine communications between a your own client application and the Web service, the XMLSpy SOAP debugger lets you step through Web services transactions between a client and server, set breakpoints, and inspect every request and response.
XMLSpy and MapForce even provide tools to help you document your Web services project. MapForce lets you print mapping diagrams for the record, and XMLSpy creates extensive documentation of XML Schema and WSDL files in either HTML or Microsoft Word format.
More information on the Altova MissionKit and Web services is available in these resources:
- Learn more about the Web services features of XMLSpy® 2008 and MapForce® 2008
- View a Flash demo of the creation of Web services using XMLSpy and MapForce
- Read the Equifax case study to find out how this leading credit reporting entity used XMLSpy to build an advanced SOAP interface for their identity verification and authentication Web service.
- Discover how we used the Altova solution to build a business operations Web service in this real-life
case study
- Apply the Web services tools in XMLSpy to connect as a client to an existing Web service
- Read our Web services white paper, entitled Web services: Benefits, challenges, and a unique visual development solution
Download a free 30-day evaluation of the Altova® MissionKit™ 2008 today!
|
|
|
|
