Docstoc

Enabling System i Applications for SOA and Web Services

Document Sample
Enabling System i Applications for SOA and Web Services Powered By Docstoc
					Enabling System i Applications for
     SOA and Web Services

      By Harindra Wijesekera (FutureSoft Pty Ltd)




                                                    White Paper
Enabling System i Applications for SOA and Web Services                                                                                  White Paper




Contents
Introduction ........................................................................................................................................... 3
Web Services Explained ....................................................................................................................... 4
SOA Explained ..................................................................................................................................... 5
iSeries Legacy Applications Explained.................................................................................................. 7
Strategies for enabling Web Services and SOA for Legacy Applications .............................................. 9
looksoftware’s approach to Web Services and SOA for iSeries ......................................................... 11
Summary ............................................................................................................................................ 13
Contact Information............................................................................................................................. 13




Figures
Figure 1: Web Services Design Model .................................................................................................. 4
Figure 2: SOA Application Model .......................................................................................................... 6
Figure 3: Pre SOA i-Series Application ................................................................................................. 8
Figure 4: Web Services and SOA Integration Example 1...................................................................... 9
Figure 5: Web Services and SOA Integration Example 2.....................................................................10
Figure 6: Web Services and SOA Integration Example 3.....................................................................11
Figure 7: looksoftware’s Web Services and SOA enabling technology................................................11
Figure 8: Programmatic access requirement to backend systems .......................................................12




Page 2 of 13                                                                                                                           September 05
Enabling System i Applications for SOA and Web Services                                      White Paper




Abstract


Web Services and Service Oriented Architecture (SOA) are widely regarded as the technology with the
highest potential for reducing IT costs and improving business responsiveness by streamlining
business processes. New and existing applications can benefit from this technology. This paper
describes web services, SOA, and how they can benefit existing iSeries applications.




    “Through 2010, over 80% of small and midsize businesses will
    make their processes at least 15% more efficient by deploying
    Service Oriented Architecture”               Source: Gartner 2005




Introduction

Within the next 5 years, 90% of the CEOs of fortune 500 enterprises surveyed by IBM expect to
increase the agility of their enterprise to meet customer demands and trends. Agility, coupled with cost
savings, are recognized as important criteria to be achieved by all enterprises. In order to achieve
such objectives, the enterprise is required to transform itself by reorganizing information resources and
creating reusable, modular, efficient and self-describing services that are independent of the
underlying technology. SOA is widely recognised as the approach to achieve such transformation
within and across the enterprise.


Enterprises are highly dependent on their existing systems. These systems perform vital processes
across the business activities of the organisation including planning, manufacturing, initial customer
contact, sales and servicing and maintaining customer relationships. Existing systems are an
important part of the agile enterprise and a service oriented architecture allows these systems to be
part of the new SOA model.


Small to medium size enterprises will also benefit from SOA technology as it allows existing
applications with limited interfaces to be extended for the support of end-to-end business processes,
through which the enterprise is able to achieve agility, reduce costs and meet customer demands. A
significant share of IT investment is expected to be spent in the acquisition of SOA based technology
by small to medium enterprises for the foreseeable future.
A variety of business benefits are delivered through the implementation of SOA, including:

    •   Improved business responsiveness and a flexible business model
    •   Asset optimization
    •   Reduced software development costs and delivery times
    •   Increased revenue and improved return on investment from existing systems
    •   The ability to integrate disparate systems in a technology independent manner



Page 3 of 13                                                                                September 05
Enabling System i Applications for SOA and Web Services                                       White Paper




Web Services Explained

The word service plays an important role in the term Web Service. A service can be identified as a
means of supplying a (business) need. The ability to obtain a stock price, departure time of a bus or
train or the price of a movie ticket, are all examples of such services. However, some services such as
verifying the credit rating of a consumer may require complex business rules. If these services are
made available over the internet using protocols such as HTTP, then it is called a Web Service. Web
Services are capable of dealing with requirements that have both simple and complex business rules.


