You are on page 1of 4

Dev Shed 05/29/2007 01:21:07 AM

Web Services
Introduction to Service Oriented Architecture (SOA)
Contributed by Jagadish Chatarji
2004−10−13
Unlimited Web Conferencing for One Flat Rate
GoToMeeting™ is the fastest, easiest and most secure way to collaborate online. Host unlimited meetings for an unlimited duration with
up to 10 attendees per meeting – all for one flat fee! Try it FREE!

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.

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

1/4
Dev Shed 05/29/2007 01:21:07 AM
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.

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

2/4
Dev Shed 05/29/2007 01:21:07 AM

• 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

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

3/4
Dev Shed 05/29/2007 01:21:07 AM
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.

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.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content
provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts,
and/or product reviews. As such it is incumbent upon the reader to employ real−world tactics for security and
implementation of best practices. We are not liable for any negative consequences that may result from implementing any
information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify
your hardware.

4/4

You might also like