8/7/2019 SOA-REPORT (2)

1/45

1

CHAPTER 1

INTRODUCTION

1.1 OVERVIEW

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed

capabilities that may be under the control of different ownership domains and implemented using

various technology stacks. In general, entities (people and organizations) create capabilities to

solve or support a solution for the problems they face in the course of their business. It is natural

to think of one persons needs being met by capabilities offered by someone else; or, in the world

of distributed computing, one computer agents requirements being met by a computer agent

belonging to a different owner. The term owner here may be used to denote different divisions of

one business or perhaps unrelated entities in different countries.

There is not necessarily a one-to-one correlation between needs and capabilities; the granularity

of needs and capabilities vary from fundamental to complex, and any given need may require a

combination of numerous capabilities while any single capability may address more than one

need. One perceived value of SOA is that it provides a powerful framework for matching needs

and capabilities and for combining capabilities to address those needs by leveraging other

capabilities. One capability may be repurposed across a multitude of needs.

SOA is a view of architecture that focuses in on services as the action boundaries between the

needs and capabilities in a manner conducive to service discovery and repurposing.

The ultimate goal of a SOA is to have an agile IT environment unaffected by all the disparate

technologies that might be used to develop its services. SOA geniuses have long realized that the

nature of most organizations is composed of heterogeneous computing environments because

different business units perceive their needs differently from one another. Standardization of all

programming objects into one proprietary technology defeats the ultimate aim of enterprise

agility. Standardization should remove the locked chains of technology dependency. The put all

8/7/2019 SOA-REPORT (2)

2/45

2

your eggs in the same basket scenario must avoided or else reap the high risks and costs of

being locked and controlled by external forces.

To achieve this, SOA must be based on nothing else but Open Standards. Enterprises, just like

any member of our society, must take steps to protect themselves against the threats of

dependency. Open Standards level the playing fields and therefore vendors have no choice but to

work in the best interest of its customers. Customers can pick and choose freely based on the

quality of service and relations with vendors.

1.2 SERVICE-ORIENTATION

Service-Orientation is not really a new concept. Many IT pioneers and architects like John

Zachman have made exhaustive references to principles such as reusability and standardization

of IT components or parts. Many readers familiar with J2EE, .Net or Object-Oriented

Programming (OOP) in general will find the principles of Service-Orientation very familiar

(although services and objects are quite different in scope).

In Service-Orientation, a service is a business function area that can easily be converted into a

computerized Service (i.e. mostly a service built from information technology). The service

forms the building blocks (i.e. architecture) to be reused across the whole Enterprise in building

business applications. In modern or contemporary IT Shops, services are likely to take the form

of Web Services. Yet, some organizations have been using Service- Orientation theory quite

successfully since the 70s proving that Service- Orientation promotes application agility

regardless of the technology platforms.

If we program our applications using the newest technologies such as Web Services but are still

doing it through traditional methods then it is nothing more that replacing or rewriting the

application all over again (i.e. the endless cycles of re-writing applications). The enterprise thatis constantly rewriting their monstrous apps produces competitive disadvantages because of the

high costs and time to re-write, test and implement. In fact, they would most likely be better off

8/7/2019 SOA-REPORT (2)

3/45

3

to keep heritage applications built with Power Builder or COBOL. Services as defined in this

section replaces the traditional word application with the word services instead.

1.2.1 What does being service-oriented implies

The fundamental technical characteristics of SOA are a service and remote service invocation. A

service is a unit of executable code that can be invoked by another service remotely and

inexpensively anywhere in the network. Compared with conventional computing models that

require significant human, programming, and computing resources for applications to

communicate and interoperate, the service-oriented computational model is based on

communication (messaging) and interoperability between services to discover and invoke remote

services, based on requirements, and to orchestrate services into composite services or service

workflows.

Figure 1.1 Service Oriented Scenario

Presumably an SOA is the architecture that supports services-orientated computing, yet there is

no architecture inherent in services and service invocation. Indeed, SOA is not an architecture

characterization; it is a style of programming. As there is no standard definition of an SOA we

8/7/2019 SOA-REPORT (2)

4/45

4

adopt a vendor neutral description of SOA functionality [Heffner, 2005] which is characterized

by three values that an SOA supports Change, Connection, and Control. Each value is provided

by a set of functions. Flexible business Change, the key SOA benefit, is enabled by a Service

Life Cycle Environment that supports the service life cycle in which services are developed,

modified, and maintained. Connection between services, the technical essence of SOA, is

realized in the Service Delivery Network through which all service interactions take place.

Control, which is required to manage services, is enabled by the Service Control Platform that

provides tools to monitor, govern, and manage service execution.

Initially during the migration to SOA, an SOA will mix services with conventional or legacy

applications. At least initially, SOAs must deal with existing computing resources that are not yet

or may never be service-oriented. Services are often depicted as service interfaces that are APIs

(Application Programming Interfaces) to functions within conventional applications, called core

application platforms that will exist early in the transition to SOA.

1.3 WHAT IS SOA

Service-oriented architecture (SOA) is a flexible set of design principles used during the

phases of systems development and integration in computing. A system based on a SOA willpackage functionality as a suite of interoperable services that can be used within multiple

separate systems from several business domains.

SOA also generally provides a way for consumers of services, such as web-based applications, to

be aware of available SOA-based services. For example, several disparate departments within a

company may develop and deploy SOA services in different implementation languages; their

respective clients will benefit from a well understood, well defined interface to access them.

XML is commonly used for interfacing with SOA services, though this is not required.

SOA defines how to integrate widely disparate applications for a Web-based environment and

uses multiple implementation platforms. Rather than defining an API, SOA defines the interface

8/7/2019 SOA-REPORT (2)

5/45

5

in terms of protocols and functionality. An endpoint is the entry point for such a SOA

implementation.

Service-orientation requires loose coupling of services with operating systems, and other

technologies that underlies applications. SOA separates functions into distinct units, or services,

which developers make accessible over a network in order to allow users to combine and reuse

them in the production of applications. These services and their corresponding consumers

communicate with each other by passing data in a well-defined, shared format, or by

coordinating an activity between two or more services.

One can consider SOA a continuum, as opposed to distributed computing or modular

programming

Figure 1.2 SOA COMPONENTS

8/7/2019 SOA-REPORT (2)

6/45

6

1.4 ACTORS IN SERVICE ORIENTATION

Following are the actors involved in service orientation,

1.4.1 Service Provider: The service provider is responsible for supplying service objects that

implement service functionality.

1.4.2 Service Requester: The service requester is a client for a particular service.

1.4.3 Service Registry: Service Registry is a repository of services which can be dynamically

published and discovered.

1.4.4 Service Object or Service Its a reusable IT asset implementing some functionality

