FCITR MAGAZINE
Dr. Arif Bramantoro
Faculty of Computing and Information Technology Rabigh King Abdulaziz University
Kingdom of Saudi Arabia
How service
oriented are you?
1
FCITR MAGAZINE
Service Oriented Approach
Internet was initially designed for application to human interactions by obtaining a variety of information, shopping online, reading headlines news. This level of interaction is fine for many purposes.
The regular internet does not support software-oriented interactions very well. This is due to the limitations of HTML and the web server- based technologies, which focused on presentation and their inability to interact with another application.
Internet now is everywhere. There is a lot more we can do!
E-marketplaces.
Open, automated B2B e-commerce.
Business process integration on the Web.
A more efficient method is needed that allows applications to interact directly with one another, automatically executing instructions. Services oriented improve Internet use by enabling program-to-program communication.
Services are loosely coupled software components delivered over internet standard technologies. Services are self-describing and modular business applications that expose the business logic as services over the internet through programmable interfaces and using internet protocols for the purpose of providing ways to find, subscribe, and invoke those services.
Services are typically implemented based on open standards and technologies specifically leveraging XML. The XML-based standards and technologies, such as Simple Object Access Protocol (SOAP);
Universal Description, Discovery, and Integration (UDDI); Web Services Definition Language (WSDL)
SAMPLE SCENARIO OF SERVICES
The following is typical scenario:
The Travel service provider deploys its services by exposing the business applications obtained from different travel businesses like airlines, car-rental, and credit card payment.
The service provider registers its business services with descriptions. The registry stores the information about the services exposed by the service provider.
The customer discovers the services using a search engine or by locating it directly from the registry and then invokes the services for performing travel reservations over the Internet using any platform or device.
Figure 1. Sample services Smartphone
Wearable devices
1
THE BASIC CHARACTERISTICS OF SERVICES APPLICATION MODEL
Services are based on XML messaging, the data exchanged between the service provider and the user are defined in XML.
Services provide a cross-platform integration of business applications over the Internet.
To build services, developers can use any common programming language, such as Java, C, C++, Visual Basic, and its existing application components.
Services are not meant for handling presentations like HTML context—it is developed to generate XML for uniform accessibility through any software application, any platform, or device. Services vary in functionality from a simple request to a complex business transaction involving multiple resources. All platforms including J2EE, CORBA, and Microsoft .NET provide extensive support for creating and deploying services.
Figure 2. Using XML for encoding data in a B2B communication
WHY SERVICE ORIENTED?
Services can be invoked through XML-based RPC mechanisms across firewalls. Sservices provide a cross-platform, cross-language solution based on XML messaging. Services facilitate ease of application integration using a lightweight infrastructure without affecting scalability. Services enable interoperability among heterogeneous applications.
The following are key benefits of services oriented:
Provides a simple mechanism for applications to become services that are accessible by anyone, anywhere, and from any device.
Defines a solution for businesses, which require flexibility and agility in application-to-application communication over the Internet.
Enables dynamic location and invocation of services through service brokers (registries).
Enables collaboration with existing applications that are modeled as services to provide aggregated services.
2
BASIC OPERATIONAL MODEL OF SERVICE ORIENTED
Service provider: is responsible for developing and deploying the services. also defines the services and publishes them with the service broker.
Service broker: (service registry) is responsible for service registration and discovery of the services. The broker lists the various service types, descriptions, and locations of the services that help the service requesters find and subscribe to the required services.
Service requestor: is responsible for the service invocation. The requestor locates the service using the service broker, invokes the required services, and executes it from the service provider.
Figure 3. Service Oriented Model
Service
Provider
3
ROLES IN SERVICE ARCHITECTURE
Roles are quite clear in service oriented, basically can be seen as:
Service provider
Owner of the service
Platform that hosts access to the service
Service requestor
Business that requires certain functions to be satisfied
Application looking for and invoking an interaction with a service
Service registry
Searchable registry of service descriptions where service providers publish their service descriptions
OPERATIONS IN SERVICE ARCHITECTURE
There are some basic operations in service oriented that must be fulfilled:
Publish
Service descriptions need to be published in order for service requestor to find them
Find
Service requestor retrieves a service description directly or queries the service registry for the service required
Bind
Service requestor invokes or initiates an interaction with the service at runtime
SERVICES SOFTWARE AND TOOLS
There are lot of tools, editor and engine that can be used to produce services, such as:
IBM products
Oracle product
BEA system products
Cape clear products
Systinet products
Sun products
4
CORE SERVICES STANDARDS
Each enterprise can choose one of the most mature standards as follows:
XML – eXtensible Markup Language – A uniform data representation and exchange mechanism.
SOAP – Simple Object Access Protocol – A standard way for communication.
UDDI – Universal Description, Discovery and Integration specification – A mechanism to register and locate service based application.
WSDL – Web Services Description Language – A standard meta language to described the services offered.
ebXML- XML-based infrastructure that enables the global use of electronic business information in an interoperable, secure, and consistent manner by all trading partners.
OTHER STANDARDS SUPPORTING SERVICES
In addition, other standards are also available depending on the enterprise requirements.
Web Service Choreography Interface (WSCI).
Web Services Flow Language (WSFL).
Directory Services Markup Language (DSML)
XLANG
The Business Transaction Protocol (BTP)
CHALLENGES OF USING SERVICES
The service provider must examine the reliability and performance of the service in peak load and uncertain conditions for high availability.
As service is publicly available, it must be implemented using authentication and authorization mechanisms, and adopting open security standards like SAML, XML encryption, XML signature. If the environment requires distributed transactions with heterogeneous resources, it should be studied and tested with standard solutions.
5 6
SERVICE-ORIENTED ARCHITECTURE
The basic principles behind the services architecture are based on the Internet protocols. What is a service-oriented architecture? It is an IT architectural style and a design principle for application development and integration. It is a set of architectural principles and patterns such as modularity, encapsulation, loose coupling.
To build the services architecture with these logical components, we need to use standardized components and a communication model.
Today the industry has well embraced the XML-based services standards and technologies as its core building blocks of services architecture. A typical services architecture relies on de facto services standards (WSDL/UDDI/SOAP technologies).
Figure 4. Service oriented building blocks
Services container/runtime environment acts as the services runtime environment and hosts the service provider. Services registry hosts the published services and acts as a broker providing a facility to publish and store the description of services. Services delivery acts as the services client runtime environment by looking up the services registries to find the required services and invoking them from the service provider.
CASE STUDY:
SERVICE ORIENTED BANKING
Due to rapid growth in the market, a European bank decides to replace its IT application infrastructure, including its core processing system, integration platform and all front-end delivery channels. One of the challenges of this project was the integration of over 20 back-end systems being used by the bank, as well as integration with external service providers.
Three main challenges of the project were: (1) business related, to bridge the gap between business requirements and technical specifications, (2) management related, to shorten development time and meet the aggressive timeline of the project, and (3) technical, to assure that performance requirements will be met on the given hardware platform. The performance of the transactional system, especially the middleware layer, is extremely important because of strict rules imposed by the systems being interfaced. An example is how ATM requests processed in the online mode are governed by strict time-out rules.
Two key areas of the solution were: (1) the definition of a unified, enterprise-wide data model for communication, and (2) selection of tools, allowing high-level definition of orchestrated services, that will meet agreed performance requirements in the production environment and allow business analysts to participate in the service design process.
The project team acknowledged that the resulting data model would need to follow business requirements but also need to comply with the requirements of the existing legacy systems. While basic data transformations can be performed directly in the service interface of the back-end systems, fine-grained business requirements can be fulfilled only by the orchestration of coarse-grained back-end services.
In contrast to business services exposed by the back-end applications, services resulting from the orchestration were called virtual services.