Extensive use of XML has been suggested for Web Services, because without it, information passed
over the internet has little or no semantic meaning or context beyond its presentation. XML adds a
layer of intelligence and structure. Even though it’s possible to create a web service without the use of
XML, the industry standards (W3C etc.) have made XML mandatory. In order to qualify as an XML
web service, it will therefore be necessary to conform to an internet protocol (usually HTTP) and use
XML documents to send and receive information.


A web service has been defined by W3C as a “software system identified by a URL, whose public
interfaces and bindings are defined and described using XML. Its definition can be discovered by other
software systems. These systems may interact with the web service in a manner prescribed by its
definition using XML based messages conveyed by internet protocols”.




                                  Figure 1: Web Services Design Model


The Web Services design model has advanced with the incorporation of technologies such as WSDL,
SOAP (including XML documents) over HTTP and UDDI. It is clear that the need for Web Services
and its popularity is a consequence of the successful use of the internet in business. Each web service
requires a service provider (publisher of service) and service requestor (interested party). It is also
possible and common for the service requestor to be a service provider as well. Some web service
implementations may require intermediaries. They may play multiple roles including load managers,
pre-processors, message verifiers, routers etc. Intermediaries are found as layer between service
requestor and service provider.




Page 4 of 13                                                                                September 05
Enabling System i Applications for SOA and Web Services                                         White Paper




WSDL allow users to define the web service in a standard way. It must contain interface, message,
service and binding sections in its description. An interface can be described as a component that
provides a business interface or a collection of business operations. For example, ‘Customer-Order’ is
a business interface consisting of multiple operations and they include; ‘Create-Order’, ‘Get-Order-
Value’, ‘Get-Order-Status’ etc. A message consists of one or many input or output parameters. They
are used by an operation to exchange messages between the service requestor and service provider.
The service and binding sections provide implementation details of the service. Service describes a
number of endpoints at which the web service can be accessed. The binding element provides
invocation details.


SOAP, as defined by W3C, is a “light-weight protocol intended for exchanging structured information in
a decentralized, distributed environment. It uses XML technologies to define an extensible messaging
framework providing a message construct that can be exchanged over a variety of underlying
protocols. The framework has been designed to be independent of any particular programming model
and other implementation specific semantics”.


SOAP has been expressed initially as a technology that brings disparate heterogeneous RPC based
platforms together. Common features of RPC based platforms are high dependency between
applications and tight coupling. SOAP is considered to eliminate both of these by providing low
dependency and loose coupling, allowing for participating applications to evolve independently without
impacting each other. The use of a well-defined standard based messaging framework has evolved
SOAP to be the prominent protocol for XML web services.


Each SOAP message is defined as an envelope consisting of header and body elements. The
grammar described within the standard enforces various rules including the maximum number of
header and body elements possible, only one in this case, and the choice of a header element being
optional and a body element being mandatory for each envelope. The body of the message can be
customized for various domains, meaning standard vocabulary sets, allowing customers, suppliers and
other stakeholders to request services of each other in a standardized manner. XML documents are
capable of hosting RPC and document-centric messages that can be processed through synchronous
and asynchronous methods.


Once a web service is created, it should be made available for interested parties to use. This could be
fulfilled through immediate notification of availability or discovery process. The UDDI specification
provides a central directory or registry that could host service descriptions of one or many providers,
thereby creating an organization or a community of users. It is also possible for this service to be
outsourced. For example, companies such as Microsoft and IBM may host a registry for service
providers to describe their web services. Service requestors will be able to interrogate and discover
available services prior to utilizing them. Also, it is worth noting that use of UDDI is not apparent in all
implementations of Web Services as it is possible to notify interested parties of the availability of
service interfaces and their structures through other means.




SOA Explained

The main objective of SOA is to advocate a set of architectural and design principles that are different
from the traditional view. The traditional view consists of business components and objects. SOA
considers an enterprise as consisting of many processes and services. They are independent of the
technology being used. The term service is a core concept. An enterprise is modelled and designed


Page 5 of 13                                                                                   September 05
Enabling System i Applications for SOA and Web Services                                                     White Paper