satisfying business need.

8/7/2019 SOA-REPORT (2)

7/45

7

1.5 SOA LIFECYCLE

The core IT assets of any organization include the following,

y data,y legacy applications,y line-of-business applications andy packaged applicationsSOA implementation is an iterative approach to building integrated loosely coupled systems.

Microsoft has been the leading player in SOA implementation. Following is the SOA life cycleas defined by Microsoft Corporation

Figure 1.4 SOA Lifecycle

8/7/2019 SOA-REPORT (2)

8/45

8

1.6 REQUIREMENTS FOR SOA

In order to efficiently use a SOA, the architecture must meet the following requirements:

y Interoperability among different systems and programming languages that provides the basisfor integration between applications on different platforms through a communication

protocol. One example of such communication depends on the concept of messages. Using

messages across defined message channels decreases the complexity of the end application,

thereby allowing the developer of the application to focus on true application functionality

instead of the intricate needs of a communication protocol.

yDesire to create a federation of resources. Establish and maintain data flow to a Federateddatabase system. This allows new functionality developed to reference a common business

format for each data element.

8/7/2019 SOA-REPORT (2)

9/45

9

CHAPTER 2

LITERARY SURVEY

2.1 BACKGROUND

Current Information Technology infrastructures have reached a crossroad as more and more

Enterprises seek ways to restructure, reorganize and re-align their IT shops. Many believe that in

5 to 10 years from now, Information Technology (IT) will be transformed as the old methods of

building huge monolithic systems are likely to give way to more efficient and agile methods.Thanks to recent advancements in the Internet and Web Services technologies a new approach to

building IT systems called the Service-Oriented Architecture (or simply SOA) is quickly

gaining momentum and acceptance. This new approach, modeled from modern schools of

engineering and architecture, is setting the stage for assembling applications at runtime through

the use of reusable plug and play services. This new way of thinking could not have come at a

better time as todays organizations are seeking ways to control development and maintenance

costs and to consolidate IT infrastructure. To do so, most organizations realize that they will

have to re-invent their information systems into services (rather than applications) to improve the

flexibility and agility needed to support all business processes.

A well-planned strategy based on Service-Oriented Architecture (SOA) will put the Department

of Postsecondary Education, Training and Labor in the drivers seat in terms of procuring cost-

effective agile IT services. The SOA approach results in a vendor and technology agnostic

environment where services can be acquired from either an internal IT Shop or from outside

vendors of SOA-enabled services. SOA goes beyond the current methods of concentrating solely

on the microscopic reusability of objects and programming code by encouraging the reusability

and scalability of business-focused services instead. This approach results in an organization

whose processes behave more like a dynamic living organism. In other words, our applications

8/7/2019 SOA-REPORT (2)

10/45

10

can dynamically re-align themselves to the changing needs of the enterprise on-the-fly (during

runtime). The approach helps us in designing plug-compatible services rather than building

gigantic complex and inflexible applications.

2.2 SOA HISTORY

Enterprise IT System is decomposed into business services. Decomposition theory was first

introduced in the late 1950s. System theory states, The more complex a system is, the more

unknowns it contains and thus, the harder it is to automate it. This theory supports divide and

conquer modular based approach to software development.

In 1960, decomposition approach was first applied on mainframe applications by splitting them

into separate jobs, each implemented by a separate program.

In 1970, there came a boom of object-oriented (OO) paradigm which further strengthened

decomposition adoption by introducing objects, or modules of code, each of which implemented

a model of a real thing. The idea was to map real world entities to software objects. But object

abstractions too often prove to be too fine-grained making it very difficult to map technical

concepts over business level.

Also, many object-oriented developers used to spend most of their time dealing with technical

constructs such as collections, graphical widgets, and so on. In most cases, the real domain

problem disappears inside objects and modules which no longer are understandable by domain

experts. Ultimately, the object model and the class hierarchy are not really understandable by the

domain experts.

In the late 1990s, component based approach was introduced. It helped up to a certain level to fix

the problems of OO by raising a level of abstraction, increasing granularity, and creating a

tighter linkage with the business level concepts.

Although with the introduction of software components, software applications became more

flexible, better structured, and more manageable. But, it never really solved the fundamental

8/7/2019 SOA-REPORT (2)

11/45

11

problem related to software applications of being application-centric. Both objects and

components provide better design and development approaches for individual applications.

With the start of new millennium, SOA brings decomposition to a higher level, SOA approach

too uses the principle of decomposition where business process is decomposed into tasks and

those tasks are then mapped to services. Further services can be composed to form a larger

service called composite service. The architecture of SOA is such that it makes possible to align

business and technology together. It does this by providing meaning to business services and

business processes. And the best part is that it makes it possible to trace services and processes

back to enterprise business architecture.

Thats how starting from multiple jobs era, object orientation, components, we now have service

orientation in place to promote business flexibility and agility that in turn results in flexible IT

infrastructure thereby making it possible a long awaited dream; the dream of having a fastest

time to market. This fastest time to market also yields in least ROI since reusing IT assets in

terms of services requires less time and less effort rather than developing from the scratch.

8/7/2019 SOA-REPORT (2)

12/45

12

Figure 2.1 History of SOA

2.3 EVOLUTION OF DISTRIBUTED SYSTEMS TECHNOLOGIES

Shifting our attention now to the technology side of SOA, we should also spend some time

talking about the evolution of distributed systems technologies and its impact on SOA.

Distributed systems play an essential role within SOA. Most businesses are composed of many

departments or LOBs that represent islands of thought and activity that need to collaborate to

achieve the goals of the business. Likewise, the services identified within a business design will

often show up in the information system as a set of independent application functions that need

to be integrated to implement the service, or that will be composed to form higher level services

or business processes. Given the prominence of distributed computing within an SOA, it is worth

understanding what works and does not work in distributed system technologies.

First, tightly-coupled distributed systems generally do not work. Since the boundaries of a

distributed system often represent corresponding boundaries between the organizations

8/7/2019 SOA-REPORT (2)

13/45

13

responsible for the parts of the distributed system, you cannot expect that they will all operate

with the same technology, or version of technology (technology constraint). Chances are

technology to use for the construction and deployment of their part; these decisions made over

time accrete different hardware and software technologies.

You cannot reliably expect that calling a function over a distributed network will respond to you

in a timely manner (temporal constraint). If nothing else, a remote procedure call may be

measured in terms of milliseconds to get there and back with a response, whereas a local call to

that same function may be measured in microseconds to respond three orders of magnitude or

more in difference between a distributed call and a local call. Beyond that, there is a higher

chance of running into a system failure over the distributed system than in a local address space.

There is potential for network failure; the target machine may be down; or the function you are

