Service Oriented Architecture Vision

J. Kelly Flanagan

Introduction

Sharing my vision of a service oriented architecture would be incomplete without describing my underlying philosophy that we must put the end-user in a position to create many of their own IT solutions. This philosophy is described in more detail in the document included as Appendix 1. The last paragraph of that document reads,

In summary, how do IT organizations become more productive? The answer lies in making it possible for everyday consumers of IT to develop their own IT solutions. An IT provider should enable this kind of self-service by defining the architecture, developing an IT infrastructure, acquiring tools, and developing training programs that all work together in accomplishing this goal.

The ultimate goal is to have numerous web services that are discoverable by end-users, an inexpensive development environment for creating additional services, a governance model for approving services, a workflow or business process management tool for linking services together to create applications, a web portal for exposing content to users, and underlying physical and virtual environments to run them. In addition, an authentication and authorization scheme must be in place to expose appropriate information to authorized users. Finally, all of this must be documented and training material created. With this in place end-users would be empowered to provide more of their IT solutions.

First Steps

It is not expected that the end goal be reached through a single project or initiative. However, it seems prudent that the initial project should create a robust underlying layer of infrastructure that is scalable and will be able to meet initial and future needs as we reach for the end goal. With this in mind allow me to outline my initial principles and requirements for our service-oriented architecture.

Principles

1. During the course of this project we will decide how to make decisions, will work within this framework to make decisions quickly, and we’ll work together to make decisions successful.

2. We will work to create an exciting SOA environment that we as individuals and as an organization can be proud of.

3. Our SOA will follow recognized standards where practicable and will deviate only when standards based solutions are not available.

4. Great thought and care will be given to acquiring technology for the creation of our SOA. We must have respect for sacred resources. Our choices should minimize total cost of ownership while maximizing flexibility and functionality.

Requirements

1. Services must be discoverable by end-users. Discovery may expose WSDL and other standard information.

2. Services must be consumable using REST and SOAP interfaces when possible.

3. Documentation, examples, and training must be available to describe the environment, discovery, and consumption of available services. This should be done in such a way as to not limit end users to a single OIT defined approach.

4. The system should provide policy based authorization and security.

5. The system should enable the forking of requests and the joining and comparison of responses to facilitate the testing of new versions of existing applications.

6. Requests and responses should be traceable to facilitate functional testing and performance monitoring and optimization.

7. The SOA should function in a scalable virtual environment. The addition of virtual resources with underlying physical resources will increase performance.

8. OIT should create several services to demonstrate that the system functions properly.

The above requirements should be met in such a way as to not jeopardize the future enhancements to our SOA. Future enhancements or requirements include:

1. OIT will provide end-users with a recommended web service development environment capable of creating services executable in the created SOA environment.

a. The development stack must be free or very inexpensive; cost should not be a barrier to use.

b. The development stack should be as easy to use as possible; complexity should not be a barrier to use.

c. The development stack should run in multiple user environments including Windows, Linux, and Mac OS X.

d. OIT should bundle this stack and make it available via our software distribution tool. This stack should be kept up-to-date.

2. OIT will provide training material describing the creation and use of local services and the governance process for escalating them to the enterprise level.

3. OIT should create numerous services. A couple of examples include:

a. A service similar to the EC2 offering by Amazon.

b. A service similar to the S3 storage solution offered by Amazon.

c. A service that allows users to determine if a student is registered in a particular course and section, is majoring in a particular college, department, or program; or in fact is even a student.

d. Others.

4. A standards based web portal will be provided as the standard user interface. The SOA should be created with this in mind.

5. Business process management tools or workflow systems will be employed to interface services to applications and to create applications by connecting services (mashups).

Appendix 1

Putting the Power of Technology within Everyone’s Reach

J. Kelly Flanagan

Introduction

Previous decades have shown a dramatic increase in the use of information technology in business, education, government, and elsewhere to assist in executing enterprise processes and accomplishing institutional objectives. It is likely that this trend will continue as the use of information technology spreads throughout the enterprise. However, it is unlikely that the space, funding, and human resources, allocated to information technology organizations in the past, will continue to increase significantly. So information technology organizations are faced with a daunting question; how do they serve their increasing base of information technology consumers without increasing their own demand on resources? In other words, how do they increase their productivity? One solution is for information technology organizations to produce tools that simplify the tasks of creating applications and accessing information so that previous technology consumers can become their own developers and producers. In essence they enable end-users, through appropriate self-service, to meet their own needs in a simple, inexpensive, and intuitive way, thus augmenting their technology staff with experts found in other disciplines.

