Download the Integration Domain Document doc format of Final ETRM 5.1 Integration Domain

Enterprise Technical Reference Model - Version 5.1

Effective Date: November 18, 2011

Integration Domain Table of Contents



 

5. Domain: Integration
5.1 Discipline: Registry Services
5.1.1 Technology Area: Web Service Registry

5.2 Discipline: Enterprise Service Bus

5.2.1 Technology Area: Messaging Services

5.3 Discipline: Transport

5.3.1 Technology Area: Protocols


ETRM Document Organization

The ETRM specifies standards, specifications and technologies for each layer or area of the Service Oriented Architecture. For ease of reference, each area and its various components are organized into the following building blocks:

  • Domains: Logical groupings of Disciplines that form the main building blocks within the technical architecture.
  • Disciplines: Logical functional areas addressed within each domain as part of the architecture documentation.
  • Technology Areas: Technical topics that are relevant to each Discipline
  • Technology Specifications: Sets of product standards, protocols, specifications or configurations associated with each Technology Area.

 


5. Domain: Integration

Description

The Integration Domain addresses how information, transactions, security, systems management and Business Services are integrated across intra-enterprise entities, e.g. agencies, as well as extra-enterprise entities, e.g. business partners.

Strategic Importance

The manner in which government information, transactions and business services are integrated is critical to creating an Enterprise SOA Architecture where:

  • Integration timeliness, efficiency and cost effectiveness is facilitated
  • Application security can be extended to Government to Business and Government to Government Services
  • Open standards provide consistent integration methods across diverse technologies

Although IT integration is not a new phenomenon, this level of cross platform integration using open standards has no historical precedent.

Related Trends

  • The IT industry is evolving from hub & spoke Enterprise Application Integration architectures (EAI), to more distributed SOA based integration architectures
  • Major IT vendors are collaborating with open standards bodies to develop a set of interoperable standards to achieve the goal of cross enterprise, cross-platform, Business Service Integration
  • XML semantics are the lingua franca to achieve Integration between diverse agencies and/or businesses using diverse technologies

Vision

To create an enterprise messaging environment based on open standards that facilitate trusted and timely communications between Business Services. This environment is a fundamental building block of the Commonwealth’s SOA.

Roadmap

Current State

  • Currently a majority of agency applications are mainframe or client-server based limiting access to transactions and data
  • Some business service integration can only be achieved through the use of proprietary protocols and standards
  • The Commonwealth is in the process of upgrading its infrastructure to provide additional support for SOA open standards
  • Agencies vary in their approach to SOA, many of which are transitioning to a service-based integration style

Target State

  • The creation of an Enterprise Web Service Registry to facilitate the software reusability and the creation of composite Business Services
  • The creation of an enhanced Enterprise Service Bus solution to provide standards based SOA Reliable Messaging, Routing, and Transformation
  • The ability of government applications to support on demand business integration, using open standards, consistent with security and privacy requirements.
  • The replacement of CommBridge with the SOA-enabled Interchange

Boundary

This domain addresses technology specifications for Registry Services and the Enterprise Service Bus. Technology specifications for non-SOA related directories and integration services are not addressed in this document. Security specifications and standards are defined in the ETRM Security Domain.  Application composition specifications and standards for orchestration and choreography are included in the ETRM Application Domain.

Related Policies

Associated Disciplines

  • Registry Services
  • Enterprise Service Bus
  • Transport

 

Integration domain showing hierarchy of Disciplines and areas of technology as specified in the etrm.

 

Integration >

5.1 Discipline: Registry Services

Description

All IT Enterprises utilize a variety of proprietary and standards-based Registry Services. A Registry is a catalogue of items, including:

  • Devices
  • Applications
  • People
  • Telephone Numbers
  • Email addresses

In some cases the terms Registry and Directory are used interchangeably. Examples of Registry Services include:

  • Operating System Registries
  • Telephone Directories
  • Email Directories
  • Web Service Registries
  • Identity Management Directories

Registry Services play an important role in the Service Oriented Architecture. They allow for the registration, governance, and discovery of those critical items that are crucial for the conduct of electronic government services.

