Copyright 2004 - 2006, HCL Technologies Limited All Rights Reserved.

WH

ITE

PA

PE

R

Migration to Service Oriented Architecture Using Web Services Whitepaper

cross platform GUI for web services

1.

3.

Requirement for a service-oriented architecture 3

2. What is SOA 3

Features of SOA 3

4. Advantages of SOA 4

5. The Role of Web Services in SOA 4

6. Why Use Web Services? 5

7. Where does Presenter5 Fit in? 5

8. The Advantages of Rich-Client Architecture 5

9. Some more Advantages of Presenter5 6

Tabl

e of

Con

tent

s

1. Requirement for a service-oriented

architecture

2. What Is SOA?

=Leverage existing assets of middleware. Existing

systems can rarely be thrown away, and often

contain within them great value to the enterprise.

Strategically, the objective is to build a new

architecture that will yield all the value hoped for, but

tactically, the existing systems must be integrated

such that, over time, they can be componentized or

replaced in manageable, incremental projects.

=Support rich client interface to be able to do away

with the limitations due to thin client interface if at

all.

=Allow for incremental implementations and

migration of assets. Countless integration projects

have failed due to their complexity, cost, and

unworkable implementation schedules.

=Include a development environment that will be built

around a standard component framework, promote

better reuse of modules and systems, allow legacy

assets to be migrated to the framework, and allow

for the timely implementation of new technologies.

Service-oriented architecture allows designing

software systems that provide services to other

applications through published and discoverable

interfaces, and where the services can be invoked over

a network. When you implement a service-oriented

architecture using Web services technologies, you

create a new way of building applications within a

more powerful and flexible programming model.

Development and ownership costs as well as

implementation risks are reduced. SOA is both an

architecture and a programming model, a way of

thinking about building software. In an SOA:

=All functions are defined as services. This includes

purely business functions, business transactions

composed of lower-level functions, and system

service functions.

=All services are independent. They operate as "black

boxes"; external components neither know nor care

how they perform their function, merely that they

return the expected result.

=In the most general sense, the interfaces are

invokable; that is, at an architectural level, it is

irrelevant whether they are local (within the system)

or remote (external to the immediate system), what

interconnect scheme or protocol is used to effect

the invocation, or what infrastructure components

are required to make the connection.

SOA differs from other forms of computing in a few

fundamental ways.

=Loosely Coupled:

A software is organized into modular components.

This is not a novel concept, but the difference with

SOA is that the components, or services, are loosely-

coupled. Loose coupling is significant because it

underlies the flexibility behind SOA. Loose coupling

means services can be linked together dynamically at

run-time, with few dependencies on how the services

are actually implemented.

Loosely-coupled services can be linked together easily

and quickly as business requirements demand. Tightly-

coupled systems are less flexible, usually involving

recoding or recompilation when interdependent

components are modified. Tight coupling makes it

hard for applications to adapt to changing business

requirements.

3. Features of SOA

3

=Interoperability:

An important consequence of loose coupling is that

services can run anywhere on the network and they

are not restricted to a specific hardware or software

platform or programming language. In a SOA, services

can (and, in many cases, will) originate from different

technology suppliers. Tightly coupled systems, on the

other hand, usually involve a commitment to a specific

software environment, which creates interoperability

issues when different platforms need to be integrated.

=Standard Service Interface:

The service interface describes how to call the

service, specifying, amongst other things, where the

service is located and the format of input/output

parameters. The service interface is what provides

another program with the information it needs to

make a request to the service and get a response. The

Customer Lookup service interface, for instance,

might specify different ways of querying customer

information (by customer id, by customer name, etc.),

and the structure of the customer data that is

returned by the service.

The service implementation is the actual code that

fulfills the functionality of the service. It is the logic that

resides on a computer somewhere on the network

and executes when called (subject, of course, to

appropriate security constraints). Unlike the service

interface, which is defined in a neutral format, the

service implementation is inherently platform-

dependent. SOA is not concerned with how services

are implemented – architecturally-speaking it doesn’t

matter, for example, whether the Customer Lookup

service is written in Java or COBOL – only that a

service fulfills the behavior specified by its interface.

4. Advantages of SOA

5. The Role of Web Services in SOA

The ideas behind SOA – modularization, platform

independence, etc. – are not new. Prior technologies

have promoted many of the same principles, but failed

to achieve the status of SOA. So why has SOA gained

so much traction? The answer is Web services.

On the one hand, Web services – which are simply

services that use specific XML-based protocols and

interface descriptions to communicate – provide the

standards upon which today’s SOAs are being built.

Of these, the key standards are:

=SOAP (Simple Object Access Protocol), which deals

with how an application calls a Web service to

perform an operation and return an answer

=WSDL (Web services Description Language), which

is the XML-based format used to define the

4

SOA

CHARACTERISTIC BUSINESS BENEFITS

Loosely-coupled

} Increases organizational agility; allows companies to easily

assemble, and modify business processes in response to market requirements

} Provides a competitive advantage by offering greater flexibility in the way computer systems can be used to support the business

} Lowers implementation costs by increasing reusability; services can easily be shared across multiple applications

} Increases IT adaptability; changes – resulting from mergers, acquisitions, package application implementations, etc. – are integrated more easily