As individuals identify the benefits of using IT to instantiate processes, they will require more from IT organizations, IT applications, and will require faster delivery. To meet this demand, IT organizations must increase collaboration, to add application functionality into their “infrastructure”, and expose them as “services” to the consumer. In addition, tools must be developed and integrated into the infrastructure that will enable end-users to easily combine these services into applications that meet their needs with little or no interaction with the enterprise IT provider.

Just a few years ago the term infrastructure brought to mind the underlying hardware that makes IT work. However, as technologies such as databases and operating systems become standardized, they too become part of the “infrastructure”.

As you think of a technology infrastructure stack, see Figure 1, with hardware components on one extreme and business applications on the other, the line dividing infrastructure from applications moves over time from the hardware end of the stack towards the application end of the stack. Successful IT organizations must consistently move this line upwards to increase productivity and meet business needs.

There are historical examples of this type of change. Not so many years ago providers of information were intimately aware of the types of servers and operating systems required to run their applications. However, today with many applications running in more abstract environments and with the results being distributed to the end-user via the web, few know or care what types of server or operating systems are being used to host their databases, application servers, web servers, etc. Several specific examples exist that support this hypothesis:

1. Business reporting tools such as Business Objects

2. Content Management tools such as Documentum

3. Portal technologies

4. Business process management tools

5. Service oriented architectures such as web services

Business Reporting

In the recent past business reporting was accomplished by writing custom applications to access the necessary databases, acquire the needed data, manipulate it, and present the results to the consumer in the desired format. This has changed. Tools such as Business Objects permit the information technology organization to build the traditional infrastructure plus data universes that define and contain the data elements available to the consumer. The tools keep the data contained in the universes synchronized with the associated databases. These well-formed universes are then exposed to an application, provided by the vendor, which enables the consumer to define and construct the desired reports. In this example the servers, storage, databases, tools to create universes, the universes themselves, and the application used to create reports have all become part of the infrastructure. The consumer no longer cares about the technology behind any of it, but simply knows how to run the application to generate the needed reports. The result is that the consumer can experiment with different views of the data without modifying the application, interacting with an IT development team, or expending a vast amount of time or money.

Content Management

Many organizations still use a manual process of creating, managing, and publishing content, particularly web content. In these cases the content is often created manually or with rudimentary tools and then manually placed on a server in an appropriate location to be published via a web server application. With modern content management systems (CMS) documents are created, submitted for review, reviewed and approved, and published to a web site via a workflow engine that takes much of the manual labor out of the process. The organization can concentrate on the content rather than on the process for maintaining it. The details have been hidden away in the infrastructure. The information technology provider maintains the appropriate servers, databases, workflow engines, and document management application and exposes to the producer of web content the user interface of the publishing application. The producers of web content see little of the underlying tools, but rather interact with a web based publishing tool that allows them to create content, get appropriate approvals, and publish without having to deal with the details.

Portal Technologies

A portal provides a standard user interface, a single point of entry to enterprise applications, and a single approach for user authentication, authorization, and personalization. By using a portal as the user interface for applications, the learning curve necessary to develop applications is lowered. As the application development process is simplified more members of the enterprise can become involved in developing their own solutions. Those who previously depended on the IT organization for solutions can now develop their own solutions. This essentially increases the number of IT professionals without increasing the IT organizations demand on resources.

Business Process Management and Service-Oriented Architectures

Business process management (BPM) tools allow users to graphically document the flow of information and documents that make up the processes necessary to meet institutional goals and objectives. Not only are the processes documented, but a BPM tool then makes it possible to automate portions of the process and even provide process metrics. During process execution, the BPM system interacts with various electronic systems such as email, ERP, and other applications to accomplish defined processes.

A service-oriented architecture (SOA) links independent services (provided by external as well as internal entities) using standard interfaces and communication protocols. A service-oriented architecture approach yields flexible, loosely coupled applications instead of traditional inflexible monolithic systems which are complex and expensive to change. Web services can be used to implement a service-oriented architecture.

The combination of a service-oriented architecture, such as web services, and business process management or workflow tools can yield applications that are similar to the processes they implement. This is beneficial to an organization because as they change processes it is very clear how an application must be modified to match. When a centralized IT organization uses this technique to create enterprise applications it must first implement the SOA and BPM tools and support them as infrastructure. When future applications are developed the workflow is defined, existing services are used where possible, and new services are created. The development of a few services and the workflow definition is within the reach of many outside the centralized IT organization. Again, this distributes the development of enterprise solutions and minimizes the need for growing the IT organization to meet the needs of the institution.

Summary