through a service-oriented view which would evolve in service-centric directions in the future. It creates
shared, reusable and distributed services. SOA based design contribute towards competitive
advantage and operational efficiency. The traditional view consists of encapsulating (or hiding)
business logic within objects and components, whereas SOA provides for encapsulation based on
service oriented processes. Service oriented processes are coarse-grained; meaning ‘chunky’
interactions – i.e. a collection of several tasks and services brought together through a piece of
logic/workflow. It represents a fewer but larger number of messages - placing customer orders for
example. Typically, objects and components are fine grained as they work towards complying with a
well defined software object model, from an object orientation perspective. Any single fine grained
business logic is not sufficient to meet a complete business requirement.




                                                                                                     Presentation
        Presentation
                                     Request
                                                 messages
                                     Service
                                                                                                        Data
           Data

                                                               coarse-grained
                                                              service interface
                  Service Consumer                                                Service Provider

                                      Figure 2: SOA Application Model


SOA requires service interfaces to be created and exposed. It is through service interfaces that
business interactions occur. Services comprise reusable functionality invoked through a published
programmatic interface. As the service interfaces are business oriented, they correspond to the
granularity of activities and sub-processes within end-to-end business processes. They are
independent message-based application logic that can be available on disparate systems and
accessed across networks. They are also loosely coupled services, allowing a level of independence
including own security, policy and transaction boundaries. Service interfaces are standardised, which
ensures longevity, maintainability and extensibility of the application. The programmatic interface of a
service, also known as a contract, contains metadata that describes the location, binding, messages,
functions, schema and other attributes.


The SOA approach has gained prominence and acceptance in the industry among organizations who
are interested in the process of deploying standardised interfaces for existing and new applications.
Through a coarse grained interface it is possible to encapsulate existing functions (maintain an
abstraction layer between service interfaces and the backend) and modules in creating standardised
and loosely coupled applications. Loose coupling and coarse grained interfaces are core to the SOA
value proposition. Benefits include increased reusability, service sharing, composition, orchestration,
interoperability, consistent access, reduce maintenance and work duplication.


Even though tight coupling of interfaces is possible within SOA, best practice advocates the
advantages of loose coupling. Traditional distributed object computing environments such as CORBA,
DCOM and DCE are based on tight coupling of services which requires closer dependency between
the client and the service. Web Services are the most recognized and the preferred implementation
method (technology) for achieving SOA architectural principles. The loosely coupled Web Services
communication framework is an SOA best practice. The other means of achieving SOA include TCP,
MSMQ, HTTP and MQ Series.




Page 6 of 13                                                                                              September 05
Enabling System i Applications for SOA and Web Services                                         White Paper




The distinct layers of an application environment are; the presentation layer, business (or application)
layer and the data layer. These layers or tiers may be available on a homogeneous or heterogeneous
environment. The term multi-tier is being used when they are distributed across various systems. SOA
has changed the multi-tier architecture through the introduction of a logical layer that comprises of a
standard programmatic interface. It is known as the service integration layer. The service integration
layer will facilitate a business process to be across disparate systems, but still provide for process
unification. It will also be necessary to provide for high availability, fault tolerance, redundancy etc. as
the demand for SOA based services increases. This should be addressed through ensuring the
existence of satisfactory infrastructure.




iSeries Legacy Applications Explained

The word ‘legacy’ in the Concise Oxford Dictionary is defined as “something handed down by a
predecessor”. All things handed down by predecessors are not necessarily bad! The term ‘legacy’
however, has different connotations in the IT world. The technology in use could determine the legacy
status of the application. In the world of the internet, years are determined in months; hence anything
that was developed 6 months ago could potentially be a legacy application as it does not conform to
the current technology. The architectural principles adopted may determine the legacy status of an
application. If the application was designed through non-distributed computing architectural principles,
it may be seen as a legacy application. Applications developed prior to SOA may also be seen as
legacy applications. There may be many other ways of classifying an application as ‘legacy’.


