Services, SOA, SOSE and the Future

Sheikh Zeeshan Shakeel, BS (CS) University of Karachi, MS-(SPM) NU-FAST Karachi Pakistan

OMS & FIX Implementation Team Lead at MIXITTM

Technologies,

zee_shakeel@hotmail.com, zshakeel@mixitusa.com

Abstract.

With the advent of services or web services, oriented architecture or SOA has changed the way distributed systems

used to be integrated. There has always been a need to make such IT assets which at least reusable because reusable

IT assets are what results in greater cost saving. Also, SOA make it possible what was missing for a long time, we

call it IT-business alignment. Services stand at the heart of Service oriented architecture. In this particular document

we try to answer what is service, what is SOA, Service oriented software engineering. We take a look at the benefits

of SOA with respect to different stakeholders be it business analyst or an IT professional or an enterprise. We try to

clarify the misconceptions that many people have regarding SOA. We also try to provide a brief insight upon SOA

history that is where we started from and how did we reach to SOA. There is a brief discussion on SOA life cycle as

well. Finally we talk about SOA future and to endorse our argument we try to give comments from SOA gurus from

all around the world. We believe this paper will prove to be a good resource in getting started with some solid

understanding of SOA and its related concepts.

Keywords: Web Service, Service, SOA, SOSE, Composite applications

1. Introduction

Service Oriented Architecture (SOA) is considered as an IT problem solver. Many problems exist today be it

prolonged development cycles, poor overall quality of code, inability to meet current and future business

requirements, etc. all of them can be solved by proper implementation of SOA. SOA has been around for a decade

or so, and it has made huge advances during this period of time, especially in the areas of asset reuse, integration and

security etc. A lot is being said about services, SOA and SOSE. Before we really take the insight regarding the

benefits let me first define what actually service, SOA and SOSE are all about.

1.1. Service in Service Oriented Architecture

Service-Oriented Architecture is a practice of deriving an information system design from a business design

enabling IT and business growing side by side resulting minimum time to value for the business. The business

process and the tasks from which it is composed can be collectively thought of as services. Thus, the business design

is essentially a composition of services and the policies and conditions that must be applied to their use which form

the information system design.

There are several questions come into mind when we talk about service oriented architecture. For instance, what is a

service? Is it a method within an application? Are all functions services within an application? Researchers say that

coming up with a single, mathematically precise definition that applies universally to the entire situation is

impractical, unrealistic and very difficult. It is also said that, in practice, such precision is not necessary to achieving

value and success from SOA.

The fundamental assumption in the application of SOA to information technology is the principle of loose coupling.

In general, ―a service is a repeatable or reusable task within a business process”. [8] So the set of tasks that make

up a business process are called services and the business process, therefore, can be thought of as a composition of

services.

1.2. Service Orientation and SOA

Service-orientation is a way of ―integrating business as a set of linked services”. [8] Services are defined in all the

lines of business or LOB’s. Also the business process itself is defined in terms of services. Main services are further

decomposed into basic more granular services. These services are then used to interlink LOB’s. Similarly, the same

principles of composition can be used to create links with business partners to both automate those relationships and

to gain more efficiency from them. The ultimate consequence of service orientation is flexibility: the ability to

iteratively optimize business design, unhampered by inflexible IT structures.

A Service-Oriented Architecture, then, is an architectural style for creating an Enterprise IT Architecture that

exploits the principles of service orientation, loose-coupling, integration, composite systems to achieve a tighter

relationship between the business and the information systems that support the business. It has become a de-facto

standard create enterprise wide reusable IT assets.

So far we have defined SOA in terms of business perspective. In Technically terms, SOA is a way of designing a

software system to provide services to either end-user applications or to other services through published and

discoverable Interfaces.

According to W3C’s Web Services Glossary (2004),

―SOA is a set of components which can be invoked and whose interfaces descriptions can be published and

discovered. A basis of SOA is the concept of service as a functional representation of a real-world business activity

that is meaningful to the end user and encapsulated in a software solution‖. [8]

In the last eight years, there has been significant improvement in the concepts and technologies used to build