Stakeholders/Roles

  • external and internal users of government information and services
  • business service architects
  • analysts and application developers

Roadmap

The Commonwealth does not have enterprise Web Service Registries at this time. Our goal is to make available a standards-based Enterprise Registry for use by agencies, which can be implemented as a Shared Service for registering and publishing Web Services. It is envisioned that this Enterprise Registry will:

  • Provide a repository for Business Service Metadata, e.g. Policies, Schema
  • Have the capacity to be partitioned to provide “virtual agency registries” as a Shared Service
  • Have the capacity to be Federated with agency managed Universal Description, Discovery and Integration (UDDI) Registries

Enterprise Technology Solution

The Commonwealth is implementing the HP Systinet Repository and Registry as the enterprise solution. ITD will work with agencies to develop an Enterprise Web Service Registry with the goal of implementing a standards-based solution that can be used by agencies as a Shared Service for registering, publishing and governing Web Services.

Relevant Standards Organizations

Additional information about the Standards Organizations listed below can be found in the Introduction section of the ETRM or by clicking on the hyperlink to the organization.

  • OASIS - Organization for advancement of structured information standards
  • WS-Interoperability - The Web Services Interoperability Organization

Associated Technology Areas

  • Web Service Registry

 

Integration > Registry Services >

5.1.1 Technology Area: Web Service Registry

Description

A Web Services Registry provides an enterprise catalogue for Service Providers to publish Web Services to, and for Service Consumers to search and find Web Services. The Registry facilitates service reuse with management of service publication and subscription data, to extend the value of Web services by providing developers with powerful search, notify, browse and API support.

SOA Web Service Registry Services provide easy discovery of Web Services. SOA Business Services are meaningful only if potential users can find information sufficient to permit their execution. If you can’t find it, you can’t reuse it. The focus of the SOA Service Registry is the definition of a set of services supporting the description and discovery of:

  • Businesses, Organizations/Governments, and other Service Providers
  • The specific Business Services they make available
  • The technical interface standards that may be used to access those Services

In addition, at run time, an application queries UDDI Services to discover the service policy and binding information for the services it needs, and then connects directly to those services.

Based on a common set of industry standards, including HTTP, XML, SOAP, and UDDI, the Web Service Registry provides an interoperable, foundational infrastructure for an SOA-based software environment for both publicly available services and services only exposed internally within an enterprise.

Service Registry standards focus on the published service interfaces, and therefore tend to not represent all of the information typically captured in the service repository, such as service dependencies, business application contexts, and business rules.  The Commonwealth is monitoring the industry’s progress on the development of service repository standards, such as ongoing efforts with S-RAMP.

Technology Specification: Universal Description, Discovery and Integration (UDDI)

Description

UDDI registries provide easy discovery of Web services and other programmatic resources inside an organization. They also facilitate the governance of web services.

Two common scenarios for Registry Services inside an organization are Developer Reuse and Dynamic Application Configuration:

  • Developer Reuse: At design time, developers should search Registry Services for Web services and other programmatic resources to reuse in building new applications. UDDI Services expose all of the information needed to invoke a service, making it easy for the developer to integrate the service into an application.
  • Dynamic Application Configuration: At run time, an application should query UDDI Services to discover the current binding information for the services it needs, and then connects directly to those services. The Registry must ensure that mission critical services are not exposed to unauthorized applications.

Guidelines - When evaluating and/or acquiring an SOA Business Service Registry it is important to look for compliance with the UDDI standard, to insure interoperability with other Technology Areas which comprise the Enterprise SOA.

Standards and Specifications -

  • UDDI v. 2.0 - The Universal Description, Discovery and Integration (UDDI) protocol version 2.0 has been tested by the WS-Interoperability group to insure successful integration with SOAP 1.1 and WSDL 1.1, thus providing the Commonwealth with a level of interoperability assurance.
    Refer to: http://www.uddi.org/

Migration Strategy-

UDDI v. 3.0 has now been ratified by OASIS. However, it has not yet been included in the WS-I Basic Profile. Therefore, the latest UDDI version has not yet been tested for interoperability. Use of this new standard will require agencies to do their own interoperability testing until such time as the WS-I Basic Profile is updated. The ETRM standards will be revised to reflect revisions to the WS-I Basic Profile.

 