However, the most important task is to determine the demand for the application by its user community
and the contribution it makes towards the enterprise. For an application to continue to be useful, it
should at least make a positive contribution. Apart from the economic benefits, the maintainability and
extensibility should be accounted for when calculating the contribution. The other factors are
functionality, usability, reliability, performance, scalability, adaptability and technology. If the
application is difficult to maintain and the cost of maintenance is too high, then alternatives should be
considered. The same applies with extensibility and the technology being used. It is necessary to
ensure that the technology being used, even though not the flavour of the month, is supported by the
vendor for the foreseeable future.


The software and hardware technologies used by most iSeries applications are supported and
upgraded by the vendor. The most used and popular software development technologies are RPG,
COBOL and CLP. This is in addition to database technologies such as DB2, DDS and SQL. The
power of iSeries comes with its integrated environment. According to Frank Soltis, the chief architect of
the iSeries environment, “integration in a computer system means the various parts work together as a
whole. The value of integration for a customer is that the system is easier to install, maintain and use,
which usually results in lower operational costs for a business”.


Typically data, business logic and presentation of an iSeries application are tightly coupled. The
inherent nature of the environment does not promote distribution of applications and their services
naturally. It is a known fact that “it is easier to develop and maintain applications for an iSeries
environment than for some other platform”.




Page 7 of 13                                                                                   September 05
Enabling System i Applications for SOA and Web Services                                      White Paper




                                  Figure 3: Pre SOA i-Series Application




The pre SOA application modules on the iSeries are highly dependent on each other for their
execution. For instance, there is no separation between database code and business logic. Database
code is tightly linked with business logic and they perform at the highest level of efficiency.
The re-use factor of such applications is low, unless productivity and/or software engineering tools are
used. Synon 2E, ASSET, LANSA are good examples. Even with a low re-use factor, the maintenance
of such applications has been easier and less costly due to the need for a single skill set. One
developer is capable of coding and testing 5250 screen interfaces, database handling routines and
business logic. Other operating environments may require a number of specialists to achieve the same
outcome. Pre SOA iSeries applications have been in demand for many years, some for over a decade
and have made significant contributions towards enterprise productivity. They are highly functional,
reliable systems and enterprises have made significant investment over the years in their upkeep. It is
therefore necessary for such systems to be integrated with external environments.


Application integration is an evolving process. Initially, from an iSeries perspective, applications were
integrated with use of RPC mechanisms over the SNA architecture. Such applications were successful
mostly within native IBM environments including OS2, iSeries and Mainframe domains. This was
followed by the use of message-oriented-middleware such as MQ Series (now known as WebSphere
MQ). It has provided a way to transact with other disparate systems by sending and receiving data, on
a synchronous or asynchronous basis. The dawn of the internet has resulted in the next wave of
communication protocol. It has eliminated the need for point-to-point integration and has given rise to a
variety of enterprise integration opportunities. Messaging over the internet has become secure, cost
effective and efficient, allowing for greater openness of the iSeries applications. Products such as
WebMethods, Tibco and SeeBeyond have played a significant role in this space. As described earlier,
Web Services and SOA have gained prominence in the marketplace due to the economic benefits they
bring. So, there is significant extra advantage to be gained by enhancing the investment in these ‘tried
and true’ iSeries legacy applications with new web services interfaces.




Page 8 of 13                                                                               September 05
Enabling System i Applications for SOA and Web Services                                               White Paper




Strategies for enabling Web Services and SOA for Legacy Applications

In this section, we discuss a number of possible strategies that can be used to provision service
oriented transaction capability. Since many applications are not architected with Web Services and
service orientation in mind, careful consideration is required prior to implementing such services.
Depending on the strategy adopted, the existing application may require major, minor or no change at
all. Here we discuss a few possible approaches.


A proxy service can be used to front-end the backend application by creating required service
components such as WSDL. This is an important capability because it may sometimes be necessary
to expose existing functionality without further business logic. For many legacy applications the
capability to expose functionality directly does not exist, hence the need for proxy services. The use of
proxy services may demand no customization of the application. Even though proxy services are easy
to develop and deploy, they may be less efficient in the design aspects of performance and scalability.