information systems. The foundation of this evolution is Service Oriented Architecture and its tagline is

composition, i.e. the ability to build assets that can be reused in contexts even which were unknown at the time they

were designed and implemented.

1.3. Service Oriented Software Engineering or SOSE

At the heart of the SOSE paradigm is the concept of service, as well as the way to expose system capabilities to

consumers as services through the Service-Oriented Architecture (SOA). In this regard, the Web services technology

is just a way to efficiently realize the concepts of services and SOA. The service forms a contractual agreement

between provider and consumer. Service-oriented software engineering (SOSE) is concerned with theories,

principles, methods, and tools for building loosely-coupled application services that provide particular business

functionality and are distributed within and across organizational boundaries.

Building service-oriented solutions require addressing the concerns of both the service provider and the service

consumer. From the perspective of service provider, it is critically essential to determine what components of the

system can be exposed as services that offer a high business value for consumer and at the same time it should be

decoupled from the rest of the system. This decoupling is essential since it allows the services to be used anywhere

without the dependency of other system functions thereby making it a real reusable IT asset.

From the service consumer perspective, it is a fundamentally important to determine what parts of the business

functions can be completed by calling a services over the web or what parts can be done by composing an in-house

service. Balancing the needs of service provider and consumer is crucial to achieving the true benefits of service

orientation. This also increases business agility and makes inter- and intra-enterprise integration very flexible and a

dream come true.

In its true sense, Just as Software Engineering is a methodology to build software, service oriented engineering is a

kind of methodology to build large scale enterprise-wise, service-oriented, loosely-coupled systems. These

methodologies and practices yield in systems which are flexible, adaptable to quick business changing demands and

have least time-to-market.

1.4. SOA based Enterprise Architecture results in Composite Applications

SOA based Enterprise Architecture results in composite applications. A composite application is a set of related and

integrated services that support a business process built on top of SOA. Composite application can be thought of as

an application that brings together the functionality and services of related intersecting applications. For example, a

government regulatory application regarding the credit history of a person can be made. This application can bring

in the credit history of client from all the banks be it any bank in the country or even the banks outside the country

as long as the relevant services are available, his mortgage details, any loans and also the cash present in all his

accounts. This is only possible though composite applications which are purely based upon web services.

2. SOA Technology Side: What Works and What Doesn’t

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.

2.1. Technology Constraint: Technology Dependent Systems Generally Don’t Work

First and foremost, it’s a proven fact that tightly-coupled distributed systems generally do not work. The property of

being tightly-coupled leads to solutions that don’t extend and are difficult to adapt. Also they don’t 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 just to provide the capability of having reusable IT assets. In today’s fast

emerging technology world, you can’t 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 that’s 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 that’s 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.

2.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.

2.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.

3. Actors in Service Orientation

Following are the actors involved in service orientation,

Service Provider

The service provider is responsible for supplying service objects that implement service

functionality.

Service Requester

The service requester is a client for a particular service.

Service Registry

Service Registry is a repository of services which can be dynamically published and discovered.

Service Object or Service

It’s a reusable IT asset implementing some functionality satisfying business need.

Figure 1: Actors in Service Orientation [8]

4. SOA Life Cycle

The core IT assets of any organization include the following,

data,

legacy applications,

line-of-business applications and

packaged applications

SOA 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 cycle as defined by Microsoft Corporation [9],

Figure 2: SOA life cycle as defined by Microsoft [9]

Expose

The expose phase is concerned with creating the services and taking the decisions regarding which methods or tasks

to expose as services. While creating services it needs to be taken into account whether the service should be fine-

grained or coarse-grained.

A service is a fine-grained service if there is a one-to-one mapping between the service and the business process

while it is course-grained if multiple services are required to perform a business function or process.

How the services need to be implemented it’s also a question of concern here. Whether a service is to be exposed as

a local service running on company local network or it is to be exposed over the web as web service. These and

many other relevant questions need to be answered here.

Compose

After the services have been created in expose phase of SOA life cycle, they can be combined to form more complex