Integration >

5.2 Discipline: Enterprise Service Bus

Description

An Enterprise Service Bus (ESB) is a grouping of services that facilitate integration including:

  • Messaging Services - The ESB has evolved from message-queuing technology, which was originally point-to-point in nature. One of the most fundamental functions of an ESB is the sending and receiving of messages between SOA Service Providers and Service Consumers.
  • Transformation Services – In a SOA, the message payload is typically an XML document. Given the plethora of XML standards, and the continued use of legacy formats (e.g. EDI), the ESB needs to provide Transformation Services to convert legacy formats to XML, as well as transform XML from a Service Provider to the format expected by the Service Consumer. An ESB can be used to extract and transform data from legacy systems to enable information access without the need to replace systems.

Analysts increasingly refer to ESBs as a method of making application integration simpler and cheaper. Furthermore, through the use of Transformation Services, distributed processes can include legacy applications as well as Web Services.

 

Relevant Standards Organizations

Additional information about the Standards Organizations listed below can be found in the Introduction section of the ETRM or by clicking on the hyperlink to the organization.

  • OASIS - Organization for advancement of structured information standards
  • W3C - The World Wide Web Consortium
  • WS-Interoperability - The Web Services Interoperability Organization.

Stakeholders/Roles

  • external and internal users of government information and services
  • business service architects
  • business analysts
  • application developers
  • operations managers

Roadmap

The Commonwealth is offering a variety of ESB capabilities through interoperable tool suites to meet Agency service level objectives for managed file transfers, messaging and service-call integrations.

The Commonwealth is currently maintaining a shared messaging service called CommBridge, which was built on top of IBM's WebSphere MQ (see Enterprise Technology Solution below).

CommBridge is being replaced by an updated, SOA-capable service, called Interchange. Interchange supports file transfers within the Commonwealth as well as between the Commonwealth and external partners. It offers a secure set of mechanisms for managed file transfers, including the ability to exchange files between systems and/or individuals. Additionally, Interchange has been developed in a service-oriented fashion, with the ability to support multiple protocols such as secure FTP-variants, HTTPS and MQ File Transfer Edition. The supported set of protocols allows Agencies to meet their unique service level objectives while leveraging a consolidated service framework. Agencies that currently use CommBridge are upgrading their services to use Interchange.

 

EnterpriseTechnology Solution

The Enterprise Service Bus ESB is expected to enable the integration and orchestration of services. To do this, the ESB must support a number of different protocols and must also be able to enforce enterprise-wide policies and governance, including but not limited to compliance with standards. Service-level integration comes in many different forms including managed file transfers, messaging and service calls.

The legacy Enterprise ESB Shared Service, CommBridge Service Bus (CSB), is based on WebSphere MQ. It provides assured once-only delivery of messages across more than 35 different vendor platforms using a variety of communications protocols. The transportation of message data is made possible through the use of a network of WebSphere MQ queue managers. Each queue manager hosts local queues that are containers used to store messages. Through remote queue definitions and message channels, data can be transported to its destination queue manager. CommBridge is being deprecated in favor of Interchange.

To use CommBridge an agency application must make a connection to a WebSphere MQ queue manager, the services of which will enable it to receive (get) messages from local queues, or send (put) messages to any queue on any queue manager. The application’s connection may be made directly (where the queue manager runs locally to the application) or as a client to a queue manager that is accessible over the network. WebSphere MQ supports a variety of application programming interfaces (including JMS), which provide support for several programming languages as well as point-to-point and publish/subscribe communication models.

Interchange enhances the managed file transfer enterprise solution in a manner that makes it possible for it to participate in the ESB. As such, Interchange supports not one but multiple protocol endpoints such as flavors of FTP, HTTP and MQ. The complete Interchange solution relies on a number of SAI components such as the XML Gateway appliances for secondary completion, JScape application server, for protocol mediation, and Apache Camel for integration.

