I just got an HTC Droid Incredible last Thursday, so naturally I've been playing with it nonstop. It is admittedly my first smartphone, though I've owned my iPod Touch 2g for almost a year so I am well acquainted with apps. So far I really love the Google Android OS, which I expected given that Lifehacker recently recommended it over the iPhone OS for geeks. But nothing about the phone gave me more joy than a spinning cube.
Last night, I downloaded the Android SDK, installed it into Eclipse, and wrote some Java to create an app - a spinning colorful 3D cube, hardware accelerated with OpenGL ES. After it ran perfectly in the emulator, I connected my phone, installed drivers and ran a command to transfer it. My "OpenGL Test" app may not be any more than a spinning cube with no interaction, but to see it run on my phone screen is so rewarding, especially after so little time and effort.
And as I posted on Facebook shortly after: "I've had my iPod for
one year; Apple requires a Mac to develop for it, so I have done
nothing as far as coding on it. I've had my Incredible for 5 days; I
just developed my first mini Android app, a spinning 3D cube, and
deployed it to my phone." I think this is a definite win for Android, Java, and Eclipse!
If you have an Android phone and haven't touched the SDK, go give it a try! It's daunting at first but I promise it's not very hard!
Anyway, the whole reason I wanted to write this post was to ask about IBM and the Android Market (the equivalent to the iTunes App Store). IBM has no presence there! If we are trying to be leaders in Java, would it not make sense to develop some Android apps in Java, alongside our other Java initiatives?
For example, I think a slim WebSphere console would be neat. Let's say it's 3AM and IT guy Bob Smith is woken up by a call from a client; their web application is being hacked into, they're in a panic, and they want it to be taken offline immediately to stop the attack while they fix it. Normally, Bob would get up, run into his home office on the other side of his house, turn on his computer, VPN into his company, connect to the WebSphere server, and then stop the application. But what if it was as easy as hanging up with the client, tapping the WebSphere app, and tapping the stop button next to the client's web application. He wouldn't even have to get out of bed, not to mention the time saved.
Do you think this is something that IBM, or more importantly IBM's clients, would find desirable? Is there a reason for IBM's neglect of the Android Market?
Matching: java X
I have spent much of today exploring that question: what is a Web Service? It is a concept that is tough to nail down, because it is only an idea. Its implementation varies widely.
If I were to give the most brief definition of a web service, I'd say that a web service is a server program on a network (usually the internet, the "web") that processes and typically responds to messages sent to it in its protocol.
Let's break that down:
A web service is a server program. It runs on a server -- a beefy computer which is made to be extra reliable so that it can run 24/7/365 in a data center. An "application server" is a program whose sole task is to allow for easy installation ("deployment") and control of server programs, and WebSphere is an application server.
A web service is on a network. It reacts to messages that it receives from that network; if it weren't connected to a network, then it wouldn't do much of anything. And of course, the most comprehensive and accessible network is the Internet, so what better network to connect to? However, some web services (for example, a corporation's payroll system) are kept off of the internet, and restricted to only a subnet of computers. The web service itself functions the same either way, and doesn't care (or know) whether it is connected to no computers, one computer, or the entire web.
A web service processes, and typically responds to, messages sent to it. Web services don't usually do things on their own, though the possibility certainly exists (for example, one web service might want to poll another web service at specific intervals). But their main function is to receive a message from a client, process that message, and optionally send back a response. A web service does this for a large number of messages from a large number of clients at the same time.
A web service has its own protocol. Whether it uses a standard protocol such as REST, or the designers invent a totally new protocol, each web service has a specific language, or protocol, that it "talks" in. The client program is expected to interface with the service using this protocol, and some clients are custom written for the web service, while others use a common protocol such as HTTP (in which case the client would be a web browser or HTTP library).
So a web service is just about anything that communicates to clients in order to provide a service. In fact, this website that you are reading from right now was handed to you by a web service, and it used the HTTP protocol to receive the browser's "GET" request and respond to it with the contents of the webpage. It is providing your browser the service of fetching dynamic HTML documents. If you are listening to Pandora or another internet radio, the radio software is similarly interfacing with a web service, which provides the service of streaming audio to your computer over the web.
Now that I'm clear on what web services are and I have learned about some protocols such as REST and SOAP, my next step is to explore Rational Application Developer for WebSphere in-depth and make my own web service for practice, so that I'm ready to teach the process to others! Along the way I hope to learn even more about web services and the way that WebSphere hosts them! Please feel free to leave any suggestions for learning material below; for now, I'm combing developerWorks for anything of interest (such as this introductory article on web services).