I gave Visual Studio another try, and with the help of a tutorial on web services I was able to actually set one up!!! I'm still far from being a professional, but I at least understand a little bit more of what's actually going on. The thing that actually confused me was when I selected "Create Web Service" in VS2005 three files were created: web.config, service.asmx, and service.vb. I'm still not sure what they each do individually, but, I pasted some functions that converted between Celsius and Fahrenheit, and then selected build, and the service was built. And then, I didn't know what to do. I went further on through the tutorial and saw that if you wanted to integrate this service into your website all you had to do was reference where the service was. I created a simple .html file and voila, It worked. I'm still not sure what the .vb or .config files actually do, or where SOAP and WSDL actually come into place, but the .asmx file is the place where you create the "web methods" that your service needs to perform.
I was able to help some one else get going with .NET, at least to the point I had reached with the web service I created on the first of the month, which was a converter between Fahrenheit between Celsius. So that helped solidify my knowledge a little bit.
I'm still trying to understand how to piece everything together in .NET. I created another simple web service from a tutorial on Microsoft's web site, and it helped define some of the different files VS creates with any given web service. They referred to the .vb file as the web service, the .asmx file as the ASP file (I'm still not sure what this does). And the web.config has a lot of xml in it, and I wonder if it has anything to do with the WSDL. The web service I created was a simple math service. You can choose any of the basic four operations and plug two numbers in and it will give you and answer in xml. When you select the operation, you are taken to a page that has two text boxes labeled A and B in which you can put the numbers you want operated on. Beneath those boxes are two SOAP examples. I imagine they're giving us an example of how our web service is communicating with the server where the code lies. As far as I understand from yesterday's class, we don't need to make a web page, just a service that provides enough formatted requests so that it could easily be tied to a web page if need be. We just need to get the information from the weather database in Dr. Liddle's MySQL DB and format it correctly on our side.
I began to lose hope that I'd ever understand web services. I understood the concept of them. A WSDL is basically a contract that lives on the server and allows subscribers to view it to know what types of methods they can call to use the web service on that server. The SOAP requests and responses are the way the client and server communicate. This is great to know, but how to practically put it to use was a totally different question. I've had some experience with Java so I decided to try something different than the Java EE route. This could have been my first mistake. I installed Visual Studio (as mentioned above) and had a little success with it, but I still had no idea where the WSDL was, how it was created, or how the service was even running. There was too much magic going on behind the scenes.
Luckily I was notified of a WSDL seminar that Jimmy Zimmerman was going to teach at this morning. He made it so much easier to understand. He took a random WSDL and showed us how he modified it to work with a simple math web service he created. Dr. Liddle did something similar, but it was with an already relatively complicated web service, and even Jimmy couldn't follow him. Suffice it to say I think I'm going to take the PHP route. I'd still like to try to better understand .NET, but with a due date on this assignment, I don't want to kill myself trying to get it done.
I'm going to spend a few more hours today trying to put together a WSDL myself. I'll let you know how it goes.
This project is driving me nuts. I've spent countless hours trying to get it straight, and I have had no luck. I've talked to people in the class, I've consulted every web source google points me to when I search for the errors I have. I've talked with Dr. Liddle and got a little help, but I haven't had much of a chance to talk to him since.
The part I cannot get, nor can anyone else I’ve talked to who’s doing it in php, is how to return a complextype. I keep getting this error:
Fatal error: Uncaught SoapFault exception: [SOAP-ENV:Server] SOAP-ERROR: Encoding: object hasn't 'cityzip' property in C:\wamp\www\client4Liddle.php:6
#0 [internal function]: SoapClient->__call('getWeather', Array)
#1 C:\wamp\www\client4Liddle.php(6): SoapClient->getWeather('84602')
#2 C:\wamp\www\client4Liddle.php(13): getWeatherDetails()
thrown in C:\wamp\www\client4Liddle.php on line 6
***Later that day...***
Jimmy Zimmerman saved the day again. He had run into the same problems that I was having. Apparently, PHP doesn't like the degree symbol, and for that reason was throwing the above error. Another problem I was having was putting spaces in the elements of my associative array (i.e., $weather[City Zip] = row->cityzip;). SOAP doesn't like the spaces, and will throw an error in that case as well. You cannot have any leading or trailing white space before and after the , or the SOAP client will not be able to get the WSDL. After these issues were resolved, I was able to finally finish this project.
Business Case for Web Services and SOA
I'm not completely turned off by web services just because of this assignment. With all of the searching I've done on Google, I've definitely seen that web services are widely used in all sorts of areas. What I basically understand of web services is that they provide a resource for any body who desires to call their information. With the example of the weather web service we were asked to implement, anyone who wanted could write a requester (client) to connect to the web service that I wrote (if it ever worked). They could have the information that was retrieved plugged into their website.
I think the best example in class was that of the personalized Google homepage. You can insert any number of web services onto you page to give you news updates, weather updates, games, etc. This may not be the best example by which Dr. Liddle would have us undertand web services, but he didn't discount it.
Using Google as an example, I could see web services being of great benefit to any enterprise. In my web analyitcs class we are currently beginning to understand what dashboards are and how they can be useful. A dashboard gives you a quick visual overview of several aspects of something you wish to be monitoring. Copious amounts of information can usually be gathered by a well selected combination of graphs, statistics, or other reports on these dashboards.
A company's internal or external website could be composed of several web services that provide a similar service to that of Google's homepage, but more of a dashboard for specific updates on the progress of certain products, order information, etc. With order information you could integrate a map service with a shipment tracking service that would display on the map the approximate location of your order with the number of stops left to make and the approximate arrival date and time. Any delays could be annotated on it as well. For internal information, several teams are usually working on the development of a given product. These teams could post updated statistical information from the various tests they would be performing throughout the development and polishing of the new product.
A generic Service Oriented Architecture:
The concept of web services was discussed in the context of a Service Oriented Architecture. We had a difficult time defining SOA in class, but came up with some good attributes of this architecture:
- Loosely coupled
- Highly cohesive
- Web services
- Collection of communicating systems
- Enterprise Service Bus
Highly cohesive goes right with loose coupling. Each piece of the system is self-contained. Because of the low number of interdependencies, each individual part of the system is dedicated to performing one aspect of the system well. Web services were explained above.
With a collection of highly cohesive, loosely coupled systems, the collection of systems must be able to communicate well in order to provide a valuable service. An enterprise service bus is a back bone that all the systems can plug into, it's what provides the communication ability to the different services. The ESB is made up of a lot of machinery, and allows for lower coupling. The lower coupling comes from the fact that each system can link up to the ESB, not requiring them to be linked together, just to the ESB. Here's a diagram of an ESB that IBM has posted:
Overall I think that Web Services and SOA are a very good solution for businesses. A modularized type of environment allows for easier implementation of change. Organizations are constantly undergoing change. New technologies emerge that will give companies an edge over the others (at least until the other companies implement the same change, in which case it becomes a necessity to keep up with everyone else on the technology wave.) If each of the services companies offer are loosely coupled, and connected to an ESB, each module could be changed without affecting the entire system.
This concept is very similar to hot swappable media used in enterprise network devices. Different components of the switches or routers can be replaces without having to unplug or reset the device, allowing for a seemingly uninterrupted change to the enterprise network.