Interchange relies on the use of centralized metadata for the control of the file transfers and unlike its legacy predecessor is not a point-to-point solution. Additionally, Interchange provides enhanced governance and monitoring capabilities with the use of log-in solutions and message-driven notifications.
 

Associated Technology Areas

  • Messaging Services
  • Transformation Services (TBD)



 

Integration > EnterpriseService Bus >

5.2.1 Technology Area: Messaging Services

Description

The most critical requirement for SOA Messaging Services is guaranteed delivery. Guaranteed messaging ensures that messages are reliably delivered once, and only once, to their intended customers. Guaranteed messaging, traditionally a key requirement for financial and B2B supply chain markets, is increasingly a "must have" for government as well. Additionally, mobile clients need to be able to retrieve their messages on demand--as opposed to having to stay logged on and subscribed to a particular topic all the time. To support an on-demand delivery of messages, they need to be marked as persistent.

Persistent messages must be recovered in the case of an MQ or client failure, and the MQ server must provide the retrieve-on-demand flexibility discussed above. JMS-compliant MQ servers that support guaranteed delivery of persistent messages implement an offline storage mechanism for persisting messages to local disk or databases or across storage devices attached to a storage area network (SAN). This storage ensures message recoverability in the event of an MQ or client failure.

SOAP over HTTP, and SOAP over MQ, are widely accepted and interoperable messaging and transport protocols that are supported in a broad variety of environments. JMS and RMI are not supported on platforms other than the Java platform. They form a good framework for integrating applications running within J2EE environments.

Technology Specification: Java Messaging Service (JMS)

Description -At its simplest level, JMS sends messages between Service Providers and Service Consumers. The format of these messages is quite flexible and can include ordinary text messages (including raw text, SOAP, and XML), entire Java objects, and "empty" messages that are suitable for basic communication (like acknowledgments). What's different about JMS compared with low-level TCP/IP packets and Java Remote Method Invocation (RMI) is that while the other methods normally require real-time connectivity and messages that are sent synchronously, JMS systems are more flexible. In asynchronous mode, which is the default mode for JMS, clients don't have to be connected all the time.

Guidelines - JMS is not recommended for .NET to .NET messaging. JMS is recommended for J2EE to J2EE server messaging. JMS supports two modes of message delivery, in JMS specification terms, PERSISTENT and NON_PERSISTENT. The NON_PERSISTENT mode has the least overhead, and therefore is more efficient and considered “reliable,” but can lose data if there is a JMS provider failure, such as power loss. There is no requirement for messages to be logged to stable storage. PERSISTENT mode requires message logging in the case of a JMS provider failure. There is more overhead to this method, but because of the logging and stored data feature, this mode is considered “guaranteed.”

Standards & Specifications -

  • JMS v. 1.1 - The JMS 1.1 specification is a set of interfaces described in the J2EE specification that defines how a J2EE application component interacts with an enterprise messaging system. The actual implementation of the JMS interfaces is provided by enterprise messaging system vendors. The JMS specification allows developers to write vendor-neutral messaging applications without having to learn the native APIs of different enterprise messaging systems.
    Refer to: http://java.sun.com/products/jms/docs.html

Migration - Although CommBridge still provides much value for legacy application integration, it is a proprietary API. Agencies looking for Java interoperability and support for service oriented applications based on open standards, should consider JMS with a WebSphere MQ JMS Provider. JMS isn't a direct competitor to Web Services. One of its main uses is to make SOAP-based Web services more robust on the Java platform (pending WS-Reliability). With the capability for reliable, asynchronous messaging, JMS will have a role to play in SOA for the foreseeable future.

Technology Specification: Simple Object Access Protocol (SOAP)

Description - SOAP is a specification that defines application-level structure for messages. For two applications to integrate, they must agree upon an explicit message structure. SOAP provides an application-level message structure for use over numerous transport protocols. Applications that speak SOAP can easily exchange information with other applications that speak SOAP, facilitating integration between disparate systems. The SOAP message structure consists of a body that contains the request content and headers that contain extended information for security, routing, transactions, etc.

Guidelines - When using SOAP 1.1 an application can expose its data over one of several transport protocols, such as HTTP or MQ, and provides a standard request and response structure as defined by the SOAP specification. This structure allows other SOAP-enabled applications to easily integrate.

