Introduction to Service Oriented Architecture (SOA)

This article describes the concept of SOA (Service Oriented Architecture), its benefits, SOA with Web Services, choosing a platform to implement SOA and other related topics. The author recommends implementing SOA right now to survive in this competitive world.

Any IT organization consists of many different parts, each of which contributes equally toward the goals of helping IT meet business needs. Each of these parts has specific requirements for management as below:

  • Systems
  • Networks
  • Applications
  • Information
  • Services
  • Processes
  • Databases
  • Repositories
  • Integrations
  • Warehouses
  • Migrations
  • And more

There are further enormous changes and challenges where IT is facing the demanding requirements from real world business needs today. After several years of challenges and ups and downs from Y2K, Internet, the dot.com backlash and IT downturn of the first part of this decade, we’re finally raising our heads.  The main change that IT is currently undergoing is the shift to Service Orientation (SO) which is completely based on open standards-based computing. The perspective of IT functionality toward SO is being available as discoverable services on the network. Service orientation hides the complexity of today’s heterogeneous IT environments from business users.

For this service-oriented world to become a reality, however, companies must move to a new architectural approach known as Service-Oriented Architecture (SOA). SOA is architecture that represents software functionality as discoverable services on the network. A pure architectural definition of an SOA might be “an application architecture within which all functions are defined as independent services with well-defined invokable interfaces, which can be called in defined sequences to form business processes”.  Only a technical person can understand this definition. I’ve included a simplified version of this definition in the summary at the end of this article.

Service-oriented architectures are nothing new; the Common Object Request Broker Architecture (CORBA) and the Distributed Component Object Model (DCOM) have long provided similar functionality. These existing approaches to service orientation, however, suffered from a few difficult problems like tightly coupled scenarios.

{mospagebreak title=Web Services and SOA}

The combination of Web Services and SOAs resolves the issues of CORBA and DCOM approaches to SOAs. Now Web services have removed another barrier by allowing applications to interconnect in an object-model-neutral way. For example, using a simple XML-based messaging scheme, Java applications can invoke Microsoft .NET applications or CORBA-compliant, or even COBOL, applications. So, IBM CICS or IBM IMS transactions on a mainframe in Singapore can be invoked by a .NET application which in turn may be invoked by an agent running on an IBM Lotus Domino server in Munich. Best of all, the invoking application doesn’t have to know where the transaction will run, what language it is written in or what route the message may take along the way. A service is requested, and an answer is provided. Web services is a set of enabling technologies for SOA, and SOA is becoming the architecture of choice for development of responsive, adaptive new applications.  

The success of many Web services projects have shown that technology does exist that can enable you to implement a true SOA. SOA can be both an architecture and a programming model, a way of thinking about building software. An SOA enables you to design software systems that provide services to other applications through published and discoverable interfaces, and where the services can be invoked over a network. When you implement an SOA using Web services technologies, you create a new way of building applications within a more powerful, flexible programming model. You can reduce your development and ownership costs-and your implementation risk.

It’s important to understand that Web services does not equal SOA. Web services is a collection of technologies, including XML, Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discover and Integration (UDDI), which allow you to build programming solutions for specific messaging and application integration problems. Over time, these technologies can be expected to mature, and eventually be replaced with better, more-efficient, more-robust technology. But for the moment, the existing technologies are sufficient, and have already proven that you can implement an SOA today. SOA is the next wave of application development. Web services and SOA are about designing and building systems using heterogeneous network-addressable software components.

{mospagebreak title=Benefits of SOA}

Architecturally, the modern enterprise architecture design could involve:

  • Service Oriented
  • Event-Driven
  • Loosely coupled
  • Aligned with life cycle support processes
  • Able to support assembly and integration
  • Able to leverage existing applications and infrastructure

SOAs offer the following advantages over traditional approaches to distributed computing:

  • They offer business services across the platforms
  • They provide location independence
  • Services need not be at a particular system or particular network
  • Completely loosely coupled approach
  • Authentication and authorization support at every level
  • The search and connectivity to other services is dynamic

Short-term benefits of implementation:

  • Enhances reliability
  • Reduces hardware acquisition costs
  • Leverages existing development skills
  • Accelerates movement to standards-based server and application consolidation
  • Provides a data bridge between incompatible technologies

