Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
0Activity
0 of .
Results for:
No results containing your search query
P. 1
Service-oriented architechture simplifies data source integration

Service-oriented architechture simplifies data source integration

Ratings: (0)|Views: 0 |Likes:
Published by Infosys
Here's how the approach helps refinery scheduling and also contributes to business-wide SOA adoption. Read infosys document "Service-oriented architecture simplifies data source integration"
Here's how the approach helps refinery scheduling and also contributes to business-wide SOA adoption. Read infosys document "Service-oriented architecture simplifies data source integration"

More info:

Categories:Types, Business/Law
Published by: Infosys on Jul 01, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/01/2013

pdf

text

original

 
 
Originally appeared in:
October 2009, pgs 41-46.
Used with permission.
Process Control and Information Systems
SpecialReport
Service-oriented architecture
simplifies data source integration
Here
s how the approach helps refinery scheduling and also contributes tobusiness-wide SOA adoption
K. Samdani, Infosys Consulting, Bangalore, India
he refinery scheduling system needs to interface with variousheterogeneous data sources. Although the traditional point-to-point integration approach serves the needs, it presentsmathematical engines to develop an end-to-end refinery schedule. These tools need data such as tank inventories, qualities, crudearrival and product dispatches, prices, etc. from heterogeneousseveral problems due to a variety of underlying platform tech-nologies. Also, such a solution is not scalable. Applying the SOAapproach helps automate the refinery scheduling process as well ascontributes to building a business-wide services repository. This article compares the traditional integration approach forthe refinery scheduling process with the SOA-based approach andpresents a conceptual architecture along with the benefits thereof. Italso aims at bringing out how the SOA approach for individualprojects such as refinery scheduling contributes to overall strategicSOA adoption by the refining business.
Introduction.
The modern integration approach suggests SOAfor the whole organization for strategic business transformation. The Forrester surve
1
indicates that broadly 70% of large busi-nesses and nearly half of small to medium-sized businesses are intoSOA and, more importantly, are by and large satisfied. Adopting the SOA approach for refinery scheduling helps intwo ways:
The SOA approach develops a reusable scheduling servicescatalog that becomes part of an overall business-wide servicesrepository.
The SOA approach provides open standards-based integra-tion of the scheduling tool with a variety of data sources. The refinery scheduling process can be viewed as a set of reus-able services. A service (for example, getting tank inventories) thatis necessary for refinery scheduling can be used by other businessprocesses such as yield accounting, plan vs actuals analysis, etc. Also, it can be used across other refineries. SOA also provides inte-gration standards for interfacing with the various heterogeneousdata sources.Fig. 1 depicts the traditional approach of point-to-point inter-faces between the scheduling tool and data sources. Although itserves the data needs of the scheduling tool, several problemsassociated with the traditional approach are:
Data source systems vary widely in underlying platform,integration capabilities, sophistication, etc. Some sources arespreadsheets/text files whereas others may expose Web servicesfor retrieving data.
In case the legacy systems (providing data to the scheduling tool) are replaced by modern systems, the interfaces with suchsystems are required to be replaced.
Developing an interface for a new data source is almost afresh effort. Reusability is minimal.
These interfaces are tightly coupled with source systems.Hence, changes in underlying platform technologies of the sourcesystems mean a lot of rework.
In interconnected supply chains, data sources may be outsidethe organization. Supply chain partners have their own system
.txt/.csvfiles
Spreadsheets Component Planned crude/
RDBMSs
stream products receiptflow/quality and dispatches
Tank volume
Historian/ and service Refinery Refinery
data sources such as historians, laboratory information manage-ment systems (LIMS), spreadsheets, etc. It eliminates platformdependence by using open standards-based service interface speci-fications. It enables organizing the scheduling process as variousreusable services, thus contributing to developing a business-wideservices repository.
Traditional approach to refinery scheduling.
Refinery 
scheduling is largely driven by a scheduling tool. The tool gener-
RTDBMS
Tank qualities
LIMS
schedulingsystemPricesPricelistspreadsheetscheduleSupply
information
Third partysystems
ates schedules by processing data from a variety of sources. Unlike
Fig. 1
Traditional integration approach.
in the past, current refinery scheduling tools employ advanced
HYDROCARBON
 