Standards & Specifications -

  • SOAP v. 1.1 - The MEMBER SUBMISSION SOAP 1.1, published as a W3C NOTE, consists of three parts:
    • The SOAP envelope construct defines an overall framework for expressing what is in a message; who should deal with it, and whether it is optional or mandatory.
    • The SOAP encoding rules defines a serialization mechanism that can be used to exchange instances of application-defined data types.
    • The SOAP RPC representation defines a convention that can be used to represent remote procedure calls and responses.

Although these parts are described together as part of SOAP 1.1, they are functionally orthogonal. In particular, the envelope and the encoding rules are defined in different namespaces in order to promote simplicity through modularity.
Refer to:
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

Migration Strategy - SOAP 1.2 has now been ratified by the W3C and supports the binding of SOAP with multiple transport protocols. However, it has not yet been included in the WS-I Basic Profile. Therefore, the latest SOAP version has not yet been tested for interoperability. Use of this new standard will require agencies to do their own interoperability testing until such time as the WS-I Basic Profile is updated. The ETRM standards will be revised to reflect revisions to the WS-I Basic Profile.

Technology Specification: WS-Addressing


Description - Applications that exchange messages using SOAP typically communicate through networks with intermediate nodes such as firewalls and gateways, and may use a variety of underlying transport protocols, such as HTTP, MQ, or JMS. Such applications need a mechanism for indicating the ultimate destinations of such messages -- without knowledge of or concern for the particular transport protocols involved. This is analogous to the use of a "To the Attention of" indication in the address on an envelope sent through the postal service.

A variety of message exchange patterns may be used. Therefore, one needs to be able to specify the reply destination and where to send fault information, etc. One also needs a mechanism indicating to which message an application is replying.

The WS-Addressing specification defines two key interoperable constructs in order to meet these needs. First, it defines endpoint references, which provide a general-purpose, transport-neutral way to convey the addressing information needed to reach service endpoints. This makes it possible for messaging systems to support transmission through network that includes processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner. Second, it defines standard SOAP message information headers to support the use of such endpoint references in addressing and exchanging Web service messages such as the "To", "Action", "ReplyTo", and "RelatesTo" headers. These enable considerable flexibility in the use of a wide variety of message exchange patterns, such as asynchronous reply and extended conversations.

Guidelines - Agencies should use WS-Addressing to decouple message addressing concerns from the underlying transport. New service-oriented applications must support and adopt the use of WS-Addressing.

Standards & Specifications -
•WS-Addressing 1.0 - Core
Refer to: http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/
•WS-Addressing 1.0 - Metadata
Refer to: http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/
•WS-Addressing 1.0 - SOAP Binding
Refer to: http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/


Migration Strategy - Agencies not presently using WS-Addressing for legacy services are strongly encouraged to adopt it and migrate towards its use as soon as feasible. Mediation services such as provided by an Enterprise Service Bus or Interchange may be used to facilitate such migration.


TECHNOLOGY SPECIFICATION: SOAP MESSAGE TRANSMISSION OPTIMIZATION MECHANISM (MTOM)

Description - The use of SOAP to exchange XML messages containing large quantities of binary data, such as images, can incur significant processing and efficiency costs as a result of the default mechanism for representing that data as text characters. Two specifications (MTOM and XOP) provide a means to mitigate these costs. SOAP Message Transmission Optimization Mechanism (MTOM) defines an abstract feature for optimizing the transmission and/or wire format of SOAP messages. The XML-binary Optimized Packaging (XOP) specification defines a convention for efficiently representing XML Infosets that contain certain kinds of content, such as elements containing large amounts of binary data. The concrete implementation specificied by MTOM depends on the use of XOP.


The MTOM specification provides a binding for use with SOAP 1.2 (the current specification at the time MTOM and XOP were formalized). The SOAP 1.1 Binding for MTOM 1.0 specifies the minimal modifications to MTOM and XOP to enable these facilities to be used interoperably with SOAP 1.1.