calling may be so heavily overloaded handling requests from other clients that it could be

severely delayed in responding to your request.

Finally, different organizations will often have independent development cycles evolving the

parts of the distributed system at different rates (organizational constraint). It is easy for one

organization to introduce bugfixes to their part that will affect behavior that your part depends

on.

Likewise, they may introduce even more severe changes to address new requirements that will

break your interface to their part. In general, you should avoid designing distributed systems that

require everyone to use the same technology, that requires each part to respond in a fixed time or

with extremely low latency, or that requires an rigidly constant set of behaviors or interfaces.

Having said that, we also recognize that some of these constraints are hard to avoid sometimes

you just have to depend on certain capability that only one technology offers, or you may be

mandated by judicial or regulatory requirements to do things a certain way, etc. There are

degrees of forgiveness in these principles, but the more that you are able to adhere to them, themore successful you will be in exploiting distributed computing.

8/7/2019 SOA-REPORT (2)

14/45

14

History in the Information Technology industry is littered with examples of where distributed

computing systems violated (or, more accurately, preceded the discovery of!) these principles.

SNA, DCE, DCOM and CORBA are all examples of distributed computing systems that

required that everyone use the same technology (or, at least, in the case of CORBA, a technology

that implemented precisely the same specified syntax and semantics) to participate in the

distributed integration of parts. Even distributed messaging systems, which embrace some

aspects of loose coupling such as avoiding temporal and to some extent organizational

constraints have tended to also impose technology constraints, requiring all of the distributed

participants operate with the same underlying messaging middleware technology.

We have, hopefully, learned from these mistakes. SOA very intentionally is an evolution of

distributed computing building upon the principles of loose coupling and encapsulation. We take

deliberate steps to avoid dependence on technological, temporal and organizational constraints.

We then allow you to thoughtfully compromise on those principles to the degree that you need to

overcome specific limitations in your environment, but then always with an eye towards

encapsulating those compromises so that they dont create an adverse affect on your use of SOA

elsewhere within your business design.

The notion of loose coupling fits well with the premise of deriving your information system

design from your business design. A significant number of business processes are performed,

today, by human beings. People are inherently loosely coupled in their interactions with other

humans and machines. We are able to communicate with each other over a variety of different

technologies. We are, relative to a computer, very slow that is, we generally dont respond to

each other in a predictably reliable fashion or with low latency. And were pretty good at

adapting to changes in behavior, semantics, and even syntax. Thus, at the highest levels,

activities that automate human processes, with their inherent loose coupling as a comparison,

make for a pretty good approximation for where we can apply boundaries in the distributed

information system.

8/7/2019 SOA-REPORT (2)

15/45

15

2.4 EVOLUTION OF SOA

SOA can be viewed as an evolutionary computing architecture that closely mirrors the history of

the industrial revolution. With SOA, computing architectures are expanding beyond object

oriented self-sufficiency and now allowing for highly specialized and interoperable computing

consumer/producer relationships. This summary provides some history and relationships

between SOA and previous enterprise tiered architectures, object oriented paradigms, and

structured procedural programming.

Pre 1980, structured procedural programming was prevalent for assembling well structured

software code (that was the hope) into a software system. Procedural style APIs focus on the

natural ability to solve problems via a functional process. The focus is primarily on how to get

from point A to point B. This functional way of solving a problem is often a necessary first step

when exploring an unfamiliar problem domain. Between 1980 and 1990, OO evolved and

established its dominance in the software industry. OO focuses on combining elements of the

problem domain in the form of objects containing data and methods which help solve the

problem of how to get from point A to point B in a way that will also be good to get to point C

(reusability).

However, OO evolved prior to the common distributed computing environments that we have

today. Between 1990 and 2000, enterprise tiered architectures evolved and demonstrated that

combining methods with data between tiers worked against scalability and loose coupling of the

enterprise system, thus the use of data transfer objects between tiers and the focus on the data

model for communication between tiers of the enterprise system. Up to the year 2000, individual

computing systems remained relatively self-sufficient.

The pre-SOA tiered enterprise architectures and implementations did not provide a good solution

for computing specialization and computing interdependence at a business or government level.

SOA exploded from the evolution of the tiered enterprise architectures and pressures to provide

specialized B2B and G2B interoperability. Under the realm of a SOA ecosystem fall the

concepts of acting in a SOA ecosystem, social structures, service description, service visibility,

8/7/2019 SOA-REPORT (2)

16/45

16

service interactions, policies and contracts, governance, etc. and this mix of concepts combine to

provide the architectures for the implementations of the automated computing needs for modern

computing consumer/producer relationships. SOA is a computing architecture that allows for

complex relationships and specializations of computing services on a global scale.

2.4 PROGRAMMING TOOLS TO BUILD SOA SOLUTIONS

Figure 2.2 Programming Tools to Build SOA Solutions

The brief analysis of the programming tools that are being used to build SOA solutions is

elicited. This research is with respect the size of organization or industry corresponding to the

particular tool. According to this research, we clearly see that the vendors that supply the tools to

implement Web Services are in a better position to lead the Web Services technology market.

Microsoft Visual Studio.NET seems to be holding a larger market share with fifty percent of the

companies showing a tendency towards it.

8/7/2019 SOA-REPORT (2)

17/45

17

2.5 PLATFORMS TO EXECUTE SOA SOLUTIONS

The brief analysis of the SOA platforms that are being used to execute SOA solutions is elicited.

This research is with respect the size of organization or industry corresponding to the particular

SOA platform. According to this research, Microsoft .NET has proven to be the most widely

used platform to execute SOA solutions. Reason being the may be the ease of use that Microsoft

.NET is providing developers and making it easy to deploy SOA solutions.

Figure 2.3 Platforms to execute SOA Solutions

8/7/2019 SOA-REPORT (2)

18/45

18

CHAPTER 3

EXISTING WORK IN THIS FIELD

3.1 SOA TERMINOLOGIES

3.1.1 Service

A service is a coherent unit of business functionality accessible through programmatic interfaces.

This definition has been based on one of the definitions of Gartner Research [Gartner, 2007]. It

importantly stresses that:

y Any service concerns business functionality.y Services are accessed via programmatic interfaces, i.e. that the business functionality is made

available by software.

A service is an abstract resource that represents a capability of performing tasks that represents a

coherent functionality from the point of view of provider entities and requester entities. To be

used, a service must be realized by a concrete provider agent.

3.1.2 Operation

An operation is an individual function of a service associated with a single consumer-service

interaction. A set of messages related to a single Web service action is Operation. An operation

is an interaction with the service consisting of a set of (ordinary and fault) messages exchanged

between the service and the other parties involved in the interaction.

3.1.3 Interface

Interface is a machine-readable description of the services abstract functionality, provided in a

