> developer > dnu > courses > Web Services page 2

Web Services

April 2003

DeveloperNet University Course

Reader Rating    from ratings

Introduction

We begin the course with a pretend scenario of a fictitious company. Let's say you are a developer for an online sports news company called NWSport. You and your team have been tasked to write an application that will provide news, information, and scores through the Internet to anyone that subscribes to your service. You have no idea what platform or even what device a subscribed user may be using, yet will provide them with an online web portal in which they can pick and choose the specific information they want to receive. For each sport-- they should be able to choose specific games or events to get "real time" news, scores and updates.

The news research team will update information and scores from a variety of locations throughout the US. The information must be delivered to a subscribed user's computer or other PDA device. Because of the global nature of this service, your company has out sourced, to other news research companies throughout the US and the rest of the world, the gathering of sport news and information. Their development teams will need access into the service to provide news and scores from the events they cover. How do you implement this type of subscription service?

Distributed Technologies Overview

Although this is a very complex problem, we have a variety of methods to choose from in order to implement the basic functionality of providing information in this type of distributed setting to users. Some distributed technologies we could consider are:

• Common Object Request Broker Architecture or CORBA
  
  
• Enterprise Java Beans or EJBs
  
  
• Distributed Component Object Model or DCOM
  
  
• Java Remote Method Invocation over Internet Inter ORB Protocol or RMI/IIOP
  
  

Each of these technologies is distributed in architecture or they are designed to be used in systems that are not centrally run on one local machine--but several machines spread out through multiple geographic locations. Each technology can be used to solve a piece of the problem. As with every software technology, each has its own set of pros and cons that we must consider in order to best solve the scenario and design our software system to be effective and efficient.

A detailed explanation of each technology is beyond the scope of this course, but we will review pros and cons of each one in our effort to design our Sports information system.

Common Object Request Broker Architecture.  CORBA could be a great technology to use in this scenario because it is language independent. It relies on an Object Request Broker or ORB object in order to remotely call another object. The ORB object must be implemented for the platform you are going to run. CORBA can be extremely complicated to write and would require a steep learning curve.

Enterprise Java Beans.  EJBs actually do play a role in Web Services today. Their purpose is to handle server-side business logic. The architecture of EJB is similar to that of a Web Service. An EJB uses a home and remote interface as well as the main Java class that performs the logic of the EJB. A client application remotely invokes an EJB passing data to it, to be processed. The EJB will most likely interface with a database to store and retrieve information and return the requested information back to the user after performing the logic of the EJB to the data. An EJB can be a part of the scope of a Web Service. The drawbacks of EJB include the complexity of building an EJB, large hardware and software overhead, and Java language dependency.

Distributed Component Object Model.  DCOM can be implemented in multiple languages, but like CORBA, relies on COM services so the platform must support COM services. It can also be very complex to implement.

Java Remote Method Invocation.  Java RMI is another good distributed technology. Unlike the previous two, it must be implemented in Java, but does not have the complexity that CORBA and DCOM systems have.

Web Services Scenario

As illustrated by these examples, these technologies offer good solutions, but can be complex, language or platform-dependent, and offer other complicating factors that make the design of our Sports News network difficult.

Our online sports news company scenario helps us to better understand what web services offer. Although the scenario lacks sufficient detail to properly solve the problem, it does help us understand what we can achieve with Web Services.

History of Internet Application Development

In the early days of the Internet, the trend in software development centered primarily on HTML. Web pages went from displaying simple web pages with information about companies to complex HTML layouts, colorful displays, and graphic intensive pages. The content itself was very static-- that is, each page was manually created by an HTML developer and manually edited. With the addition of web technologies such as Java, ASP, and databases, we could add more dynamic content to the pages. Now, web pages have transformed from a flashy display of HTML to more conservative displays of information. Web pages must now be able to offer dynamic content on requests regardless of operating system, platform, device, or browser. Now many web pages even offer real time content displays. It is the functionality of web services technologies that transforms purely static, flashy content; to more conservative, flexible, and dynamic content, capable of displaying numerous technologies.

Today's Software Development Industry

Before we begin to define Web Services, let's take just a minute to analyze the state and trends of today's software systems, and the challenges that Internet software must overcome. Software is becoming increasing complex. The scope of the business problems is expanding to include more and more functionality. The business requirements are extremely detailed and require the software to provide excellent service to the user. The following is a list of many requirements for today's software systems.

• Web enabled - In today's Internet world, nearly all software must be in the web space.
  
  
• Distributed architecture - Software is object oriented in nature and objects are no longer present on one local machine. Software must interact with objects through the Internet requesting and posting information.
  
  
• Device independent - Many devices will connect to the software system including PCs, PDAs, cell phones, laptops, etc.
  
  
• Platform independent - A variety of operating systems will connect to the software system.
  
  
• Robust and scalable - The software must be robust and scalable to accommodate 100s and even 1000s of users while maintaining acceptable performance for every connection.
  
  
• Separate data from presentation - Presentation layers, or the look and feel, should be separate from data layers so that as graphical user interfaces are re-designed, these changes will not affect the data layer of the software. The look and feel of the application, such as colors, fonts, and graphical components, can be changed without significant changes to other parts of the application.
  
  
• Fit in the budget- IT departments are strapped for funding and plagued by budget cuts, but required to implement new distributed applications. The development must not create more financial stress on departments that are already financially stressed.
  
  
• Limited development time - Even though the problems the software must solve are complex, the application should not be complex to develop. IT departments need to realize a rapid Return on Investment for their application and cannot afford to spend many months in development in today's competitive market.
  
  
• Must provide real time information - Software now must provide important information to the user. In many cases the user's job will depend on the information the software is to provide. The user wants to receive the information as close to "real time" as possible.
  
  
• Interoperability - It is also likely that the software will be part of a system made up of many software components. The software must interoperate smoothly with other software modules to collectively perform the functions of the software.
  
  
• Communication - Software may be required to communicate through a corporate network or Internet. In many cases, the software must be intelligible enough to communicate effectively.
  
  
• Proprietary - The software system itself could be proprietary and the technologies used to build the software could be proprietary. This makes it difficult to integrate the software system with other systems.
  
  

Each of these points is a problem that should be addressed when the software project is launched. They are valid business and technical problems that must be solved. Most of the applications written, address these needs in some way. It is important to take these into consideration when you build web application software.