Pennsylvania
Department of Public Welfare
Office of Information Systems
webMethods Interfaces and Exchanges
Integration Guidelines
Version 1.1
November 5, 2003
Table of Contents
Introduction 3
Purpose 3
Document Change Log 3
Executive Overview 4
Why webMethods Integration Server? 6
Decision Support Criteria: When to use webMethods at DPW 14
EAI 14
B2B 15
webMethods Development & Architecture Guidelines 17
DPW Standard Installation of webMethods: CWOPA Image 17
DPW Programming & Configuration: webMethods Flow Service(s) Directory Structure 17
Naming Conventions: webMethods Directory Structures and Flow Services for SOAP 18
DPW Standard Package and Directory Structure: High Level 19
PROMISe SOAP Standards for webMethods: Recipient Eligibility Process 21
Sample EDS Partner SOAP XML Message 22
DPW FTP Standard Information: webMethods FTP web Utility Application for B2B 22
FTP Flow Services: 25
OpenTi Information: webMethods Standards for COMPASS 26
webMethods Architecture: Infrastructure & Environment Configuration 27
Environment Configuration Map 27
Firewall Ports 29
Network Services 29
Inter-Server Communications 29
System Backups 30
webMethods Network Topology 30
webMethods Deployment Standards 31
Requirements Gathering and Project Initiation 31
Integration Survey 32
Functional Requirements 32
Technical Requirements: Compatibility 32
Development 33
Performance and Reliability 33
Security 33
Operations 34
Organizational 34
GEAR Methodology 34
Roles and Expectations 35
Attachment: eGovernment Vendor Survey 37
Email 38
webMethods Interfaces and Exchanges Integration Guidelines
Introduction
Pennsylvania’s Department of Public Welfare (DPW) has adopted an application integration strategy deploying a publish-and-subscribe (pub/sub) based Enterprise Application Integration (EAI) architecture. DPW has extended this architecture to include standard XML, flat file and standards-based message formats. This strategy is designed to enable a high level of plug-n-play integration to meet DPW’s dynamic integration needs. This strategy is well aligned with the overall DPW Enterprise Standard Technology Integration Strategy and leverages industry best practices for overcoming the barriers large entities face when trying to integrate business systems to meet business challenges.
Purpose
The Department of Public Welfare (DPW) uses webMethods Integration Broker to integrate DPW data interfaces and exchanges. This Standard provides DPW with integration guidelines for interfacing and exchanging data between applications and computers. This Standard standardizes the DPW integration processes in the following areas: Determining the integration strategies, determining integration decision support criteria, webMethods software development, webMethods computer network architecture, and webMethods project deployment.
Document Change Log
Change Date / Version / CR # / Change Description / Author and Organization10/15/03 / 1.0 / Initial creation. / Dennis Stamm
11/05/03 / 1.1 / Added new Vendor Survey Form / Barbara Wadlinger
Executive Overview
Integration Strategy
The strategy leverages the webMethods Integration Server solution to connect new business applications, legacy applications, business partners and web services into tightly coupled business processes. The mandate clearly identified a need for an enterprise-wide integration strategy - that defines common business objects for commonly used technical events, business processes and message types. In the middleware setting, these reusable processes and messages are described using BODs (Business Object Definitions). This strategy is designed to make interoperability between multiple disparate systems scalable and affordable.
Central to the overall integration strategy is the use of XML standards to define the messages exchanged in the interfaces between the systems (eg SOAP) outside of the enterprise. There are several industry standards dealing with business object definitions. With the assistance of DPW’s Data Architecture team, a proprietary data standard (based on WC3 guidelines and best practices) was created for developing DPW’s message content and formats. These data elements are the foundation for a canonical format.
DPW’s architecture is well suited to the needs of integrating business applications within the firewall (A2A - application to application) and is very compatible with the overall middleware architecture and goals for future B2B (business to business) initiatives. The use of an “out of the box solution” <like webMethods> and open standards will accelerate the design and deployment middleware components and integration technologies. This means that DPW will see the ability to greatly re-use the interfaces initially developed, creating a “greater time to market” scenario; decreasing the time and money it takes to integrate applications and business partners to the ever-growing DPW interfaces, data exchange and trading partner network.
As part of the development of this strategy, DPW created a team comprised of consulting personnel, application experts and DPW IT staff to devise and refine the strategy and methodology for taking the Middleware and Integration Sever standard to deployment as a publish/subscribe, and process automation enabler.
Audience
The intended audience is interface leads, OIS Executives, integration managers & architects, systems analysts and developers engaged in EAI and B2B activities for the Department of Public Welfare. This document will help integration projects understand DPW’s integration strategy, guidelines, and deployment standards. In addition, individuals can determine whether or not webMethods is the recommended solution for integration projects; and how to connect with the right resources (human and technical) and leverage the webMethods Integration platform.
The findings of this team are presented inside this paper and accompanying appendix or linked documents. They describe the following:
- Decision Support Criteria (How and when to deploy webMethods)
- Integration Standards Information (Best Practices for design and development of webMethods middleware interfaces, Environment Configuration Blueprints)
- Deployment Considerations (How to bring projects “on-board” to the evolving and existing webMethods framework, Integration Planning and Requirements Gathering)
Together, these documents are intended to provide a dynamic framework on which to build DPW’s capabilities to create enterprise-wide interfaces between applications and develop and maintain complex, deeply integrated business processes in an organized, coordinated and affordable manner.
Decision Support
With the introduction of an integration platform, one questions whether or not all interfaces will connect to that platform. For DPW, it is not necessary for all interfaces to bind to webMethods. In order to understand interface requirements, DPW must look at both EAI and B2B requirements. EAI - If an interface requires simple read, write, lookup access between direct database calls, then, webMethods is not required. However, for complicated multi-phase, secure, technical or business process automation, then webMethods is the preferred interface mechanism. It is important to remember that re-usability is the key to success. Pre-built “plug-ins” and processes will be created by the DPW Integration Team. Other applications will be able to simply connect to these processes. For B2B – The webMethods Trading Networks Platform is the recommended solution. This platform creates profiles for data exchange. Once routing rules, security and process information is created, other business partners or external (outside firewall) business partners can be connected almost instantaneously.
Deployment Process
Ultimately, DPW will have many application groups and business partners requiring the use of secure interface transaction sets. In order to properly integrate these systems and partners, it is mandatory for DPW to include standard PMO Integration Planning Processes for webMethods. The standard Software Deployment Lifecycle will be augmented to include webMethods Deployment Standards based on the webMethods GEAR Methodology. This will include everything from requirements gathering mechanisms, planning templates and testing procedures. Vital to this process will be the introduction of an “Integration Survey”. This survey will be the key to prioritizing project deployments and jumpstarting the on-boarding process.
Contact Information
Integration Project Contact Information is as follows:
NAME / ROLE/LOCATION / eMail / PHONEMike Light, DPW / Development Manager / / (717) 772-7941
Pat Gildner, DPW / webMethods Technical Architecture Manager / / (717) 772-7196
Supporting Directories, Documentation & Information
TITLE / LOCATION / PURPOSE / AUTHORIntegration Server and Middleware – DPW Directory / \\Hbgpwisfps01\TQM\H-Net TI Projects\Messaging and Integration Broker / Shared Folder for all webMethods and middleware deliverables and documentation / DPW
Why webMethods Integration Server?
An important challenge to IT organizations is developing and deploying effective integration architecture(s). This architecture must be flexible enough to meet changing business needs while detailed enough to allow the development of tightly integrated business processes. The architecture must not only meet the needs currently addressed with point-to-point application integration, but must also introduce the flexibility and agility needed to excel in a more demanding business climate. Today’s business climate includes secure file transfers, the Internet, B2B, eCommerce, extended supply chains, reduced margins and reorganizations—all of which drive the need for flexibility and efficiency in integrating applications functions.
IT Integration architecture strategies that meet the new criteria provide:
· Improved business level integration through reusable architecture and technology.
· Agility and flexibility using open standards and practices.
· Reduced time, cost to deploy, and TCO (Total Cost of Ownership) through modeling to leverage development efforts.
Addressing the first criterion are IT architectures that allow organizations to concentrate on business level integration instead of lower-level technical details. Common features of these architectures include model-based development, loose coupling and standards-based messages. These architectures allow an organization to get beyond spending time and expertise on the how messages are passed and managed and concentrate on what they contain and why they are exchanged.
Complicating reuse and business level focus is the need to include legacy and current line-of-business systems. Embedded in these systems is significant knowledge about an enterprise’s specific business process and the value they bring to the marketplace, the details of which are not easily discovered and copied. An architecture that cannot leverage the enterprise information and processes already developed will simply have to reinvent them or wait for a successful overhaul. Re-usability is a key criterion for DPW.
Modern integration architectures, such as the publish/subscribe middleware selected by DPW, provide the tools necessary to bridge enterprise applications, legacy systems, and business models. Middleware and integration architectures provide a means to integrate legacy systems with the more current systems. webMethods Integration solutions are highly configurable, reusable, support standards based messaging architecture, and encourage loosely-coupled designs.
Open Standards
Open standards play a key role in meeting the second criterion for integration architectures. Within DPW, projects have the option to use XML, and externally all B2B interfaces will always utilize XML and all aspects of data transformation requirements via the webMethods integration layer. Open standards help commoditize this layer, reducing the amount of effort necessary to implement and maintain the protocols used to interoperate. Standards establish large communities who share understanding of common business vocabulary, while reducing the burdens of application development and human training.
XML provides the ability to create messages that are very specific to the information to be described. DPW will need to be able to accept all types of data from business partners and webMethods will be the tool to decipher that XML Traffic, acting as the primary XML gateway.
This ability to create specifications and a primary XML gateway has been beneficial to integration projects. The ability to send, receive and label data accurately helps assure that the data can be used correctly, not simply placed in some location in an unused exchange format.
However, this flexibility is accompanied by its own problems. The flexibility to create standards has created a situation in which there are thousands of standards, and dozens that may relate to any given business context. Indeed, Forrester Research reports in The XML eBusiness Contract[i] that over 75 percent of the Global 2500 need industry specific standards. But over 50 percent of the Global 2500 believe they will have to support more than two standards.
As more systems based on different standards are integrated into the overall business environment, each one requires developing unique interfaces. And as processes, products or other relevant details change, the changes must be reflected in each interface. The result is an integration network in which adding new standards and business processes squares the amount of work as those changes must be reflected in all of the interfaces. Without careful management, as the number of applications and process integrated rise, it becomes increasing difficult to retain the agility and adaptability inherent in businesses, resulting in an exponentially greater amount of resources expended for each integration.[ii]
The solution is an architecture designed to expect and manage multiple standards. These architectures are precise in describing and managing data, which provides the ability to transform data to accommodate multiple standards. Key to this architecture are models. As DPW’s integration architecture evolves, more focus should be given toward “model driven” canonical formats. DPW must create a re-usable architecture, applying the Data Team’s DPW Enterprise Standard Data Types Library as this format. In the future, it is extremely important to focus on standards for each and every proprietary message inside and outside the data exchange.
Model Driven: Business Process and Data
Another key decision for acquiring webMethods was based on business and data modeling requirements. Modeling and model-driven technologies enable teams to leverage their previous development efforts. In IT systems, model-driven technologies help automate the process of interconnecting systems and managing shared processes. Modeling, already broadly used in applications, is poised to take on increasing importance in interface development as it provides the means to directly impact the behavior of systems based on business models. webMethods WorkFlow, Business Integrator and Trading Networks Products, support technical and business process modeling – business analysts and technical specialists can shell out the programming logic at the Business Level and create a visual representation of the interface model, as well as the APIs behind the process, usually without a large amount of programming necessary.
Modeling technologies aggregate and reuse knowledge regarding the documents and processes that fuel business. This in turn enables tight integration with existing business systems without giving up flexibility and adaptability.
Model-driven systems can restore variability and agility to standards-based systems. They change their behavior based on abstract models that describe the information and processes. For example, SQL databases configure the storage system using SQL models that describe the information to be stored in the relational tables. Tools and user interfaces used to develop model-based systems can significantly lower development time relative to hard coded systems.