platform-independent form. An interface defines the communication boundary between two

8/7/2019 SOA-REPORT (2)

19/45

19

entities, such as a piece of software, a hardware device, or a user. It generally refers to an

abstraction that an entity provides of itself to the outside. This separates the methods of external

communication from internal operation, and allows it to be internally modified without affecting

the way outside entities interact with it, as well as provide multiple abstractions of itself. It may

also provide a means of translation between entities which do not speak the same language, such

as between a human and a computer.

A WSDL 2.0 interface defines the abstract interface of a Web service as a set of abstract

operations, each operation representing a simple interaction between the client and the service.

Each operation specifies the types of messages that the service can send or receive as part of that

operation. Each operation also specifies a message exchange pattern that indicates the sequence

in which the associated messages are to be transmitted between the parties.

Figure 3.1 SOA Terminologies

8/7/2019 SOA-REPORT (2)

20/45

20

3.1.4 Contract

A Contract is an expression of visible aspects of Service behavior. A contract is the service

interface specification accompanied with an additional set of requirements and constraints that

must be agreed between the client and the service. A service contract is comprised of one or

more published documents (called service description documents) that express meta information

about a service.

The concept of contract is considered essential to Web Services: contract represents the overall

agreement between the requester entity and the provider entity on how and why their respective

agents will interact; it is not necessarily written or explicitly negotiated. It may be explicit or

implicit, oral or written, machine process-able or human oriented, and it may be a legal

agreement or an informal (non-legal) agreement.

One may argue that any service description conforming to (a version of) the WSDL standard

actually represents a contract. This cannot hold; the service provider and the owners of the

consuming applications usually agree additional requirements and constraints that augment the

WSDL description. Therefore the combination of these two constitutes the contract. If we would

constrain the interaction in such a way that only the machine-readable agreements would be

allowed, then the argumentation would be different. WSDL descriptions would become

contracts, as there would be nothing else beyond it. In practice, this holds for the anonymous

interactions on Internet, where the machine-readable WSDL description is the only agreement

between the consumer and the service.

3.2 WHATS THE BEST FIT FOR SOA

You might be wondering in which business functions and situations SOA fits best and which

best shows its potential? There are some situations and business functions that should conjure

8/7/2019 SOA-REPORT (2)

21/45

21

SOA immediately, because SOA can boost competitiveness and productivity, and clearly display

its benefits. Such situations mainly include:

y Centralized business functions used by multiple entities: SOA helps to identify suchfunctions and package them into reusable, self-contained services that aren't affected by

process changes around them.

y Integration with partners: SOA promotes using standards, which is critical in anyintegration because standards create a common baseline for all parties to work on. Also, the

agility provided by SOA enhances the integration experience with the flexibility to plug in,

change, or update services almost seamlessly to your clients with SOA's decoupling

capabilities.

y The existence of old technologies that are still working: Some organizations aren't willingto give up their tried-and-true technologies. Security concerns make some customers,

especially in sensitive industries such as banking, suspicious of new software systems and

their unknown vulnerabilities. In these cases, SOA can help by wrapping legacy technologies

in standardized ways, enabling their exposure in a standards-based environment suited for

integration and reuse.

3.3 FACTORS MAKING SOA, AN AGILE OPTION

Because change is inevitable, the only guarantee of the continuity of a business is its ability to

anticipate and adapt to changes, also known as business agility. Crucial to the future of any

business, SOA makes business agility possible with the following factors.

2.3.1 Loose coupling

y Enables real-time business capabilities because it removes the hard connections that impedethe ability to change

y Changes the way IT costs are distributed, with less expenses in implementation and moreinvestments in reuse

8/7/2019 SOA-REPORT (2)

22/45

22

y Increases the feasibility of real-time remote access to original sources of information, thusreducing the delay and dependencies

y Integration projects are driven by business needs, with the visibility of capabilities provided(that is, business is the main driver)

y Lets companies extract more data measuring business performance in real time by exposingand sharing information

y Decreases time to market because connections to customers and partners can be made fastery Makes it easier for partners to do business with your companyy Promotes and publicizes your services, making it easier for customers to find you and your

services

y Makes it easier to find new partners and services by helping you search for the most suitableservice for your need

3.3.2 Reuse

y Makes processes more consistent because they depend on the same reused componentsy Promotes increased quality through competition between the services providersy Gives consumers a wide choice of suppliersy Covers essentially all classes of IT assets: hardware, software, data, and process assetsy Decreases the impact of change because it's done in a central location and reflects on all

concerned parties

y Lets you focus on business processes rather than technical implementationy Helps decrease the cost of integration because the component has already been integratedy Lets you make system changes without constraining business changey Promotes flexibility, which gives you more space to innovatey Lets you publish once but consume many times3.3.3 Extensibility

y Makes SOA solutions available to all sizes of organizations

8/7/2019 SOA-REPORT (2)

23/45

23

y Changes software-deployment activities from a big-bang model into a more dynamic, less-time-consuming model, which is more appropriate to the business

y Makes it easier to add or change partnersy Accelerates mergers and acquisitionsy Facilitates exposed services, which represent potential new revenue

3.4 SOA IS ALWAYS BETTER??

SOA provides benefits in almost all cases of business organizations. However, in very special

cases, it might prove to be a liability more than a drive towards better business. These cases

include:

y A homogeneous IT environment: If an organization depends on a set of coherentproductsbelonging to a same vendor, for example, has a limited scope of work, and has

no need to add or change any of these products, an SOA might be a liability more than a

useful strategy.

y When true real-time performance is critical: To provide loose coupling between differentconsumers and producers, an SOA depends on interoperable protocols, which are slow by

nature. It can also induce mediation logic and asynchronous protocols, which aren't suitablefor real-time performance.

y When things don't change: If the customer sees no change happening to the business logic,presentation, data flow, process, or any other aspect of the application, converting old

systems to SOA might not return sufficient value to make the effort worthwhile.

y When tight coupling is not an inconvenience: Loose coupling is of best use when it's usedwith a component that's not under your control and, this, you can't control its change. On the

other hand, when the component is yours and under your control, loose coupling can be a

burden, especially if the component isn't really reusable.

8/7/2019 SOA-REPORT (2)

24/45

24

3.5 SOA CONCEPTS

3.5.1 Definition of a service in SOA

There are a lot of different definitions of services, but I think these do the best job of explaining

what a service really is. "A service is a function that is well-defined, self-contained, and does not

depend on the context or state of other services."

3.5.2 The concept of loose coupling in SOA

To understand the concept of loose coupling in SOA, you should first examine the concept of

loose coupling in general. The following items demonstrate what loose coupling is and why it's

valuable:

y An entity is coupled if changes to the entity by one party in the interaction requirecorresponding changes by the other parties (for example, business data models).

y An entity is declared if its behavior is specified in the interface to the service, and servicerequesters and providers can only interact if they have matching declared behavior. Declared

aspects include security, transactional behavior, and quality of service (such as response time

and delivery).

y An entity is transformed if it's declared by both service requesters and service providers, butthe infrastructure provides some transformation capability to enable interactions between

service requesters and providers that declare mismatched behavior.

y An entity is negotiated if both requester and provider declare a spectrum of behaviors theyare able to support, and the intermediary infrastructure is capable of negotiating an agreed-

upon behavior between them for each interaction.

y An entity is decoupled if changes to the aspect by one party in the interaction don't requirecorresponding changes by the other parties. Loose coupling manifests itself in the SOA

paradigm as follows:

y It helps to have an abstraction layer between the service producers and service consumers.y Loose coupling promotes flexibility in changing the service implementation without

impacting the service consumers.

8/7/2019 SOA-REPORT (2)

25/45

25

y In the SOA approach, functionality is organized as a set of modular, reusable shared services.These services have well-defined interfaces that encapsulate the key rules for accessing the

services. They're also built without making any assumptions of who will use or consume

these services. Thus, they are loosely coupled to the consumer of these services.

3.6 HOW DOES XML CONTRIBUTE IN SOA

Based on open standards and promoting platform-independent business integration, SOA needs a

common platform to base its infrastructure on. This infrastructure needs to be supported by all

involved parties to form a common base of understanding. XML is at the core of this

infrastructure for the following reasons:

y XML is the foundation for virtually all Web services standards, such as XML schema,SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery,

and Integration (UDDI). These standards leverage the core concept of XML-based

representations, a worldwide supported format that carries out information interchange

between service providers and requesters in an SOA.

y Using XML resolves the challenge of working with different data formats in differentapplications across multiple platforms.

y XML has the benefit of ease of representation, being text-based, flexible, and extensible bynature.

3.6.1 XML Standards in SOA

3.6.1.1 SOAP: This simple XML-based protocol lets applications exchange information over

transportation protocols like HTTP. Using XML in SOAP guarantees that the SOAP protocol is:

y Platform independent.y Internet usable.y Humanly readable, structured, and text based.

8/7/2019 SOA-REPORT (2)

26/45

26

With the benefits above, SOAP is the recommended and most widely used communication

protocol for Web services. Knowing that Web services are the cornerstone for SOA, it's therefore

also the basic communication protocol for SOA solutions.

3.6.1.2 WSDL: WSDL is a document written in XML to describe a Web service. It specifies the

location of the service and the operations (or methods) the service exposes to let individuals

access those services. A WSDL file describes four main things:

y Services available by the Web service interface, such as listing names of methods andattribute messages

y Data types of messagesy Binding information for the transport protocol, such as HTTP and JMSy Service address to be used when calling it3.6.1.3 Electronic Business using eXtensible Markup Language (ebXML):

ebXML is a standard way to define the business transactions that can be performed between

different businesses. ebXML defines standard methods for business messages exchange,

establishing trading communications and registering business processes between companies.

3.7 SERVICE REGISTRIES

A service registry is a directory of services available in an SOA system. It contains the physical

location of services, versions and validity periods of services, service documentation, and

policies. A service registry is one of the main building blocks of an SOA architecture. Its role is

described below:

y The service registry realizes the SOA promise of loose coupling. By holding the serviceendpoint locations, it removes the high coupling resulting from hard-wiring the consumer to

the provider. It also eases the potential difficulties in replacing one service implementation

with another if needed.

8/7/2019 SOA-REPORT (2)

27/45

27

y A service registry is highly scalable; it evolves seamlessly should the system it serves grow.y It enables systems analysts to survey an enterprise's business services portfolio. They can

then determine which services are available to automate processes to address pressing

business needs and which aren't, letting you know what needs to be implemented and added

to the portfolio, providing a catalog of the available services.

y A service registry can step into the role of governing services by enforcing compliance forsubscribing services. This helps ensure the integrity of service governance and policies.

You'll learn more about governance and its importance in SOA later in this tutorial.

y Visibility of the available services and their interfaces allows speedier development, greaterapplication reuse, improved governance, and better business planning and management. The

lack of a service registry leads to redundancy and inefficiency.

y Service registries help reduce time wasted in locating service information.y Without a registry to track services and their relationships, an SOA environment not only

lacks coherence and control, it invites chaos.

3.8 SOA TECHNOLOGY SIDE: WHAT WORKS AND WHAT DOESNT

As we see there is a strong relationship between SOA and distributed systems. SOA is glue that

makes it possible to interoperate and collaborate disparate systems. Given the involvement of

distributed computing within an SOA, it is worth understanding what works and does not work

in distributed system technologies. Following are the three major constraints where we really

need to take a look at.

3.8.1 Technology Constraint: Technology Dependent Systems Generally Dont Work

First and foremost, its a proven fact that tightly-coupled distributed systems generally do not

work. The property of being tightly-coupled leads to solutions that dont extend and are difficult

to adapt. Also they dont last for longer. Every organization makes its own technology decisions

based on its own needs. It is unrealistic to expect an organization to use a particular technology

8/7/2019 SOA-REPORT (2)

28/45

28

just to provide the capability of having reusable IT assets. In todays fast emerging technology

world, you cant expect that they will all operate with the same technology, or version of

technology and this is what we call technology constraint. Previous distributed solutions such as

CORBA, DCOM etc had a dependency of same technology to be used everywhere which was

unrealistic thats why ended up in failure. The key point is that every organization should be

given a leverage of using the technology that better fits their needs and thats where SOA seems

to excel. SOA design is such that it frees an organization from the technology to be used. Java

services can be exploited in .net environment and vice versa. Even a service hosted on a Linux

server is consumable on Microsoft platform. As long as the service is discoverable on web it can

be consumed anywhere in the world over the web.

3.8.2 Temporal Constraint: Never Expect Time-Sensitive Service Response

Temporal constraint refers to the time sensitive behavior of a service. The golden rule to

remember in SOA world is that Never reliably expect that calling a function over a distributed

network will respond in a timely manner. This is due to the fact that there is a higher chance of

running into a system failure over the distributed system than in a local address space. Network

failures are also common; the target machine may be down for several hours; or the function you

are calling may be so heavily overloaded handling requests from other clients.

3.8.3 Organizational Constraint:Every Organization Has Independent Development Cycles

Finally, there is organizational constraint according to which different organizations will often

have independent development cycles evolving the parts of the distributed system at different

rates. It is easy for one organization to introduce bug fixes to their part that will affect behavior

that your part depends on. Likewise, they may introduce even more severe changes to address