PROCESSING
October 2009
T
 
 
SpecialReport
Process Control and Information Systems
upgrade/technology strategy roadmap. Any change to the underly-ing technology by them impacts the interface.
For multirefinery organizations, the development and globaldeployment costs are high since there is little reusability.
Maintenance/upgrade costs are high.
Typically, these are not in line with the overall enterprise- wide IT strategy and hence, carry a lot of risks.Point-to-point interfaces are typically implemented quickly. They serve tactical short-term objectives. Having selected a sched-uling tool, the scheduler expects to start using it as soon as possiblefor obvious benefits of generating optimal and/or feasible produc-tion schedules without considering integration-related issues.
Initiate Collect Audit Generate Publishscheduling data data schedule schedule
Fig. 2
High-level view of the scheduling business process.
Refinery
However, businesses are taking a holistic view of integrationneeds of multiple applications across the organization and devel-oping integration standards. They expect a robustintegrationsolution that considers reusability, is globally deployable acrossmultiple refineries and reduces total cost-of-ownership.
SOA-based approach for scheduling.
The principle
objective of the SOA approach is to eliminate platform depen-dence and organize the business as a set of reusable services. In therefinery scheduling process, the primary service is to generate therefinery schedule. Generating the refinery schedule is achieved by performing several services. SOA decouples these services fromsource or target systems. Thus, it enables using a service as and when needed by any other service or application. As shown in Fig. 2, the refinery scheduling business processcan be viewed as made of multiple steps such as
initiate scheduling 
,collect data, audit data, generate schedule and publish schedule.Fig. 3 presents an example of how the refinery scheduling busi-ness process can be organized as various services. These services areclassified into coarse-grained (step) and fine-grained services(substep and activity). The refinery scheduling business process is divided into five kesteps. The
initiate scheduling 
step triggers the
collect data 
step to get
Business
process
StepSubstepschedulingInitiate Collect Audit Generate Publishscheduling data data schedule scheduleConstruct Connect Retrieve Constructrequest to source and Calculate Unit of response
data from various sources such as historians, LIMS, spreadsheets,etc. The
audit data 
step audits incoming data and shares it with
 generate schedule 
, that runs the scheduling engine and produces anoptimal schedule. The
 publish schedule 
step publishes it.Each step has been further divided into substeps. For example,
collect data 
uses various substeps:
initiate 
,
construct request message 
,
connect to source system 
through to
construct response message 
.Each substep can also be logically divided into activities. Fig. 3provides an example of how the
unit of measure conversion 
substep
message system
 Activity
Receivedata inputsmeasurevalidate messageIdentify Look-upExecutesource and conversionconversiontarget UoMs table
uses four activities. The SOA approach expects such detailed organization of coarse-grained as well as fine-grained services. This enables devel-oping a services repository. It is essential to consider how ser- vices can be independent of source and target applications whiledeveloping the services repository, thereby increasing reusability of services.
Fig. 3
Representative organization of refinery scheduling
services.
Unit of measure service
IdentifyValidated Receive source Look-up
SOA enhances reusability of services.
Systematic orga-nization of services as depicted in Fig. 3 helps identify reusability and removes redundancies. Once organized,such a unique set of services representing thescheduling business process can be called by any application/business function within
Tank
refinery operations as well as the broader
data (from data and conversionhistorian) inputs target table
UoMs
Unit of measure service
IdentifyValidated Receive source Look-updata (from data and conversion
LIMS)
inputs target table
UoMs
Execute inventoriesconversion (desired
UoM)
Constructresponse
Tank
Execute qualitiesconversion (desired
UoM)
enterprise. To maximize reusability, servicesneed to be developed in a manner such thatmultiple applications/other services can usethem. Creating application-independentservices works very well for reusability.Reusability of services can be demon-strated at multiple levels, i.e., at the substep orstep levels or across the business processes.
Reusability at the substep level.
 