Long-term benefits of implementation:

  • Provides the ability to build composite applications
  • Creates a self-healing infrastructure that reduces management costs
  • Provides truly real-time decision-making applications
  • Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners

Benefits from the perspective of Business Value

  • Ability to more quickly meet customer demands
  • Lower costs associated with the acquisition and maintenance of technology
  • Management of business functionality closer to the business units
  • Leverages existing investments in technology
  • Reduces reliance on expensive custom development

{mospagebreak title=Which is best suitable for SOA: .NET or J2EE?}

Which is best suitable for SOA: .NET or J2EE?

This is the most complicated question among many people. Microsoft claims that its architecture is great; similar claims come from Sun also.  None of them could beat each other in any of its technologies. No one can give an immediate decision or solution to any of such questions. 

Although the rivalry between .NET and J2EE continues, neither platform is expected to dominate business-application development in the near term. Instead, their roughly equal capabilities will win roughly equal market share for .NET and J2EE. That means the two technologies will be used in 80 to 90 percent of business-application development over the next five years. 

Both .NET and J2EE are good platforms for developing and hosting business applications. Both support n-tier architectures via client- and server-side component models for assembling enterprise applications. This allows for use of either fat or thin user interfaces with both platforms.

However, .NET and J2EE are far from identical, and each platform has distinct strengths. The primary strength of .NET is its use of multiple programming languages running on a single platform. This eliminates the programming language as a barrier for adoption. Further .NET strengths include ease of use and speed of development as programmers might be transitioning from COBOL or C. (In contrast, transitioning to Java usually takes greater skill in object orientation.)

J2EE takes .NET’s multiple programming-language/single-platform paradigm and turns it around: The primary strength of J2EE is its use of a single programming language capable of running on multiple platforms. This eliminates the platform as a barrier for adoption. Further J2EE strengths include vendor neutrality and the active involvement of a large, open-source community.

From an integration standpoint, JDBC is actually more promising than J2CA. This API provides access to virtually any data source, from relational databases to spreadsheets and flat files. With a JDBC driver, all corporate data can be connected, even in a heterogeneous environment. In addition to its support for actual relational databases, JDBC can also support emulated relational models based on legacy information sources. But to do this, JDBC requires an integration product that can map the legacy-application functions to emulate a relational database model. The .NET platform, with its dependence on Microsoft BizTalk Server, has the same drawbacks for legacy-application integration as it does for packaged-application integration. So, despite the very real integration potential of .NET and J2EE, both platforms have their associated limitations. And when it comes to legacy-application integration, neither platform can complete the job on its own.

Although Web services were not conceived as an integration technology, they can be effective in the application-integration process. Web services provide a standard way to expose application interfaces through XML (Extensible Markup Language) and WSDL (Web Services Description Language). They also use a standard way to communicate, via SOAP (Simple Object Access Protocol). These features help reduce the cost and complexity of integration, as well as the cost and complexity of building new applications. Web services are made even more interesting by the fact that they are supported by both .NET and J2EE, and run equally well on both platforms. Therefore, Web services are ideal for bridging the two platforms.

Only large businesses are in a position to adopt both .NET and J2EE, due to two circumstances: 1) they have sufficient resources to train their development staff on both platforms, and 2) they have the capacity to develop best practices for managing environments that include elements from both platforms. Unlike very larger counterparts, small and midsize organizations won’t have the luxury of supporting both platforms simultaneously. Due to limited resources, they will probably be forced to choose between .NET and J2EE. And because Microsoft has established a strong presence in small and midsize businesses, .NET can reasonably be expected to prevail in this market.

{mospagebreak title=Summary with Simple Definitions}

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. The combination of services – internal and external to an organization – makes up a service-oriented architecture.

If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. Services are what you connect together using Web Services. A service is the endpoint of a connection. Also, a service has some type of underlying computer system that supports the connection offered.

The technology of Web Services is the most likely connection technology of service-oriented architectures. Web services essentially use XML to create a robust connection.

Any suggestions or feedback are welcome. Please click Discuss or the author link for the author’s email.

[gp-comments width="770" linklove="off" ]

chat