new requirements that will break your interface to their part.

8/7/2019 SOA-REPORT (2)

29/45

29

CHAPTER 4

PROPOSED WORK

4.1 SOA PERSPECTIVES

4.1.1 Business Perspective SOA

SOA is actually done by developers and architects. There are many stakeholders whose interests

actively drive the design of the SOA solution.

The business analyst is concerned with bringing IT infrastructure more in line with the business

strategy. This effectively means that SOA solutions should be designed such that the business

analyst has greater insight into the costs and benefits of various IT investments.

CTO of the organization will make sure that the solution should meet the needs of the business

analyst. He also makes sure that existing applications are preserved and integrate well with

newly developed capabilities.

IT manager is concerned with making management of distributed systems easy. He also makes

sure that these distributed systems integrate well to yield greater business value.

Developers and solution architects are concerned with creating highly dynamic composite

applications that meet the goals of the various stakeholders. The service orientation approach is

the best approach today to deal with heterogeneity. It integrates these heterogeneous so well that

it meets the needs of the organization as a whole.

4.1.2 Technical Perspective of SOA

The Enterprise architect view it as a set of architectural principles and patterns addressing overall

characteristics of solutions such as modularity, encapsulation, loose coupling, separation of

concerns, reuse, composability and so on.

8/7/2019 SOA-REPORT (2)

30/45

30

A Project manager sees it as a development methodology supporting maximum reuse and greater

time to value.

A Tester or quality assurance engineer Views it as a way to modularize, and consequently

simplify, overall system testing.

A Software developer Views a programming model complete with standards, tools, and

technologies, such as Web services.

4.1.3 IT Department SOA Perspective

From the IT departments point of view, SOA-based integration has following advantages,

y simplifies management of distributed resources across multiple platforms,y requires less hardware,y is more reliable,y is standards-based andy Is less costly.

4.2 CONVERGENCE OF SOA AND WEB 2.0

There are at least two significant connection points which relate Web 2.0 and SOA. One is that

Web 2.0 can be conceptualized as a global SOA. Two, that many traditional brick-and-mortar

business that are currently using SOA as their architectural model will want to connect their

Web/Web 2.0 faces up to their SOA. This makes Web 2.0 not just being the Global SOA but

makes meeting smaller SOAs everywhere not just likely, but inevitable. We're talking serious

convergence of focus here. If true, this means that more than half of all software development,

SOA and otherwise, will revolve around the Web, inside or outside organization boundaries. All

of this means Web 2.0 and SOA will meet each other both coming and going, and begin tobecome each other as well.

8/7/2019 SOA-REPORT (2)

31/45

31

Figure 4.1 SOA and Web 2.0 Convergence

4.3 SOA IN AN ENTERPRISE

As an architectural principle for delivering agility and flexibility by decoupling interface and

implementation (business logic), SOA has been in existence for decades. Object-oriented and

component-based development models were established by using the same principle. Recent

technological developments and Web-service standards have made SOA easier by replacing

method calls on object references to message passing.

In large enterprises, services have been delivered in isolation by several projects that are based

on LOB requirements in the organizationnot as a big-bang SOA-definition project. Enterprise-

architecture (EA) efforts in the organizations helped identify the reusable services and leverage

existing investments. Because SOA facilitated interoperability, many legacy applications were

exposed as services and the business functionality was reused.

SOA became the EAI driver across the company, and EAs have evolved into on-premise

distributed systems that are enabled by SOA

8/7/2019 SOA-REPORT (2)

32/45

32

4.4 THE CLOUD OPPORTUNITY

Cloud computing presents both a model and new opportunities for technology buyers in an

enterprise. It offers the opportunity to focus on the core capabilities of an enterprise by

outsourcing certain aspects of IT and reducing IT costs. It also accelerates the provisioning and

deployment with the support hassles that are transferred to the cloud-service provider. The Cloud

is altering the way in which organizations build their infrastructure and applications.

The essential characteristics of cloud computing include both the delivery model and the

commercial model. In terms of the delivery model, it should be available as a service over the

Internet and accessible either from a Web browser or as a Web service. Commercially, users pay

for service usage; both the overall maintenance effort and user costs are low.

Technologically, the Cloud is a culmination of standards and technologies that have come

together over the past several years. They include server virtualization, Web Security, and Web

Services. The implication for the enterprise is that dynamically scalable infrastructure is

available transparently, without any IT involvement in building and managing the infrastructure.

4.4.1 Cloud Computing Models

y Infrastructure as a Service (IaaS),y Platform as a Service (PaaS), andy Software as a Service (SaaS)4.4.1.1 Infrastructure as a Service: Delivery of server infrastructure as a service. An enterprise

does not need to purchase servers, networking equipment, or data-center real estate. It is all

managed by the cloud provider who also dynamically scales up or down, based on the

application-workload requirements. Examples of IaaS are Amazon Elastic Compute Cloud (EC2)

and AppNexus.

4.4.1.2 Platform as a Service: Infrastructure and complete development environment and

computing platform for application development and deployment in the Cloud. Examples of

PaaS are the Windows Azure Platform and the Google App Engine.

8/7/2019 SOA-REPORT (2)

33/45

33

4.4.1.3 Software as a Service: Web-based deployment model, so that the entire application

software is available through the Web browser as a service. Again, pricing is based on usage.

Examples of SaaS are SalesForce.com, Windows Live Hotmail, and Microsoft Dynamics CRM

Online.

4.4.2 Application Characteristics for the Cloud in an Enterprise

Figure 4.2 Application Characteristics for Cloud in an Enterprise

The cloud adoption in enterprises initially is led by tactical opportunities that offer

implementation speed and cost advantages to these enterprises, although there are a few

misconceptions about when to use the Cloud and the associated technological challenges in

moving toward it. Security, performance, availability, and reliability are the top concerns that IT

managers cite for adopting the Cloud. Cloud providers are addressing these concerns through

appropriate architectural measures and service-level agreements (SLAs) to gain user confidence

in the Cloud.

8/7/2019 SOA-REPORT (2)

34/45

34

4.5 MODEL BUSINESS DRIVERS AND APPLICATION SCENARIOS

4.5.1 Rapid global expansion

Global usage of service-based loyalty application Extension of homegrown e-commerce system internationally Readiness to address peak workload for e-commerce New store portal for store staff Centralization of store systems

4.5.2 Branding and superior customer service

New social-media applications for customer feedback and collaboration New CRM system for repairs service Launch of online marketing campaign

4.5.3 Driving growth via new business services and channels

New venture into online home-appliance retailing

Figure 4.3 Model Business Drivers

8/7/2019 SOA-REPORT (2)

35/45

35

Figure 4.4 Mapping Application Scenarios to Cloud Characteristics