services called composite services. This is done so as to take the advantage of existing services. The best part of

SOA is that services exist independently of other components or services thereby making them reusable as and when

required without the dependency of other services.

Consume

After the services have been created and composed then they must be made available for consumption by either

other IT systems or by end users. Different people can consume the service different ways. Users can consume the

composed service through a number of ways,

Web portals,

rich clients,

Office business applications and

mobile devices etc

While making the service available for consumption there are several questions that need to be asked that come

under the umbrella of SOA governance? SOA governance defines the policy regarding how the service will actually

be created? What technology to be used for service creation? Where the service will be published? Who will use the

service?

5. Programming Tools to Build SOA Solutions

Following is a brief analysis of the programming tools that are being used to build SOA solutions. This research is

with respect the size of organization or industry corresponding to the particular tool. This research was done by [10].

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. Figure 3 depicts this with

more clarity.

Figure 3: Programming Tools Used by Industry Size [10]

For more details on this research see [10]

6. Platforms to Execute SOA Solutions

Following is a brief analysis of the SOA platforms that are being used to execute SOA solutions. This research is

with respect the size of organization or industry corresponding to the particular SOA platform. This research was

done by [10]. 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 4 depicts this with more clarity.

Figure 4: SOA Platform Used by Industry Size [10]

For more details on this research see [10]

7. 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‖. [7] 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 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.

That’s how starting from multiple job’s 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.

Figure 5 shows this transition to SOA based approach as follows,

Figure 5: SOA History [7]

For more on this see [7].

8. Guidelines to SOA Implementation Following are the guidelines from for SOA Adoption,

Try to satisfy business needs rather than just ―doing SOA”.

Successful SOA implementation requires adopting a hybrid approach that makes use of both top-down and

bottom-up approach. Top-down approach does not divide the problem to a right level. Although it does

take some integration issues into consideration but fails to judge individual sub-problem complexity. So it’s

not well-suited to real world. Bottom-up approaches are not manageable either. That’s why organizations

that take hybrid approach are actually able to perform successful SOA adoptions.

Avoid ―build it and they will come‖ approach. In today’s business demands change too quickly making a

long awaited solution inappropriate to satisfy current business needs. That’s why SOA solutions are

supposed to be built incrementally rather than whole sole ―rip and replace‖ solution.

SOA iterations should be quick enough to realize faster time-to-value. The old ―Trust me‖ approach no

longer holds. Also make sure these rapid iterations demonstrate appropriate value.

Last but not the least; ―Snowball” approach is what is mostly desired. We start with a snowball and then

keep building it until a larger snowball is constructed. This is probably the most helpful way with respect to

leveraging SOA to drive business value.

9. SOA Benefits

9.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,

Web,

rich client,

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.

9.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

our existing IT services don’t adequately meet specific business needs,

its maintenance cost is extremely high

its change responsiveness is extremely low

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.

9.3. Aligning IT with Business

In today’s 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.

9.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.

9.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.

9.6. Enhanced Business Decision Making

In, Today’s 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.

9.7. Greater Employee Productivity

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

employee productivity.

9.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.

10. SOA Perspectives

10.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.

10.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.

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.

10.3. IT Department SOA Perspective

From the IT department’s point of view, SOA-based integration has following advantages,

simplifies management of distributed resources across multiple platforms,

requires less hardware,

is more reliable,

is standards-based and

Is less costly.

11. SOA Misconceptions

Different people have different misconceptions regarding SOA. Following are the most common among them,

Is SOA a product that can be purchased or sold?

It’s not a product that can be purchased or sold. Just as software engineering a philosophy to build software

applications so is SOA is a design methodology to build reusable composite systems or applications.

Does SOA Implementation require a business process overhaul?

SOA does not require a complete technological and business process overhaul rather SOA solutions are incremental

and built on top of current investments.

Are SOA and Web Services just the Same?

SOA is also often equated with Web services, and the terms used interchangeably. While it is true that SOA is made

easier and more pervasive through the broad adoption of Web services, the two are different not the same thing.

SOA is an approach to designing systems—it’s a design philosophy to build reusable IT systems or composite