Guidelines - Applications that need to exchange SOAP messages containing potentially large binary data elements should use MTOM to optimize the transmission of those messages and reduce the performance burden imposed on the receiver(s) of those messages.

Standards & Specifications -
•SOAP Message Transmission Optimization Mechanism
Refer to: http://www.w3.org/TR/soap12-mtom/
•XML-Binary Optimized Packaging
Refer to: http://www.w3.org/TR/xop10/
•SOAP 1.1 Binding for MTOM 1.0
Refer to: http://www.w3.org/Submission/2006/SUBM-soap11mtom10-20060405/


5.2.2 TECHNOLOGY AREA: MANAGED FILE TRANSFERS

Description - File Transfer is an integration style where applications make use of files as a mechanism to integrate between applications*. File transfers can be managed or unmanaged.

Unmanaged file transfers are not monitored and offer limited auditability and reliability. Managed file transfers (MFT) refer to software solutions / applications that facilitate the secure, auditable and reliable transfer of files from one system to another over multiple protocols and network topologies, providing a higher level of control, and visibility.

Agencies should consider these additional non-functional requirements when determining file transfer needs:
•auditability
•security
•recoverability
•reliability
•platform independence
•reporting/statistics
•centralized monitoring
•policy-based requirements (HIPAA, PCI, etc)

The Interchange platform has been sourced and deployed to mediate managed file transfers between Agency applications. It provides several operational and security advantages.
 

Technology Specification: Interchange - Enterprise Service

 

Description - The overall success of the Commonwealth's agency IT systems depends on the ability to integrate across agency boundaries, legacy systems and emerging technologies. Interchange is the door to this capability, allowing the streamlining of business processes and consequently reducing the cost of doing business.

Interchange consists of a set of client components and server components. As part of the upgrade to the latest version, the previously unsupported version of IBM's MQ Server software is replaced by IBM's WMQ File Transfer Edition; a product specifically designed to handle robust file transfers between agencies and partners while still leveraging the IBM MQ software to provide guaranteed delivery and other benefits. (Interchange is being continually updated to support other protocols in addition to MQ.)
 

Interchange is part of the SAI program, a collaboration between technology and business to develop Enterprise shared services that can be used by multiple agencies to support Service Oriented Architecture (SOA) applications.

Guidelines - When building new applications or business processes (or modifying those in existence, e.g. CommBridge-dependant or not) that contain inter Agency data transfers, Agencies must maximally leverage Interchange.

The welcome kit can be found here: https://wiki.state.ma.us/confluence/display/sai/Interchange+Welcome+Kit.
 

For current CommBridge customers, a link to the FAQ can be found here: https://wiki.state.ma.us/confluence/display/sai/CommBridge+Customers+FAQ%27s

Standards & Specifications -

•OASIS - Organization for advancement of structured information standards
•W3C - The World Wide Web Consortium
•WS-Interoperability- The Web Services Interoperability Organization.

Migration Strategy - Interchange is available today for customers upgrading from Legacy CommBridge who currently use IBM MQ Series. In addition to support for IBM MQ, Interchange system has extended its adapter offerings to include file FTP, SFTP and FTPS. Many of these offerings are already in the testing phases.

Legacy CommBridge users may be familiar with running an MQ Server in their environment. In the new Interchange system this will likely change. In business terms, your agency is likely to only need some client software. In more technical terms, the overall architecture is moving to more of a "bus" topology featuring transformation and orchestration, rather than a "point-to-point" or "hub and spoke" client-server topology.

Technology Specification: File Transfer Protocol (FTP)

Description - File Transfer Protocol (FTP) is a technical protocol for transporting large files (bigger than can travel via email attachment). There is frequently a business need to exchange large amounts of data at one time between Agencies. Several standards exist and most browsers are capable of using FTP with an FTP enabled server (or a host machine acting as an FTP server) that contains the file to be transferred.