In a business context it may only be necessary to expose a subset of the functionality for service
based interactions. This can be achieved by creating relevant wrappers that expose various parts of
the application. Unlike proxy services, wrapper services are custom built and they are not a mere
replication of existing functionality. Its complexity or otherwise will depend on the business requirement
and the subsequent functional scope. With additional customized code, wrapper services can be
provisioned as complete business services.


The next level of service may be required to provide for coordination of transactions by tracking
participants and activities. A service of this nature has functionality similar to a transaction coordinator.


The following is a high level architectural diagram that represents service based interactions between
loan origination and loan servicing applications. These applications serve various business
requirements and are usually available for use in a heterogeneous environment. However, the loan
origination system will be required to request services from the loan servicing application during the
processing of new loan applications.
                                                                                          Business
                        Business




                                   Figure 4: Web Services and SOA Integration Example 1


From a design viewpoint, the required services from loan servicing can be wrapped, as it is not
necessary to expose all functionality of the servicing system. Also, it may be necessary to use
adapters when dealing with self-contained and standalone solutions such as the iSeries. Adapters are
used to bridge the gap that exists among technology platforms within legacy applications.



Page 9 of 13                                                                                         September 05
Enabling System i Applications for SOA and Web Services                                        White Paper




Adapters act as clients to invoke functions of standalone systems via supplied interfaces, the loan
servicing application in this example. Adapters are usually provided by parties who have intimate
knowledge of the application. Even though it is possible to write adapters, it is necessary to ensure
that additional complexity and adverse side effects are not introduced into the process. In addition to
knowledge, as described above, source modules may also be necessary for successful development
of adapters. Adapters can be of three types; user interface adapters (presentation), business logic
adapters (business) and database adapters (data).


User interface adapters can be used to conduct screen conversations with the loan servicing
application without impacting any aspects of the system (business as usual). They are also known as
“screen scraping” adapters. These adapters provide non-intrusive integration with existing systems.
Use of ‘5250’ or ‘3270’ screen conversation is an example. It is possible to consider the user interface
adapter as an ‘automated operator’ inputting data and sending keys (enter, help, F1, F2 etc) to
transact with the application. As a piece of software, the adapter will be required to identify, extract and
manage (their relationships etc.) data items as received from user interfaces.


Business logic adapters allow access to business rules, work flow etc. They are mainly parameterized,
that is, they provide input to receive output. Business logic adapters allow access to APIs and may be
available in the form of components (COM, EJB etc.) or programs (RPG, COBOL, CLP, Java etc.).


Database adapters are a generic type of adapter that allow access to data components in a non-
intrusive manner. They are very easy to use and highly standardized. The database APIs are available
primarily in the form of stored procedures. These APIs may allow write access to tables and it is
necessary to ensure that they conform to validation, referential integrity and business rules as most
legacy applications do not store all relevant business logic within the database.

The following diagram represents service interfaces and adapters for both loan origination and
servicing applications, allowing consumption of each others services.




                          Figure 5: Web Services and SOA Integration Example 2


The high level architectural diagram shown below represents the use of a unified service interface that
allows access to multiple applications. As described, Applications 2 and 3 require application specific
adapters to gain access to business, presentation and data layers. These applications may be
available on homogeneous (iSeries) or heterogeneous (iSeries, z-Series, p-Series, HP/UX, SUN,
Windows etc.) environments.




Page 10 of 13                                                                                 September 05
Enabling System i Applications for SOA and Web Services                                    White Paper




                         Figure 6: Web Services and SOA Integration Example 3
For example, service requests originating from Application 1 may require business rules, presentation
and data from both Application 2 and 3. The unified service interface will be required to coordinate
activity across Applications 2 and 3.




looksoftware’s approach to Web Services and SOA for iSeries

