Homework #18 - 10/22 (Makeup)

Chapter 19 - Service Oriented Architecture

     This chapter brings back memories.... I interned at BMW in Spartanburg at the IT Innovations department. There was a lot of neat things going on there with several different projects being worked on by different interns. I was probably assigned the least interesting project, and also probably the hardest. Let me see if I can recall, in correct details, what I was assigned. I was working on a back end web service which would be used for an in-house app store. The web service was to take in a JSON message which contained metadata about an app and error reporting for that app. It would include the client/developer name and contact information, a time stamp that the error report was sent, the error message, and some other stuff I can't remember. The JSON message was sent via SOAP and RESTful messages to a Glassfish server that was hosting my web service. The service was then to take the JSON, parse it, and store the information in an Oracle database. Whew, I think that's the gist of it.
     The reason this was, at least what I perceived, the hardest task is because I had never had any exposure to all of the technology and standards that come along with web services. For that matter, I don't think any of my colleagues did either. I had to read about SOAP messages, RESTful services, WSDL and XML descriptor files, and other things I don't remember. It's also the first time I had seen SQL or done anything with a database, so the learning curve was huge, as you can imagine. It took me the entirety of my 5 month internship to finish what should have been a relatively simple program.
     If I had another chance to develop the same type of system, I would jump at it. Back then I didn't really have a good grasp of what things such as a WSDL file was. All that I knew is that it was necessary to have for a web service to run. Now that I realize what it actually is and it's purpose, it wouldn't be nearly as confusing if I were have to do it again. Another thing I might employ is an actual life cycle model for my project. I remember not really knowing what I was doing, and just using the code-and-fix or waterfall models. Once something broke, and I couldn't figure out what I did to break it, I would frequently just scrap the whole thing and started over from scratch - it was quite frustrating, really.