Finale: Services

The final component of an Internest transaction that we are going to look at is the Service.  There are many definitions of what a service is, but for the purpose of this article, a service is a set of standards that software platforms can use to talk to other software platforms to get and transfer information without a human component.  Below is a diagram of a general set of these standards that are used: a Security component, a Reliable Messaging component, the Transaction, the actual Message and it's language (XML in this case), and the Metadata to put it all together.

There are couple commonly used technologies when discussing Services: SOAP, XML, and WSDL.  SOAP and WSDL are both protocols that utilize the XML language.  Soap is "a lightweight protocol for the exchange of information in a decentralized, distributed environment" and acts as a virtual envelope to send data.  WSDL is then used as the diction and syntax to the message that allows completely different applications to communicate with each other, very similar to the Universal Translator in Star Trek.

The idea of a Service has been around a while, they just have not always been publicly available or documented.  Microsoft is infamous for it's products interoperability, and the words "web service" were first documented as being uttered by Bill Gates at a developer's conference.  EDI was the first to try to develop some type of data interaction.  However, it ended up being costly and hard to implement.  Then once the Web starting gaining ground, SOAP was developed, and that opened the door to the Web service we know today.

http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%202007-02.pdf

Additional Resources:
http://en.wikipedia.org/wiki/Web_service
http://www.w3schools.com/webservices/default.asp
http://www.webopedia.com/TERM/W/Web_Services.html
http://www.businessweek.com/technology/content/feb2005/tc2005028_8000_tc203.htm
http://ws.apache.org/
http://www.ibm.com/developerworks/webservices/
http://msdn.microsoft.com/en-us/library/ms950421.aspx
http://www.innoq.com/resources/ws-standards-poster/
http://www.informationweek.com/news/6506480

Episode 5: Data Storage

The last two parts of the Internet transaction have become specialized throughout the years.  The first is data storage on the server level.  Most people understand data storage on your desktop.  Your hard drive space on your desktop limits you to the amount of documents, videos, and pictures you can store.  Well, this premise can be applied to servers as well except now it's even more important to make all the stored information easily accessible and fast.

There are a couple of different ways to go about data storage on the server level.  You can combine it with your application server if you are running a small environment.  Or it can be its own standalone server.  It can be a SQL database server or a regular file structure based system.  Some examples of storage systems include HP's blade storage system or Apple's XSAN.

Over the years, the idea of storage on a server level has grown.  It initially didn't exist; you had to save back to your computer locally.  But just as with the other services that we've looked at, the demand to collaborative and Internet based business demand storage availability on the server level and in came the NAS solution (network attached storage).  There has since been many advancements in the NAS with RAID algorithms, redundancies built-in, and the SAN, the storage area network.

Windows Storage Server Releases:

Additional Resources:
http://en.wikipedia.org/wiki/Computer_data_storage
http://welcome.hp.com/country/us/en/prodserv/storage.html
http://www.open-e.com/service-and-support/products-archive/products/open-e-dss/
http://blogs.technet.com/b/storageserver/archive/2008/06/09/a-brief-history-of-windows-storage-server-releases.aspx
http://en.wikipedia.org/wiki/Storage_area_network

Episode 4: The Application Server

The next part of the transaction I'll be discussing is the Application server component.  An application server is simply as server that provides an environment for various applications to run.  For example, the Microsoft Exchange server is an application server that runs the Microsoft Exchange application on a Windows Server platform.

The options for an application server are many.  There are a couple of main server platforms as we discussed earlier: Microsoft Windows Server, Solaris, and Linux based such as RedHat.  There are many more types and proprietary platforms as well that are developed for specific applications.  Then on top of all of these platforms, you can run your server applications such as  Microsoft SQL Server.

Over the past years, the definition of an application server has been developed, and its place in the schema defined.  The number of applications that can now be provided on a server level as drastically increased as well.  Application server were initially just static web servers, but with the increase in business online and business platforms that needed to be provided online, they have developed into the massive and various platforms they are today.