Figure 4.5 Mapping Application Scenarios to Cloud Types

8/7/2019 SOA-REPORT (2)

36/45

36

4.6 POSSIBLE INTEGRATION SCENARIOS

The possible integration scenarios between on-premise and Cloud- based applications are as

follows:

y Browser access only: Usually, SaaS applications are full-service standalone applications thatare accessible via a Web browser.

y Cloud functionality that is exposed as a service for consumption by on-premise or othercloud applications.

y Existing on-premise business functionality or services that are exposed to the Cloud.y Data integration between on-premise and cloud data stores.Such emerging hybrid models of on-premise and cloud applications result in a new class of

distributed applications. SOA-based integration with SOAP or REST Web Services seems to be

the easy answer to this problem; however, there are various other issues that should be handled

for it to work across organizational boundaries and firewalls.

4.7 CONSIDERATIONS FOR CLOUD INTEGRATION

4.7.1 Existing SOA investments: There is commonality in the business objectives of SOA andcloud computing with regard to delivering agility, flexibility, and reuse. The existing core

business services that have been developed within the enterprises will coexist and integrate with

the services in the Cloud. This is again enabled by SOA. The integration solution should address

the challenge in letting outside organizations find endpoints of the on-premise services.

4.7.2 Enterprise-architecture practices: SOA is part of the EA mainstream. The scope of

existing organization practices for EA, such as governance, are preserved and extended to the

Cloud (the Cloud is also part of the enterprise technology portfolio).

8/7/2019 SOA-REPORT (2)

37/45

37

4.7.3 Access across firewalls: To expose existing on-premise services to the Cloud, enterprise

IT has to deal with issues such as handling network-address translation and enabling access

through a firewall by opening new ports.

4.7.4 Security-access control: In the distributed application, we need an access-control solution

that works across enterprises that holding their own identity information. The solution should

address key quality-of-service (QoS) requirements, such as system availability and reliability of

integration points.

4.8 CLOUD EXTENSION USING WINDOWS AZURE PLATFORM .NET SERVICES

The Windows Azure Platform is an Internet-scale, cloud-computing services platform that is

hosted in Microsoft data centers. The Windows Azure Platform uses SOA heavily and provides

SOA-based access to data.

.NET Services is one of the components of the Windows Azure Platform; it provides cloud-

based infrastructure services and facilitates creation and deployment of composite applications.

.NET Services comprises an access-control service and a service bus.

y Access controlCloud implementation of claims-based identity federation for performingfederated access-control authorization as a Web service across organizations and protocols.

This service utilizes standard protocols, such as WS-Trust and WS-Federation.

y Service busAllows applications that expose Web-service endpoints to be located andaccessed by clients. This service enables communication between two applications- both of

which might run in the Cloud; one of which might run in the Cloud and the other on-premise;

or both of which might run on-premise, but across different enterprise data centers. It also

addresses the firewall-access issues of enterprise systems and enables connection, without

requiring data centers to open new ports for accessthus, providing location transparency to

integrating applications

8/7/2019 SOA-REPORT (2)

38/45

38

4.9 SOA AND GRID COMPUTING

There has been an increase in interest recently within the Grid community towards "Service

Oriented'' Paradigms. Services are often seen as a natural progression from component based

software development, and as a means to integrate different component development

frameworks. A service in this context may be defined as a behaviour that is provided by a

component for use by any other component based on a network-addressable interface contract

(generally identifying some capability provided by the service). A service stresses

interoperability and may be dynamically discovered and used. According to the "Open Grid

Services Architecture" (OGSA) framework, the service abstraction may be used to specify access

to computational resources, storage resources, and networks in a unified way. How the actual

service is implemented is hidden from the user through the service interface. Hence, a computerservice may be implemented on a single or multi-processor machine- however these details may

not be directly exposed in the service contract. The granularity of a service can vary- and a

service can be hosted on a single machine, or it may be distributed. The "TeraGrid'' project

provides an example of the use of services for managing access to computational and data

resources. In this project, a computational cluster of IA-64 machines may be viewed as a

compute service, for instance -- hiding details of the underlying operating system and network. A

developer would interact with such a system using the GridSDK toolkit, derived from Globus,

and consisting of a collection of services and software libraries.

Web Services provide an important instantiation of the Services paradigm, and comprise

infrastructure for specifying service properties (in XML -- via the Web Services Description

Language (WSDL) for instance), interaction between services (via SOAP), mechanisms for

service invocation through a variety of protocols and messaging systems (via the Web Services

Invocation Framework), support for a services registry (via UDDI), tunneling through firewalls

(via a Web Services Gateway), and scheduling (via the Web Services Choreography Language).

A variety of languages and support infrastructure for Web Services has appeared in recent

months -- although some of these are still specifications at this stage with no supporting

implementation. Web Services play an important role in the Semantic Web vision, aiming to add

8/7/2019 SOA-REPORT (2)

39/45

39

machine-processable information to the largely human-language content currently on the Web. A

list of publicly accessible Web Services (defined in WSDL) can be found at www.xmethods.net.

By providing metadata to enable machine processing of information, the Semantic Web provides

a useful mechanism to enable automatic interaction between software -- thereby also providing a

useful environment for agent systems to interact.

4.10 SOA BENEFITS

4.10.1 Organizing Distributed IT Resources

Service orientation is an approach to organizing distributed IT resources into an integrated

solution. No matter where information resides be it enterprise local intranet or its over the web,

as long as some service is available, it can be used anywhere. Ultimate fruit of SOA is composite

applications. These applications provide end users with more accurate and comprehensive

information and insight into processes. Also, users have the flexibility of using them in most

suitable form such as via,

y Web,y rich client,y Mobile device etc.SOA enabled Composite applications are so dynamic that enable businesses to improve and

automate manual tasks and allow them to integrate heterogeneous data spread across

organization. This ultimately gives business greater agility and ability to compete in marketplace.

4.10.2 Integrating Distributed IT Resources and Assets

Today Complex, distributed, heterogeneous IT resources are a serious concern for our

businesses. Many a times, we observe that

y our existing IT services dont adequately meet specific business needs,y its maintenance cost is extremely highy its change responsiveness is extremely low

8/7/2019 SOA-REPORT (2)

40/45

40

Full systems rip and replace or a complete renovation is not a practical solution anymore. A

better solution is however is to leverage existing IT investments so that overall organizational

goals are effectively supported. With Service orientation, systems become more responsive to

changing business needs, easier to manage and maintain. It also allows helping plan ahead for

change rather than following a reactive approach.

4.10.3 Aligning IT with Business

In todays fast changing world, many times business demands change without any plan. For

these changing conditions, IT department does not have enough time to respond. The reason