systems. In contrast, Web service is an implementation methodology that uses specific standards and language

protocols to execute on a SOA solution.

12. SOA in Our Local Industry

Following we see SOA as it is realized and followed in our local Pakistan’s Software Industry. While the

concept underlying SOA and its implementation is not new but our local industry is still in realization phase.

Most of the entities are trying to do SOA rather than targeting business needs, this is the most common problem with

most of the technical people. Since there is a strong desire for learning new tools and technologies that why many a

times web service implementation decision are also driven by thrust of getting hands on knowledge of new web

service technology rather than satisfying a real business need. When such an approach is followed, definitely we see

no real advantage of using SOA. According to researchers and SOA gurus, SOA decisions should be driven by organizational need.

Also, merely composing some web services is not enough for SOA implementation. Same is true for Object

Orientation; merely creating few functions within a class does not really mean that one has really grabbed object

oriented principles. For SOA, one really needs to go through some SOA patterns and practices.

13. SOA Future in the Eyes of Industry Experts

Following are the comments of SOA gurus [13] that help us understand where SOA future is going,

13.1 . Kerrie Holley, klholley@us.ibm.com

KERRIE HOLLEY, IBM Fellow, is CTO of IBM’s 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 we’ve 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.‖

13.2 . 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 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.‖

13.3. 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

company—as 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.‖

13.4. 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.‖

For further details on the comments given by above experts see [13]

14. Conclusion

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.

15. References

1. One of the best forums for SOA learning http://www.infoq.com/soa

2. SOA for beginners http://www.ibm.com/developerworks/webservices/newto/

3. Introduction to ESB

http://www.ibm.com/developerworks/websphere/library/techarticles/0509_flurry1/0509_flurry1.html

4. Microsoft SOA FAQ’s http://www.microsoft.com/biztalk/solutions/soa/soafaq.mspx

5. Microsoft approach to SOA http://www.microsoft.com/presspass/features/2006/oct06/10-04SOA.mspx

6. SOA VS Object-Orientation http://blogs.sun.com/jag/entry/soa_buzzworld_whiplash_or_real

7. SOA as an architectural style http://www.ibm.com/developerworks/architecture/library/ar-soastyle/

8. Service-Oriented Software System Engineering: Challenges and Practices by Zoran Stojanovic and Ajantha

Dahanayake. Idea Group Inc (2005)

9. Microsoft SOA overview http://www.microsoft.com/biztalk/solutions/soa/overview.mspx 10. Web Services Vendor: Who is on the Radar Screen of IT Buyers? Exploring opportunities for today and the

Future by Carey Azzara, Chief Research Officer info@hurwitz.com, www.hurwitz.com

11. IBM SOA Foundation: An Architectural Introduction and Overview version 1.0 by Rob High, Jr.SOA

Foundation, Chief Architect, Stephen Kinde,SOA Foundation, Architect, Steve Graham SOA Foundation, Architect

12. The Future of SOA: What worked, what didn’t, and where it is going from here? By Mamdouh Ibrahim

IBM, Kerrie Holley IBM, Nicolai M. Josuttis, Brenda Michelson, Dave Thomas and John deVadoss

Microsoft.

13. SOA What? Michael J. Carry BEA Systems

14. Migrating to SOA’s by way of Hybrid systems by John Hutchinson, Gerald Kotonya, James Walkerdine,

Peter Sawyer, Glen Dobson, and Victor Onditi

15. Service Oriented Architecture (SOA): A New Paradigm to implement dynamic e-business solutions by Joseph Bih, Tayleer Junior College, email: jjmbih@ieee.org, adj-jbih@tjc.edu

16. Scaling Down SOA to Small Businesses by Enrique Castro-Leon, Jackson He and Mark Chang Intel

Corporation.

17. Web 2.0 and SOA: Converging concepts enabling the internet of services by Christoph Schroth and Till

Janner, SAP Research CEC St. Gallen, Switzerland, christoph.schroth@sap.com

18. Composite Software Construction by Jean-Jacques Dubray, InfoQ Enterprise Software Development Series