Additional Resources:
http://en.wikipedia.org/wiki/Application_server
http://www.answers.com/topic/application-server
http://www.theserverside.com/news/1363671/What-is-an-App-Server
http://technet.microsoft.com/en-us/library/cc750283.aspx#XSLTsection130121120120
http://www.javaworld.com/javaworld/javaqa/2002-08/01-qa-0823-appvswebserver.html
http://searchsqlserver.techtarget.com/definition/application-server
http://java.sys-con.com/node/36451

Episode 3: The Web Server

The next stop on our adventure is the Web Server.  The web server is key to storing and retrieving data on the Internet.  Web servers make web pages possible, which without most people would not have a use for the Internet.  A web server is made up of two components: the hardware that it runs on and the web server software itself which turns a regular server into a web server.

A client uses a web server every time they access a website.  For instance, you are reading my blog right now which is hosted on a web server owned and operated by Blogspot.  You more than likely got here either through a Google search (also a website) or via a direct link.  The direct link should clue you in to a few things.  One, you are accessing my server space here: http://rmoorehead-mist7500.blogspot.com/ then if there is anything after the slash you are access an individual file on the server.  If there is nothing after the slash, you are still accessing a file, you just don't know it.  You are accessing the index file.

So in essence, a web server is very much like navigating your desktop with a file structure of folders and individual files.  The magic comes when a web server receives requests and processes them and sends them back out via the Internet.





The hardware requirements for a web server are pretty basic:  a large storage space, a fast processor, and a permanent IP.  If you'd like to read more about the differences between a regular desktop and a web server, please review this article.  The software is where the fun part comes in.  There is huge competition in the web server arena between Microsoft's IIS platform and the Unix-based Apache offering with Sun bringing up the rear with some specialization optimizations.

Web servers just like user's browser clients have developed over the years.  The concept of the web server and a central repository of information was developed by Tim Berners-Lee in 1989.  And due to it's popularity, Berners-Lee initiated the W3C, the World Wide Web Consortium, to regulate the web he helped to build in 1994. Since then, the concept of a web server has grown.  We now can have virtual web servers and web servers based in a cloud environment in essence taking the hardware component out of the picture.

http://news.netcraft.com/archives/2011/11/07/november-2011-web-server-survey.html

More Resources:
http://en.wikipedia.org/wiki/Web_server
http://www.webdevelopersnotes.com/basics/what_is_web_server.php
http://computer.howstuffworks.com/web-server.htm

Episode 2: The Internet

  

http://www.opte.org/

Onward!  We shall now traverse through the Internet!  According to the Oxford English Dictionary, the Internet is "a computer network consisting of or connecting a number of smaller networks, such as two or more local area networks connected by a shared communications protocol." [1]  But I think we all could have guessed at that by now.  The Internet has been compared to the Universe model many times as it's a network of stars.  The Internet is made up of two basic technology components:  protocols and structure.

The Internet is defined by it's protocols as you saw in the Oxford English Dictionary's definition.  It's based around hardware and software level protocols.  The hardware that builds the Internet (and it's networks) include routers and switches.  You can read more about routers in one of my earlier blog posts.  The main software level protocol is the IP (Internet Protocol), which is defined and maintained by the Internet Engineering Task Force (IETF).  More about the protocol suite can be found here, but basically, it's made up of several layers of protocols and standards.  The structure of the Internet is based around the "scale-free" network, which is mathematically explained here but basically, the frequency of use by each node in the network determines how many connections that node has to other nodes.  The structure of the Internet is still being debated, but the scale-free model appears to be the best-fit.

http://www.internetworldstats.com/stats.htm

The Internet as we know it began development in the late 1960s, early 1970s, with ARPANET and Mark I.  You can find a timeline of events here if you are curious.  Individual groups in education and government worked to develop local area networks that they then interconnected.  With the birth of email in the late 70s, the idea of a public network was introduced.  Then the IP protocol was defined in the early 1980s to standardized all communications.  Also in the early 1980s, the personal desktop became a reality introducing more nodes to the network.  And it has grown in leaps and bounds since then into what we have today.

http://img.labnol.org/di/periodictableoftheinterum5.jpg

More Resources:
http://computer.howstuffworks.com/internet/basics/internet-infrastructure.htm

http://en.wikipedia.org/wiki/Internet#Technology

