Chambers Final Essay


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Chambers Final Essay

  1. 1. James Chambers CPSC 5555 July 24, 2007 Final SOA Summary During this semester I learned quite a bit about Service Oriented Architecture (SOA). I learned that SOA came about as an evolutionary process. The ideas of which stemmed from lessons learned with programming languages, distributed computing, and business computing. Specifically, the concepts of breaking down a business process into individual manageable pieces, configuring those pieces at a coarse level of granularity, and utilizing a distributed network to offload work onto multiple machines were attributed. The motivation behind creating an SOA was that businesses wanted a solution to utilizing as much assets as they could from there enterprise’s existing application landscape. Most of which were riddled with heterogeneous middleware and technology. Prior attempts to alleviate this “headache” failed. These attempts included standardization efforts via technology (e.g. Enterprise Data Model & Enterprise Service Bus). SOA was and has proven to be an acceptable solution. The success can be contributed to the fact that it is neither a technology nor a standard. It can be considered more of a set of guidelines. These guidelines are technology-independent, high-level concepts that provide architectural blueprints. The blueprints help to define the creation of an architectural landscape that allows the components of that architecture to be created independently yet integrated globally. More importantly the architecture is founded around the idea of breaking the entire business process down into smaller components of business functionality. Each component of functionality is a derivation of the overall business process and manifests itself in autonomous units called services. Hence the title “service” oriented architecture. All service oriented architectures are based on four key components: application frontends, service, service repository, and service bus. The application frontends are considered the initiators and controllers of the application landscape. These components are responsible for forcing input through the system and gathering its output. Services represent the fundamental building blocks of an SOA. Their purpose is to execute various aspects of business functionality. Service repositories provide a means for the storage and discovery of services. Lastly, service buses are the components that connect the application frontends with the services. There are essentially three stages of an SOA. The stages include the fundamental SOA, the networked SOA, and the process enabled SOA. The most basic being the fundamental SOA and the most advanced being the process enabled SOA. As you progress from stage to stage, you essentially provide additional services with an increased amount of functionality. The initial stage creates basic services that encapsulate functionality to store, update, and delete data as well as functionality to execute computational algorithms. The following stage introduces intermediary services which help to bridge technical gaps within the network. Finally, the last stage introduces process centric services which help to encapsulate the functionality of a business process.
  2. 2. Enterprises that make it to this stage are said to have a fully leveraged SOA. At this stage one’s application landscape can consist of thin application frontends which are primarily responsible for calling services (which do most of the work) and displaying results. The progression from the Fundamental SOA to the Process Enabled SOA follows a logical path. For this reason, the systematic progression along this path is recommended for companies wishing to start their own SOA. Companies such as Duetsche Post AG and Winterthur have been relatively successful in implementing their SOAs. The key to their success was securing the appropriate budget, choosing a suitable project to start with, setting up a strong SOA team, and finding the appropriate budget. This strategy is referred to as the four pillars of success. Because their SOAs were a success, they were able to reap the main benefit of an SOA. That benefit is the creation of an agile enterprise in which processes and services are completely flexible. Their SOAs allowed both business and IT sides of the house to come together and develop the enterprise infrastructure with a common ground of communication (i.e. services). In the end, their implementation of an SOA will allow them to quickly reconfigure their infrastructure to meet the needs of their ever evolving business processes. Web Services Summary In edition to learning about the Service Oriented Architecture (SOA), I also learned about web services. Web services are just one means to implement an SOA. Specifically, a web service is “a software system designed to support interoperable machine-to-machine interaction over a network.” To facilitate interaction, web services utilize the following industry/web standards: • XML – This is referred to as “the format” behind web services. Essentially XML is an extensible markup language designed as a way to mark up a document and expose its structure for machine processing. • SOAP – This can be considered “the language” behind web services. SOAP is a mechanism that utilizes XML to define the unit of communication in order to facilitate cross platform distributed computing. It contains a flexible mechanism for data representation, a convention for RPC’s and responses, and a protocol binding framework. • WSDL – This can be thought of as “the describer” behind web services. A WSDL is essentially an XML based document that describes who, what, were, and how about a service. Particularly, it serves as a definition of a service and can be stored in service repository. This definition is read by service requesters to determine if they need that service and how they can invoke it if they do. • HTTP – This is the typical means of transporting web services. More specifically, it is the mechanism for transporting XML across the distributed network. Once transported, XML is marshaled and unmarshaled at both the client and server sides to enact the functionality of the service. In class we learned how to used HTTP, WSDL, and SOAP to create, publish, and consume a web service. Though we did not have the chance to implement one, we also
  3. 3. learned about the UDDI registry. UDDI is not considered a service repository. However, it provides similar functionality. Specifically, it provides a mechanism to describe services and a means to both statically and dynamically discover them. Has this course change any of your ideas about Enterprise computing? Yes. I originally thought about tackling enterprise computing from a technology specific approach. Specifically, I thought that standardizing the enterprise through use of data models or enterprise-wide middleware was the key. After reading the case studies and arguments presented in this book, I was made aware of the fact that companies that have gone this route have failed. In the end, they ended up creating an application landscape riddled with heterogeneous technologies. Taking the SOA approach just seems like common sense. You are now breaking down business processes into sub components (i.e. services) that have a coarse level of granularity. This provides them the potential to be reused across multiple parts of the enterprise. More importantly, the SOA process of creating those services provides a common ground for communication between the business and IT sides of the house. I discovered that taking the SOA approach necessitated an organizational shift within the companies that implemented them. Deutsche Post AG and Winterthur were forced to reorganize the structure of their business processes (e.g. into domains) as well as insert SOA Teams into their business hierarchy. These teams included Architecture Boards, which regulated the process of creating services, and the evangelizing teams which were responsible for broadcasting and teaching the benefits of SOA. In all, I’d say that SOA has changed my entire perspective of enterprise computing. As a developer, I now have to think in terms of coarse-granularity and stateless communication (when possible). As a manager, I now see the future of our infrastructure not only needs to change from a technological level but at a business level as well. This directly equates into the creation of new positions and regulatory bodies (e.g. Architectural Boards) not currently in place. What material was completely new / familiar? I was already familiar with the idea of web services. I knew that creating them allowed for a specific level of abstraction. Specifically, by creating a web service, I could consume it via a standalone application, a web application, or even various operating systems. However, I was not familiar with the concept of a service oriented architecture (SOA) or more importantly that a web service was a means of accomplishing one. I now know that building web services go way beyond bridging technology, it is part of a greater concept and that concept is the SOA. To be successful in implementing an SOA, one must carefully consider what should and shouldn’t be distributed (e.g. private vs. public services), the ramification of distributing services (e.g. utilizing security mechanisms across heterogeneous networks), and bridging heterogeneous technology (e.g. middleware such as MOM, distributed objects, etc.). In all, I would say I now have a better idea about the many facets of distributed computing. More importantly, I now see SOA as a solution to “bringing it all together.” Does this material have application in your current work environment?
  4. 4. Yes. I am currently working on creating an enterprise web portal. My original design involved creating teams of programmers and assigning each team to a specific business unit. From there we were going to take a uniform approach of development. Specifically, we were going to independently tackle each units needs by creating applications using C# and integrating them via ASP.NET. Though this approach may work, it will tie us into a specific vendor (i.e. Microsoft). More importantly, it is limiting its ability to be re-used. If our company is ever purchased, some if not all of it may have to be re-engineered during the merger. This is especially true if the new company brings a J2EE environment. However, if I can take the SOA approach I should be able to future proof our technology. Specifically, I can follow Winterthur’s approach of defining domains. In my case, each business unit correlates to a specific domain. I could then refine the functionality of those domains down into services. While defining them, I would make sure to leave the services at a coarse enough level so as to maximize their potential for reuse. For example, the Marketing department asked me to create a contact management system. Their system had a need to track what contacts they made, when they made them, and what came out of those meetings (i.e. specific contracts awarded). I can see myself now creating various services from this requirement. The first would be a basic service that allows individuals to create, update, and delete contacts. This would not only come in handy for the marketing department but may also come in handy for our HR department. If I abstract this enough I could allow them to use it to manage potential new hires (i.e. contacts) for a job position. Overall, SOA has opened my eyes. It is a new approach that needs to be looked into. Before I continue with my original plans, I plan on talking to my engineers to discuss using our web portal as our entry into the SOA. Specifically, I may use the contact management system as the pilot project. It has wide spread visibility, limited risk, and the support (budget and multiple departmental manages backing it) needed to make it a success. What material should be included if the course is taught again? What chapters were most helpful? Just about everything taught in this class should be taught again. However, I found a lot of redundancies between the two books. My recommendation would be to start at chapter 4 in the ESOA text. The information contained in the first three chapters was pretty much repeated in the rest of the text. In general, everything up to chapter 14 was excellent. I really thought chapters 14 – 17 were good. However, the greatest benefit from these chapters could be obtained by simply reading the section on lessons learned. In regards to the BWSWJ text, I recommend all of the chapters taught in this class. I really liked having the opportunity to create a web service and consume it. Given enough time I imagine someone could use Axis to create a UDDI repository. It would have been neat if we had one in place for everyone to publish their own service and have the means to locate and consume them. I think this would have brought all parts of the SOA into play. Which book was most helpful? Both were beneficial. ESOA helped introduce the concepts. The BWSWJ text helped me solidify the concepts with an actual example. From an applied approach the BWSWJ
  5. 5. provides more of a hands-on approach. As a programmer I like this approach. However, one of the things reiterated in our ESOA text was that an SOA benefits both the technical and business sides of the house. By choosing only the BWSWJ text, you would be limiting the benefit to just IT students. I could foresee business majors getting a lot out of this class as well. Perhaps this class would be the prelude to another class on Business Process Management Systems. Did producing an on-line lecture help you come to grips with the material in the chapter you were assigned? Most definitely. I was assigned Chapter 4 which looking back at it now doesn’t seem that difficult. However, at the time SOA was a new concept and I had a hard time conceptualizing what it was. While preparing my on-line lecture for the class I found myself reviewing other sources. This helped to fill in the gaps that the book left out. Moreover, it gave a much greater understanding of the material.