looksoftware has taken a pragmatic and non-intrusive approach to Web Services and SOA on the
iSeries platform. This approach allows business users to protect their existing investment and leverage
highly functional applications deployed on the iSeries.




                  Figure 7: looksoftware’s Web Services and SOA enabling technology




Page 11 of 13                                                                             September 05
Enabling System i Applications for SOA and Web Services                                     White Paper




soarchitect and centric technologies are required to create web and SOA enabled applications.
soarchitect can be used to generate service interface components including WSDL. This interface also
includes data items to be received from and sent to the requestor. centric provides adapter technology
and it includes 5250 screen conversations, API calls and direct database access. These adapters can
work with green screen or 5250 functions, non-screen based routines comprising RPG, COBOL and
CLP programs, and database adapters that allow access to database functions using SQL. It is also
possible to conduct 3270 screen conversations through centric using its 3270 adapter.


The service requestors can be of any type including looksoftware’s smartclient and lookserver.
smartclient and lookserver are capable of consuming Web Services published by soarchitect and
centric – just like any other service requestor. However, the added advantages are rich functionality
on the desktop from smartclient and the ability to publish information retrieved through Web Services
on PDAs and desktop clients through lookserver.




Example: Retrieve Order Information from the Host iSeries Application
The first step in the process is to determine the input from requestor and the output expected from the
service. In this example we assume ‘order number’ and ‘customer number’ to be input and ‘order
value’, ‘tax codes’, ‘special discount codes’ and ‘help desk notes’ to be output. As described earlier,
they are part of the message description within WSDL.


The next step is to conduct a business analysis in order to identify the necessary software programs to
be called from the existing application. Let’s say there are two 5250 screen based programs to retrieve
‘order value’ and ‘tax codes’ respectively, 1 CLP to retrieve ‘special discount codes’ and 1 SQL
database query to retrieve ‘help desk notes’ from the customer relationship management system.




                    Figure 8: Programmatic access requirement to backend systems




Page 12 of 13                                                                             September 05
Enabling System i Applications for SOA and Web Services                                     White Paper




The scripting technology provided by centric is required to declare calls to the host. The 5250 ‘screen
scraping’ adapter is necessary to maintain screen conversations and extract ‘order value’ and ‘tax
codes’ from the 5250 data stream. centric API and DB adapters are required to retrieve ‘special
discounts codes’ using the CLP program and ‘help desk notes’ using SQL respectively. The above
described program access can be performed in both synchronous and asynchronous modes. Once all
data items are available, soarchitect will submit a response to the caller.


In addition to the above, where the process requires it, centric can support an intrusive development
approach by enabling the creation of new reusable software modules. Also, existing iSeries objects
such as Commands and Native Windows functions can be called.




Summary

The Web Services design model has advanced with the incorporation of techniques such as WSDL,
SOAP and UDDI. Also, the standardization of Web Services has given rise to clear and concise
definitions between service requestors and service providers that may exist in a heterogeneous
environment.

SOA advocates a set of architectural and design principles that view an enterprise as consisting of
many processes and services. They are independent of the technology being used. SOA design
principles and best practice comprise loose coupling, coarse grained and standard based service
interfaces. Even though SOA can be implemented in other forms, Web Services are the most
recognized and preferred implementation method.


As self-contained and standalone iSeries applications are not architected with Web Services and
service orientation in mind careful consideration should be given to the implementation of such
services. Strategies are required to expose all or selected modules of highly functional applications.
The use of service interfaces and adapters is proposed. Service interfaces can be in the form of Proxy,
Wrapper or Transaction Coordinated services.

Adapters can be used to bridge the gap that exists between technology platforms. They are user
interface adapters, business logic adapters and database adapters.


looksoftware’s pragmatic and non-intrusive approach to Web Services and SOA implementation is
described. The availability of highly functional adapters allows enterprises to take advantage of
existing 5250 screens, programs and database application modules, thereby protecting their
investment in the iSeries platform.




Contact Information
Email the Author         harindra.wijesekera@futuresoft.com.au


Page 13 of 13                                                                             September 05

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:8
posted:1/20/2011
language:English
pages:13