Modular approach

} Enables incremental development, deployment, and maintenance;

avoids the need to do costly and risky “big bang” software implementations

} Decreases development effort by reducing complexity (through a “divide and conquer” approach)

} Over time, accelerates deployment of new application functionality; process becomes mostly assembly (of existing services) versus mostly new development

Non-intrusive

} Allows existing investment in IT assets to be leveraged

} Lowers risk and development effort; avoids the need to rewrite and test existing applications

Standards-based

} Platform independence allows companies to use the software and

hardware of their choice

} Allows companies to engage in a multi-source strategy, reducing threat of vendor lock-in

} Reduces complexity and fragmentation resulting from use of proprietary technologies

} Lowers training requirements; increases available labor pool

General purpose technology

} Delivers economies of scale; same technology can be applied to

address a broad range of business problems

5

interface to a Web service

=UDDI (Universal Description, Discovery and

Integration), a directory for Web services that lets

applications find out what services are available to

them

Web services are accessible by applications through

the Simple Object Access Protocol (SOAP), an XML

form transmitted over HTTP. The advantage of using

Web standards in an SOA is that the services can

more easily adapt to different applications. Nothing in

particular has to be done programmatically to the

service, except to enable it to receive requests and

transfer results using SOAP. So, in many cases, Web

services are straightforward for an enterprise to build,

and existing software can even be adapted to create

new Web services.

This concept of services is not new—RMI, COM, and

CORBA are all service-oriented technologies.

However, applications based on these technologies

require them to be written using that particular

technology, often from a particular vendor. This

requirement typically hinders widespread acceptance

of an application on the Web.

Major benefits of Web Services include:

=Interoperability among distributed applications that

span diverse hardware and software platforms

=Easy, widespread access to applications through

firewalls using Web protocols

=A cross-platform, cross-language data model (XML)

that facilitates developing heterogeneous

distributed applications

Because you access Web Services using standard Web

protocols such as XML and HTTP, the diverse and

heterogeneous applications on the Web (which

typically already understand XML and HTTP) can

automatically access Web Services, and thus

communicate with each other.

6. Why Use Web Services?

These different systems can be SOAP ToolKit clients

like presenter5, J2EE applications, legacy applications,

and so on. They are written in C/C++, Java, Perl, and

other programming languages. Application

interoperability is the goal of Web Services and

depends upon the service provider's adherence to

published industry standards.

presenter5 (formerly Neuron Data’s Open Interface

Element) is the user interface development

environment that is totally cross platform, integrates

with web services and translates user interfaces into a

dozen international languages.

presenter5 provides 5 key features:

=Built-in, multi platform portability for faster, more

economical development

=C/C++ for high performance of applications

=Support for web services (SOAP & XML)

=Power widgets for automatic GUI object generation

=Internationalization to support multiple languages

and local requirements

In a rich-client system, part of the software runs

natively on a client machine. In the often transaction-

intensive arena of business-critical applications this

yields several advantages:

=Faster Performance, because the code runs natively

on the client

=Rich Interface, since rich-client systems have access

to the native windowing and GUI features of the

operating system.

=Off-line Continuation of Work, since the relevant

7. Where does Presenter5 Fit in?

8. The Advantages of Rich-Client

Architecture

6

code runs on the client and can take advantage of

work-group and local databases.

=Immediate Feedback. Users get fast responses with

context sensitive help, drop-down combo boxes,

field-by-field validation, Tabbed forms, quick lookups

for data searches, and automated process for data

entry.

=Better Security, since it’s possible to control just how

much information is exchanged with third parties

over the Internet.

=Better Reliability, because an application running on

the desktop is more reliable and stable than one that

may fail when the Internet connection is lost

intermittently.

Simply put, while the disadvantages of thin-client

architecture have limited its usefulness as a foundation

for business-critical applications, rich-client systems

have proven resilient as the preferred choice in these

areas. This is particularly the case for applications that

require high levels of user interaction, reliability and

security.

Easy migration of client

=No need to develop GUI from scratch as the current

Presenter GUI could be re-used.

=Lower cost of development due to maximum reuse

of existing components and less investment on

development and re-testing

Future safe technology

=presenter5 works with C/C++ libraries (ANSI

standard)

=Presenter5 supports backward compatibility

Native look and feel of OpenPDM client

application

=presenter5 gives native look and feel to application.

9. Some more Advantages of

Presenter5

It supports XP looks alongwith Windows3.1/95, X-

motif, openLook and MAC

Rich widget sets

=Several rich user widgets readily available in

presenter5 which includes Browser, diagrammer,

treeview, notebook, listbox , calendar and Web

browser.

No learning curve

=Quick development and provides rapid prototyping.

Firewal

SOAP &

SOAP & SOAP &

SOAP & TCP/I

Application Servers

SOAP & Presenter5 based Rich Client

HTML Browser Client consuming web services

Presenter5 based Rich Client

HTML Browser Client consuming web services

Web Server supporting web Services using:

.Net / Java / gSOAP

7

Hello there. I am from HCL Technologies. We work behind the scenes, helping our customers to shift paradigms and start revolutions. We use digital engineering to build superhuman capabilities. We make sure that the rate of progress far exceeds the price. And right now, 45,000 of us bright sparks are busy developing solutions for 500 customers in 17 countries across the world.