Unit 
of measure 
is a substep within the
collect 
data step
. Fig. 4 demonstrates how the
unit of measure 
service is used for converting 
Fig. 4
Reusability of unit of measure service (substep level).
input data units of measure from differentdata sources.
HYDROCARBON
 
PROCESSING
October 2009
 
 
SpecialReport
Process Control and Information Systems
Initiate tank
inventory
Construct
Collect data service (for tank inventories)
Connect Process
User 
inputs
(via UI)
Validateinputs
N
request to sourcemessage (use systemdata aliases) (historian)
Y Y
Connectestablished?
N
Retrievedata (UoMand validateconversion,datacalc.)
Y
 All dataavailable?
N
Constructresponseand uploadSuccessfulupload
NYN
Validateinputs
Y
ConstructGenerate error message
N N
Connect All dataestablished? available?
Y
Connect Audit Generatedata schedule
N
Successful
Y
uploadPublish
Y
scheduleProcess
User 
inputs
(via UI)
Initiate tankquality
requestmessage (usedata aliases)Retrieve Constructto source data (UoMand validate responsesystem conversion,data and upload
(LIMS)
calc.)
Collect data service (for tank qualities)Fig. 5
Reusability of collect data service (step level).
 The
unit of measure 
service receives validated data from vari-ous sources (historian, LIMS, etc.). It is expected to convert theunit of measure as required by the scheduling system. It embedsfour activities to convert units of source data to the desired unitsof measure. It does these activities in the same manner whether
Scheduling business process
Initiate Collect Audit Generate Publishscheduling data data schedule schedule
it receives tank inventories from the historian or tank qualitiesfrom the LIMS. Likewise, it can be used by any other service forconverting units of measure of other data such as prices, crudearrival schedule, etc.
Reusability at the step level.
 
Collect data 
is one of the fivesteps of the scheduling business process. It receives its triggerfrom the
initiate scheduling 
step to get data from various sourcesand provide it to the subsequent step
 — 
audit data 
. Fig. 5 dem-onstrates how the collect data service is triggered by two
initiate 
service 
triggers ( 
initiate tank inventory 
and
initiate tank quality 
triggers) to get data from the historian and LIMS. As shown inFig. 5, the
collect data 
service employs several substeps such as
construct request message 
,
connect to source system 
through to
con- 
struct response message 
.
Irrespective of the trigger (whether
initiate tank inventory 
or
initiate tank quality 
 ), the
collect data 
service employs the
construct request message 
service to receive inputs and build the requestmessage. In a
tank inventory 
trigger, the input is typically a date.For the
tank quality 
trigger, the input is a date range. The
collect data 
service abstracts such differences and enables reusability forany such trigger.
Reusability across business processes.
Fig. 6 demonstrateshow the collect data service can be used for the refinery scheduling business process as well as the yield accounting business process.Both of these business processes expect tank inventories. The
collect data 
service employs substeps to get tank inventories. There-
Initiate Collect Audit Reconcile Publishaccounting data data data account
Yield accounting business process
Fig. 6
Reusability of collect data service (business process level).
fore, it is available to be invoked independent of the business pro-cess (whether the scheduling process or yield accounting).
SOA-based scheduling tool integration.
Refinery 
scheduling system integration with data sources is quite chal-lenging since it presents a variety of platforms such as RDBMSs,historians, legacy systems, third-party systems (outside of theintranet), spreadsheets/files hosted on a local server, etc. SOA aimsat eliminating platform dependence using open standards-basedservice interface specifications [such as Web services descriptionlanguage (WSDL
2
 )] and messaging protocols (such as SOAP,REST, etc.). Fig. 7 presents the traditional approach as well as theconceptual SOA-based approach for integration solution archi-tecture for refinery scheduling. As depicted in Fig. 7 and described in Fig. 1 earlier, the tradi-tional approach provides point-to-point interfaces between datasources and the scheduling system. The conceptual SOA-based
HYDROCARBON
 
PROCESSING
October 2009

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->