Updated on July 14, 2022
What is a Service Gateway?
The Service Gateway is a set of .NET web services that reside on Windows servers that enable the exchange of information between the various software products. These web services provide the entry point for real-time integration to JHA’s core banking systems.They also provide access to additional Jack Henry products that act as a jXchange Service Provider (e.g., products such as 4|sight, Synergy, and Argo). The jXchange product is modeled after the SOA architecture.
All the business services exchange their information through the Service Gateway. The information exchange is in the form of XML. Service Gateway provides for the designation of configured providers for all business services that are used by the institution. It allows mapping of all operations for the service providers. It also provides security for the exchange of information by designating authorized users.
Web Service Description Language (WSDL)
WSDLs are provided with the Data Contracts (XSDs) at the appropriate time whether it is before the initial development cycle or at the time a new point release becomes available. Once access to jXchange servers and download services have been established, contracts can be generated from the WSDL files that are delivered to you.
XML is a self-describing language and parsing, or syntactic analysis of the sequence of tokens, and is a prerequisite for consuming web services. Without the programmatic ability to parse the tokens or elements, applications are not able to keep pace with the technology occupied by jXchange. Processing XML as plaintext hinders the ability to consume the next release of jXchange and its additional services and operations without a development effort.
Authentication in the jXchange product family now relies on Active Directory as our account store. It allows a single repository for accounts that falls into the financial institution’s existing infrastructure,allowing easier, more familiar management of accounts by bank personnel. It allows the bank to enforce their policies on jXchange product accounts to satisfy their internal regulatory requirements.
General Description of Security Model
The security model for the Gateway boundary provides authentication and authorization with the WS-Security specification’s Username Token Profile. The cryptographic protocol Secure Socket Layer (SSL) is used for transport-level security which provides both confidentiality and integrity. Messages destined for the Third-Party Gateway Web Service must include at least two elements in the WS-Security SOAP header: one element for the username and the second element for the password.
The jXchange system restricts access to its interfaces using a Role Based Access Control (RBAC) system. A third-party system’s identity must have been associated with the required role for a given operation on a service. The institution, a JHA client, manages the association of roles to identities. A given identity can be associated with more than one role. An operation on a service may restrict access by requiring a role, may deny access to callers that are a member of a particular role, or may not restrict access to the operation at all. The jXchange system restricts access to operations using RBAC. Bank association also restricts access. The caller must be associated with the bank the target service has been assigned to. The institution also controls the assignments of callers to banks.
Certificates are issued by a trusted source. Jack Henry has a business relationship with a certificate provider and provides highly trusted and secure certificates. jXchange only utilizes server-based certificates. It does not require client certificate processing. The publicly trusted root of the SSL certificate must be in the application’s proper certificate store for processing.
jXchange Release Cycle
jXchange Web Services are upgraded to the current release at least once annually.
Multiple Point Releases
jXchange can have multiple releases annually. Any point release may represent either minor or major updates or upgrades.
jXchange end-to-end services are designed to allow both forward and backward compatibility from release to release. For example, jXchange may be at the 2009.1 release while SilverLake is at the 2010 release, or jXchange may be at the 2010 release while SilverLake is at the 2009 release. Not all potential functionality is available, but current functionality is available and unhindered.
jXchange Release Classification Types
jXchange server updates are transparent to the consumer of the web services. After a scheduled server update, connectivity can be resumed without any changes to the application or correlating configuration files.
Changes that can be made through configuration files to resume web service connectivity after an update has been made to the jXchange server. Example: URL Address endpoint extension change from .ashx to .svc.
Release is not compatible with previous releases. The application that consumes the web service must be modified to match the new contracts to resume connectivity. Support for the release before the breaking change has a sunset date and is not enhanced with new operations or services.
The standards jXchange follows are:
- HTTPS : http://en.wikipedia.org/wiki/HTTP_Secure
- SOAP : http://www.w3.org/TR/soap/
- W3C : http://www.w3.org/
- WSDL : http://www.w3.org/TR/wsdl
- XML : http://www.w3.org/XML/
Web Service Standards
The following Web Services standards are being used in the design and construction of jXchange. Messaging with jXchange from third party vendors must comply with the standards for effective communication:
- SOAP 1.1 for standard and error messaging.
- XML Schema 2001 (W3C).
- WS-I Basic Profile 1.0 for basic architecture built against compliance with the standard. The system
- follows WSI usage scenarios and synchronous messaging scenarios.
- WS-I BP 1.0 for security model in compliance with WS-I Basic Security Profile 1.0.
- OASIS WS-Security 1.0 specification using a hybrid solution of transport level security (SSL) and
- WS-Security in compliance with WS-I Usage Scenarios 1.0.
- WS-I Usage Scenarios 1.01.
jXchange Sandbox Development Environment
Jack Henry offers a jXchange development environment for consumers to access during their development cycle.
This environment has a strict URL Path Policy applied; in that you must hit the jXchange DMZ Services on a URL Path that is valid for jXchange Web Services, or your communication attempt is discarded. The URL paths are given to you in the credentials email after access is granted.
Access to the DMZ requires:
- Signed Confidential and Certification Agreement
- Signed Vendor Access Agreement
- Vendor Integration Program participation
- Certification Fee
This environment provides all the supported business providers to which the Service Gateway integrates. This environment is always kept at the current GA release of jXchange. Previous releases are not supported or available in this environment. Access to this environment allows a close working relationship with the jXchange support staff and expediting the process and development of the vendor products.
Consumers are required to test all operations applicable to their specific application to verify that the XSD contract schema requirements are being met.
Maintenance periods on this environment are scheduled every Monday from 4:30 a.m. Central Standard Time through 6:30 a.m. Central Standard Time. System maintenance may not be performed every day, but when it is needed jXchange Support attempts to isolate it to these hours. Maintenance can include but is not limited to:
- Server patching and upgrades.
- Hardware upgrades.
- Core processing hours for test banks.
- Core component upgrades.