Episode 1: Client Technologies

     As I mentioned in the crawl, I'm going to be starting a 6 episode discussion reviewing some of the basics of Internet Technology.  I'll begin discussing these topics from the client end of the spectrum through to the data end.  Client side web technology can be a very broad topic, but basically, it's made up of three components: the client's platform, the client's software, and what technology is being utilized locally.

The client's platform can be a desktop, laptop, tablet, or mobile device (basic web capabilities or a smart phone); Windows, Mac, Unix, Android, Symbian.  Here are some neat statistics from the website w3schools.com on the platform market share right now for their website.  Basically, Windows has been a dominant market share for a while, but it's starting to lose ground to mobile devices.  The client's software also must be taken into consideration.  There are multiple Internet browser versions available such as Google Chrome or Mozilla Firefox.  Also a client can use an installed application to access resources on the web such as MySQL Workbench or the Evernote mobile app.  Below is a nice graph indicating where we are now with browser distribution.

http://en.wikipedia.org/wiki/File:Wikimedia_browser_share_pie_chart.png

The technology that is being utilized locally is always changing.  Some of the staples include HTML/cascading style sheets (css), JavaScript, AJAX, and XML.  These all come together to define  what's called the Web 2.0 phenomenon.  You can read more about that here on HowStuffWorks, but basically, different platforms and software can render these different languages into usable information for a user in a graphical user interface, most of the time.  Some people still enjoy their black screens with white text.

http://en.wikipedia.org/wiki/File:Timeline_of_web_browsers.svg

So how has this all developed over the past few years?  Well, one word could sum it up: drastically!  Most major companies such as Microsoft and Apple put out a new line of products (platforms and software) at least each year so the client technology development had to be constantly changing to keep up.  You can read on HowStuffWorks their articles on Web 1.0 and where they think we are going with Web 3.0.  You can also read about the evolution of HTML and where it's going with HTML5.

Additional Resources:
http://en.wikipedia.org/wiki/Client-side
http://en.wikipedia.org/wiki/Web_2.0
http://en.wikipedia.org/wiki/History_of_the_web_browser

Developing in an Ever Mobile World

This week in class we had the opportunity to listen to Chuck Hudson from Control4 speak about mobile application design.  He opened up his talk with a discussion on the "device market", and it's recent revolution from the mobile way of thinking.  It's not about the fact that it's mobile, it's about the devices that client's are trying to connect with, i.e. smart phones, tablets, TV, car displays.  He spoke a bit about the major market players and the market trends.  Android and iOS are leading the pack in the U.S.  He then detailed out the various markets that individuals apps can fall into:

• pure application sales
• outside mobile license
• advertising supported
• referral/affiliate fee
• complimentary model
• in-app purchases

After that we dug right in to the meat of developing an application, starting with the design and the challenges faced by mobile development.  He shared with us the statistic that "1 in 4 apps downloaded are never used."  And that's huge.  There are so many considerations for determining whether an application is going to succeed such as the orientation, the envisioned usage, the platform, space size restrictions.  He also could not more highly emphasize the need to storyboard and protoype as well as test, test, test,  One prototyping program he recommended was Balsmiq (www.balsmiq.com).  He also highly recommended getting involved in user groups such as those located here: developer.android.com and developer.apple.com/ios.

After that, we broke it down to the platform level.  For the Android, we discusses screen resolution support
(4 generalized sizes; 4 size densities), graphics and layout complexity, device testing and compatibility, and device fragmentation.  When developing for the Android, the environment is open sourced (eclipse and the android sdk).  The key differences include a community fed library and diverse widget availability.  The example that we went over is located here.  When you are ready to distribute your app, you can upload it to a couple of different sites, but mainly the Android Martketplace or Amazon.  The process includes code signing, incorporating any marketing information, and submitting to each site.  You also should think about any legal action you'd like to take before making the application public.

We then spoke about iOS development.  iOS development uses an MVC design pattern that is coded in Apple developed objective C.  The development tools are more mature than the Android's since it's been on the market the longest and include xcode, an interface builder, and instruments.  Apple also has the iOS Ad Hoc Program to help get your product in beta testing.  To release your app to the public, you need to add your app, upload it via the Application Loader, go through the certification process by Apple, then release it when you are ready.  Some common issues experienced during this include improper UI usage, over-throttling web request pulls, and memory leaks.