being may be IT infrastructure is inflexible in terms of supporting business changes in a

reasonable time. This is where we really need alignment of IT with business. By aligning IT with

business we mean IT infrastructure should be capable enough to adapt changing business

requirements in a reasonable response time.

SOA is an IT architectural style that supports the transformation of your business into a set of

linked services, or repeatable business tasks that can be accessed when needed over a network be

it intranet or internet. With this a dream of IT alignment with business has come true.

4.10.4 Maximal reuse of IT assets

In SOA enabled IT solutions, IT assets are managed in terms of services which are reusable to a

greater extent; this allows us to reuse IT assets to a maximum.

4.10.5 Stronger Connections with Customers and Suppliers

By making dynamic applications and business services available to external customers and

suppliers, not only is richer collaboration possible, but also customer/partner satisfaction is

increased.

4.10.6. Enhanced Business Decision Making

8/7/2019 SOA-REPORT (2)

41/45

41

In, Todays world, we see that quick decision making stands at the center of business. SOA

enabled solutions make it possible to access information in various possible ways be it Web, rich

client, mobile device etc. Due to this information is readily available for decision makers.

4.10.7 Greater Employee Productivity

SOA enabled solutions, allows employees gain timely access to the information they need. This

greatly increases employee productivity.

4.10.8. Time-To-Value is Much More Immediate with SOA

The real-world approach to SOA also emphasizes time-to-value. Time to value is more reliable

measure than ROI since any project can have a good ROI as long as it is amortized for a

reasonably long time. With ROI there is always an uncertainty, whether the business can survive

for that long to realize that return. With SOA, time to value is much more immediate.

8/7/2019 SOA-REPORT (2)

42/45

42

CHAPTER 5

CONCLUSION AND FUTURE WORK

5.1 SOA FUTURE IN THE EYES OF INDUSTRY EXPERTS

Kerrie Holley, klholley@us.ibm.com

KERRIE HOLLEY, IBM Fellow, is CTO of IBMs SOA Center of Excellence. According to

him:

One improvement with SOA might be the fact that Web Services (despite all its flaws)

introduces a new standard for interoperability. However, there is another important aspect of

SOA, which represents a revolutionary approach different to what weve typically seen before

the acceptance of heterogeneity. In the past, far too many solutions were based on the idea of

homogenization. Yet in systems beyond a certain size, homogeneity is simply not possible.

Homogeneity does not scale, which means that any approach that requires homogeneity will

sooner or later fail. Accepting heterogeneity changes the way we design large systems

landscapes. This mental shift might be a small step, but it can have dramatic consequences

(similar to agile programming, which accepts that requirements change instead of trying to fight

against this fact). Based on this we definitely think that there is a future for SOA (just as there is

a future for brainpower.

Brenda Michelson,bmichelson@elementallinks.com

BRENDA MICHELSON is an IT strategist, community leader, hands-on practitioner, and the

voice of business driven architecture. According to him,

Service-oriented architecture is much broader than the technology underpinnings that often

describe it. Service oriented architecture provides a means to express business activities as

modular, configurable and composable software services. These business services can be

combined with business events (EDA), rules and policies into business processes (BPM) and

8/7/2019 SOA-REPORT (2)

43/45

43

interactions that actually match the intent of the business strategists and process owners. While

SOA offers great promise, achieving the business benefits of SOA requires changes for both

business and IT. Most notably, business and IT must collaborate on business architecture and

business service definition, and embrace the management discipline for a shared services

environment.

John DeVadoss, John.deVadoss@microsoft.com

JOHN DeVADOSS is Senior Director for Technical Strategy in the Application Platform and

Developer division at Microsoft. According to him,

Service orientation is a means for building distributed systems. At its most abstract level, service

orientation views everything from the mainframe application to the printer to the shipping-

dock clerk to the overnight delivery companyas a service provider. Service providers expose

capabilities through interfaces, and service-oriented architecture maps these capabilities and

interfaces so they can be orchestrated into processes.

Nicolai M. Josuttis, nico@josuttis.de

NICOLAI M. JOSUTTIS (www.josuttis.com) is an independent system architect, technical

manager, author, and consultant. According to him,

If you can avoid distributed business processing, avoid it but if you have the requirement of

dealing with business processes distributed over multiple heterogeneous systems with different

owner, SOA principles are the only way to be able to be successful and still be flexible. And

because distributed processing will be a key success factor for future businesses, SOA will

remain as a fundamental IT paradigm.

5.2 CONCLUSION

The SOA terminology will converge but it will be a long process hampered by the ongoing

SOA hype. I view SOA-RM as a step in the right direction, but there are some deficiencies and

disputable points of detail. There are no discrepancies between the general SOA concepts and the

Web Services concepts; the definitions in the context of Web Services are indeed specialty

8/7/2019 SOA-REPORT (2)

44/45

44

definitions. The terms denote exactly the same concepts, with the only difference that the Web

Services definitions are narrowed by the implementation constraints. Will the definitions Ive put

forward help to take away some of the confusion? I believe they will, but I would also like to

stress that Im not advocating some kind of rigid language in our profession. That is not needed

as long we are involved in a professional debate among peers and are discussing concrete issues.

Then there is no harm done if we, for example, use the words message ormethodwhen actually

referring to an operation, even in writing. More rigor is needed when we communicate with other

professions, like business analysts and management on one side and developers on the other.

And that is, probably needless to say, what architects do (doing) regularly.

The primary goal of Service Oriented Architecture (SOA) is to align the business world with the

world of information technology (IT) in a way that makes both more effective. SOA is about the

business results that can be achieved from having better alignment between the business and IT.

Moreover, the SOA approach lets enterprises reuse software assets, thereby achieving a better

return on their IT Investments. There is a widespread tool support for SOA and as we see that

Microsoft is proving to be a leader in SOA evolution. The Future of SOA is very bright because

it emphasizes time-to-value. With SOA, time to value is much more immediate.

While there are different perspectives on Service Oriented Architectures (SOA), there is

widespread agreement that it is not a product or a technology but an approach, a style of

architecture that uses the service model to enable integration across diverse systems.

After discussing the advantages and promises that SOA delivers we come to conclusion that

SOA definitely as a broader long term future. The future of SOA lies in its power of being

independent from technology. This was a weakness of previous distributed solutions such as

DCOM, CORBA etc. We end the topic by concluding that just as there is a future for common

sense so there is definitely a future for SOA.

8/7/2019 SOA-REPORT (2)

45/45

REFERENCES

1.

www.wikipedia.org

2. www.soamodelling.org3. www.itinform.com4. www.stackoverflow.com5. www.service-architecture.com6. Gregor Hohpe SOA World7. Wenguang Wang Service-Oriented Framework