Guidelines - Agency data often must be protected in flight (while it is moving from point A to point B), so similar encrypted protocols must be used. Agencies have a business need (based on legacy system capability) that is currently or will soon be supported generically as part of Interchange: We should add guidelines that encourage agencies to use Interchange as the MFT service of choice. In particular, while the protocols below may be used to establish an endpoint connection to the Enterprise Services, they should be considered simply that: the protocol that is being used and NOT a recommendation from the ETRM that every agency should host a FTP server, for instance. In my opinion, the best way to offer the guidance is to indicate that agencies should use the Interchange MFT service to gain benefits such as monitoring, auditability, enhanced security, virus scanning, compliance with policies, etc.)

• SSH File Transfer Protocol (SFTP) is an incompatible secure file transfer subsystem for the Secure Shell (SSH) protocol.
• FTP Secure or FTP-SSL (FTPS) is an extension to FTP that adds support for the Transport Layer Security (TLS) and the Secure Sockets Layer (SSL) cryptographic protocols.
• Secure Copy (SCP) is based on the Secure Shell protocol

Standards & Specifications - FTP, FTPS, SFTP

• FTP - RFC 959 - http://www.ietf.org/rfc/rfc959.txt
• FTPS - RFC 4217 - http://www.ietf.org/rfc/rfc4217.txt
• SFTP - INTERNET DRAFT - http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13&nbsp [expired in 2007; likely still valid; monitor status]

Migration Strategy -

 

Integration >

5.3 Discipline: Transport

Description

The transport discipline addresses the various protocols that can be used to carry requests, responses and data for services exposed by the Commonwealth.

Boundary

The Transport Discipline addresses higher level protocols that applications and services use to communicate with each other. It does not cover lower level protocols like TCP/IP that are addressed in the Integration Domain. Security issues related to this Discipline are addressed in the Security Domain.

Stakeholders/Roles

  • external and internal users of government information and services
  • content managers
  • application developers

Roadmap

Moving toward a Service Oriented Architecture requires consideration of newer higher-level protocols such as Simple Object Access Protocol (SOAP) used to transport data between services. These protocols have to be safely accommodated within an enabling enterprise security architecture.

Enterprise Technology Solution

Not applicable

Relevant Standards Organizations

Additional information about the Standards Organizations listed below can be found in the Introduction section of the ETRM or by clicking on the hyperlink to the organization.

  • IETF - The Internet Engineering Task Force
  • ISO - The International Standards Organization
  • OASIS - Organization for advancement of structured information standards
  • W3C - The World Wide Web Consortium

Associated Technology Areas

  • Protocols

 

Integration > Transport >

5.3.1 Technology Area: Protocols

Description

Protocols are sets of formal rules describing how to transmit data. This technology area addresses high level protocols that deal with the data formatting, including the syntax of messages, metadata, character sets, sequencing of messages, etc.

Technology Specification: Hypertext Transfer Protocol (HTTP)

Description - The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request, modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metadata, and possible entity-body content.

Guidelines - HTML is the de facto standard for internet communications and should be used for delivering content and services over the internet.

Standards and Specifications -

  • HTTP v. 1.1: HTTP is now considered a stable specification recommended by the WC3 and given STD RFC status by the Internet Engineering Task Force (IETF).
    Refer to: http://www.w3.org/Protocols/#IETF

Technology Specification: Hypertext Transfer Protocol over Secure Socket Layer (HTTPS)

Description - HTTPS is Hypertext Transfer Protocol over Secure Socket Layer or HTTP over SSL. HTTPS encrypts and decrypts the page requests and page information between the client browser and the Web Server. HTTPS uses port 443 instead of the HTTP port 80 and usually uses a 40/128bit encryption algorithm from the client to the server.

SSL, developed by Netscape Communications Corporation, is the industry-standard method for protecting web communications. The SSL security protocol provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. Because SSL is built into all major browsers and web servers, simply installing a digital certificate turns on their SSL capabilities.

Guidelines - Since the Internet is an open network, agency services should not communicate confidential or otherwise sensitive information such as Social Security numbers or credit card transactions without encrypting the communication session via SSL. Additionally, it is a compliance requirement to utilize SSL v. 3.0 in usages covered by the Payment Card Industry (PCI) Data Security Standard (DSS).

Standards and Specifications -


* Enterprise Integration Patterns, by Hohpe and Woolf - http://www.eaipatterns.com/toc.html