After that we talked about the considerations that need answering before a deployment.

• Which OS versions do you support?  A good general rule is the current version plus one.
• How will licensing be handled?  A tip for handling licensing is to balance the level of licensing with the effort needed.
• Will you implement localization?  If so, how?  And how will you maintain it in the long run?  In-house, contractor, or community group?
• Beta Test, Beta Test, Beta Test.

Then we talked about how to measure your applications success.  It's unique to each application and it's developer, but you could gauge it by number of installs, amount of traffic, utilize any statistics available through the market, or even create your own measurement by using built-in logging.  You should also have a process ready for supporting your application.  Always welcome feedback, create new updates, and build in code support mechanisms.  A few tips and tricks that he left us with include:  know that development will always be a continual investment; market yourself, get out there and get noticed; test, test, test; and launch!  Don't hold back.  Always look back on your 1.0 version and be embarrassed.

Services! Get Your Services Here!

So what is a Web Service, you say?  According to the W3C, the World Wide Consortium that develops web standards, "a web service is a software system designed to support inter-operable machine-to-machine interaction over a network. It has an interface described in a machine-process-able format (specifically WSDL [web services descriptive language]). 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."  If that just sounded like a bunch of techno-babble, read on!  And hopefully, I'll explain it in plain English for you. 

A web service is a way that one server can speak to another server without any human interaction.  Many online functions can be done with web services, such as online web payments, fraud detection, and package tracking.  There are two primary categories of web services: the "Big Web" service and the "RESTful" service.

The "Big Web" service utilizes XML (extensible markup language), specifically the WSDL and the SOAP standard, to deliver interoperability for remote procedure calls (RPCs) and messaging integration between systems.  The WDSL, the web service descriptive language, is a way to describe the end points of a service call no matter of the format of the message.  The Simple Object Access Protocal (SOAP) is made up of three part: envelope that defines the architecture, a set of encoding rules, and a definition for representing RPCs.  SOAP can be used with many other protocols but primarily with HTTP and HTTP extensible framework.  A "Big Web" service that utilizes SOAP must have these three components:  a formal contract that defines how the web service will interact, must be able to handle complex nonfunctional requirements, and must be able to run asynchronously.  Here are a few examples of  "Big Web" services in action using AJAX: Big Web Examples (IBM)

The "RESTful" service, Representational State Transfer service, limits its architecture to a smaller, standard group of operations such as GET, POST, and DELETE for HTTP making it simple, lightweight, and fast.  This form of web service primarily focuses on stateful resources and the usage of clean URLs.  "RESTful" services can be created in three ways:  using WSDL and SOAP, as an abstraction on top of SOAP, or without SOAP at all. The design of a "RESTful" service is based around resource identification through URIs, having a uniform interface, using self-descriptive messages, and utilizing stateful interactions through hyperlinks.  Here is a similar example to the "Hello World" "Big Web" service example provided above, but this time developed using the "RESTful" implementation:  RESTful Example (Oracle)

So which one do you use?  When comparing the two types, there are four criteria to review.  The first criteria is how you want to use the web.  "Big Web" simply uses the web as a transport medium where as "RESTful" services use it for publishing information.  The next is how much heterogeneity is needed.  "RESTful" systems rely solely on HTTP data types where are "Big Web" is more robust and allows for more customization to connect to legacy systems written in different language such as COBOL.  Another consideration is how loosely coupled should the interacting systems be, or the client to server relationship.  "RESTful" web relies heavily on HTTP connections, but if the web server is down then no transaction can be performed.  This can be overcome however with dynamic late binding, where the server is located at the time of the transaction.  "Big Web" however does not have either the time/availability issue or the location issue.  "RESTful" web services are better suited for basic, ad hoc integration, such as most things over the web, and are relatively inexpensive to develop since they use a light weight architecture. "Big Web" services are better suited for when quality of service really matters, i.e. enterprise application integration.  "RESTful" web services are also better suited for web applications since most clients can consume them letting the server side evolve and scale.

Well that was a quick and dirty overview of the two main types of web services available.  Please check out the links throughout for some additional reading and my sources.