U.S. patent application number 13/784352 was filed with the patent office on 2013-09-05 for integration gateway.
This patent application is currently assigned to Bally Gaming, Inc.. The applicant listed for this patent is BALLY GAMING, INC.. Invention is credited to Prasoona Lanka, Suren Raj Magenthrarajah, Prabhushankar Muthuswamy, Arvind Patil, Arun Rajaraman.
Application Number | 20130231190 13/784352 |
Document ID | / |
Family ID | 41507742 |
Filed Date | 2013-09-05 |
United States Patent
Application |
20130231190 |
Kind Code |
A1 |
Rajaraman; Arun ; et
al. |
September 5, 2013 |
INTEGRATION GATEWAY
Abstract
A message oriented middleware server application executable by
at least one processor implements a message oriented middleware
message provider that mediates messaging operations with a
plurality of heterogeneous applications including a number of
casino gaming applications, where instances of the heterogeneous
applications which execute on the plurality of networked
processor-based client devices including the networked
processor-based casino gaming devices.
Inventors: |
Rajaraman; Arun; (Marietta,
GA) ; Lanka; Prasoona; (Chennai, IN) ;
Magenthrarajah; Suren Raj; (Trichy, IN) ; Muthuswamy;
Prabhushankar; (Chennai, IN) ; Patil; Arvind;
(Pune, IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
BALLY GAMING, INC. |
Las Vegas |
NV |
US |
|
|
Assignee: |
Bally Gaming, Inc.
Las Vegas
NV
|
Family ID: |
41507742 |
Appl. No.: |
13/784352 |
Filed: |
March 4, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12500298 |
Jul 9, 2009 |
8412768 |
|
|
13784352 |
|
|
|
|
61080165 |
Jul 11, 2008 |
|
|
|
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
H04L 67/28 20130101;
H04L 67/38 20130101; G07F 17/3225 20130101; H04L 67/2823
20130101 |
Class at
Publication: |
463/42 |
International
Class: |
G07F 17/32 20060101
G07F017/32 |
Claims
1.-29. (canceled)
30. A networked server system for use in mediating electronic
message communication among heterogeneous client devices in a
casino gaming environment, the networked server system comprising:
an integration gateway server, selectively communicatively coupled
by a network to one or more client devices, the integration gateway
server programmed to execute instructions that permit communication
therebetween, according to a selected one of a plurality of
messaging models, wherein, when an asynchronous point-to-point
messaging model is active, the integration gateway server computer
queues an electronic message from a message producing client
device, and delivers the queued electronic message to a designated
message consuming receiver client device; and when an asynchronous
publish/subscribe messaging model is active, the integration
gateway server computer gathers electronic messages at a topic
destination, and distributes the electronic messages gathered at
the topic destination to a plurality of message consuming
subscriber client devices.
31. The networked server system of claim 30, further comprising the
one or more message producing client devices.
32. The networked server system of claim 30, further comprising the
one or more message consuming subscriber client devices.
33. The networked server system of claim 30 wherein the integration
gateway server distributes the electronic messages to a particular
message destination specified in a message header.
34. The networked server system of claim 30 wherein the integration
gateway server delivers the queued electronic message to a
particular message destination specified in a message header.
35. The networked server system of claim 30 wherein the integration
gateway server is further programmed to execute instructions that:
receive platform-specific data from one or more message producing
client devices; store the platform-specific data in a message
destination; transform the platform-specific data; re-format the
platform-specific data; and deliver the transformed, re-formatted
data to a message consuming client device.
36. The networked server system of claim 30, further comprising a
transceiver that provides wireless communication.
37. The networked server system of claim 30 wherein the client
devices are casino gaming machines.
38. A method of mediating electronic messages between heterogeneous
client devices in a casino gaming environment by an integration
gateway server computer, the method comprising: when an
asynchronous point-to-point messaging model is active, queuing an
electronic message from a message producing sender client device;
and delivering the electronic message held in the queue to a
designated message consuming receiver client device; and when an
asynchronous publish/subscribe messaging model is active, gathering
electronic messages at a topic destination; and distributing the
electronic messages at the topic destination to a plurality of
message consuming subscriber client devices.
39. The method of claim 38, further comprising mediating electronic
messages in accordance with a synchronous request/response
messaging model.
40. The method of claim 38 wherein the queuing the electronic
message includes holding the message when the receiver client
device is inactive.
41. An integration gateway server communicatively coupled to one or
more processor-based casino gaming devices, the integration gateway
server comprising: a processor; and a non-transitory
processor-readable storage medium communicatively coupled to the
processor, the storage medium having instructions stored thereon
that cause the processor to: log electronic messages having
different, platform-specific formats; perform one or more data
transformations that re-format the electronic messages to allow
cross-platform communication among the casino gaming devices; and
implement communication services using acknowledgement protocols to
ensure message integrity.
42. The integration gateway server of claim 41 wherein the
non-transitory processor-readable storage medium stores a
database.
43. The integration gateway server of claim 41 wherein the
instructions further cause the processor to provide local
configuration cache services.
44. The integration gateway server of claim 41 wherein the
communication services are implemented in accordance with a System
to System (S2S) gaming industry acknowledgement protocol to enable
communication among heterogeneous casino gaming devices.
45. A non-transitory computer-readable medium communicatively
coupled to a processor, the non-transitory computer-readable medium
having computer-executable instructions stored thereon that when
executed by the processor cause the processor to implement an
integration gateway that: provides a stand-alone user interface for
setup and maintenance of the casino gaming machines. establishes
cross-platform communication among heterogeneous casino gaming
machines according to synchronous and asynchronous messaging
models; performs data transformations to manipulate and re-format
platform-specific message data according to a synchronous messaging
model; and performs data transformations to manipulate and
re-format platform specific message data according to an
asynchronous messaging model.
46. The non-transitory computer-readable medium of claim 45 wherein
the messaging models supported by the integration gateway include
one or more of a publish/subscribe messaging model, a
point-to-point messaging model, and a request-reply messaging
model.
47. The non-transitory computer-readable medium of claim 45 wherein
the heterogeneous casino gaming machines include legacy systems and
newer products based on evolving technologies.
48. The non-transitory computer-readable medium of claim 45 wherein
messaging functions provided by the integration gateway include one
or more of guaranteed message delivery, fast message delivery,
receipt notification, transaction control, or a data persistence
mechanism.
49. The non-transitory computer-readable medium of claim 45 wherein
the instructions stored thereon further include shared functions
and interceptor services.
50. The non-transitory computer-readable medium of claim 48 wherein
the messaging functions utilize objects including one or more of
connection factories, connections, sessions, producers, consumers,
messages, or destinations.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] This description generally relates to the field of
communications networks, and more particularly to middleware for
facilitating communication in heterogeneous communications
networks.
[0003] 2. Description of the Related Art
[0004] Many gaming properties are attempting to integrate and
leverage the information and capabilities provided by all of the
computing devices located on their property. This would provide
players with a more seamless experience, as they would have access
to greater functionality at every computing device they interact
with. Moreover, the gaming properties will also be able to better
track players' activities and better determine what service appeal
to which players.
[0005] Unfortunately, gaming properties typically include a variety
of different gaming devices, gaming servers and gaming software.
Often, these gaming devices, gaming servers and gaming software
have been distributed by different gaming suppliers, and may be
associated with proprietary protocols developed by each of those
different gaming suppliers. Indeed, many gaming properties have
legacy gaming devices and software on their gaming floors that use
protocols that are no longer supported. Thus, the task of
interoperability and communication has been made much more
difficult by these heterogeneous components. Although there are
communication standards that have been developed by groups such as
the Gaming Standards Association, many gaming suppliers expand upon
(or even ignore) these standards in order to improve the
functionality they can offer.
[0006] It would therefore be desirable to enable improved
communication between heterogeneous components in a gaming
property.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0007] FIG. 1 is a schematic view of a network including an
integration gateway for enabling communications among heterogeneous
components, according to one illustrated embodiment.
[0008] FIG. 2 is a schematic view of one example architecture for
the integration gateway of FIG. 1, according to one illustrated
embodiment.
[0009] FIG. 3 is a process flow showing a messaging process,
according to one illustrated embodiment.
[0010] In the drawings, identical reference numbers identify
similar elements or acts. The sizes and relative positions of
elements in the drawings are not necessarily drawn to scale. For
example, the shapes of various elements and angles are not drawn to
scale, and some of these elements are arbitrarily enlarged and
positioned to improve drawing legibility. Further, the particular
shapes of the elements as drawn, are not intended to convey any
information regarding the actual shape of the particular elements,
and have been solely selected for ease of recognition in the
drawings.
DETAILED DESCRIPTION OF THE INVENTION
[0011] In the following description, certain specific details are
set forth in order to provide a thorough understanding of various
disclosed embodiments. However, one skilled in the relevant art
will recognize that embodiments may be practiced without one or
more of these specific details, or with other methods, components,
materials, etc. In other instances, well-known structures
associated with servers, networks, displays, and/or with computer
type devices have not been shown or described in detail to avoid
unnecessarily obscuring descriptions of the embodiments.
[0012] Unless the context requires otherwise, throughout the
specification and claims which follow, the word "comprise" and
variations thereof, such as, "comprises" and "comprising" are to be
construed in an open, inclusive sense, that is as "including, but
not limited to."
[0013] Reference throughout this specification to "one embodiment"
or "an embodiment" means that a particular feature, structure or
characteristic described in connection with the embodiment is
included in at least one embodiment. Thus, the appearances of the
phrases "in one embodiment" or "in an embodiment" in various places
throughout this specification are not necessarily all referring to
the same embodiment. Furthermore, the particular features,
structures, or characteristics may be combined in any suitable
manner in one or more embodiments.
[0014] As used in this specification and the appended claims, the
singular forms "a," "an," and "the" include plural referents unless
the content clearly dictates otherwise. It should also be noted
that the term "or" is generally employed in its sense including
"and/or" unless the content clearly dictates otherwise.
[0015] The headings and Abstract of the Disclosure provided herein
are for convenience only and do not interpret the scope or meaning
of the embodiments.
[0016] Any process descriptions or blocks in flowcharts described
below may be understood as representing modules, segments, or
portions of code which include one or more executable instructions
for implementing specific logical functions. In alternative
embodiments, various logical functions, or acts may be executed out
of order from that shown or discussed, including substantially
concurrently or in reverse order, and/or manually, depending on the
functionality involved, as would be understood by those reasonably
skilled in the art.
Glossary
[0017] Acknowledgement: Control messages exchanged between clients
and broker to ensure reliable delivery. There are two general types
of acknowledgement: client acknowledgements and broker
acknowledgements.
[0018] Administered Objects: A pre-configured object--a connection
factory or a destination--that encapsulates provider-specific
implementation details, and is created by an administrator for use
by one or more JMS clients. The use of administered objects allows
JMS clients to be provider-independent. Administered objects are
placed in a JNDI name space by and are accessed by JMS clients
using JNDI lookups.
[0019] Asynchronous Messaging: An exchange of messages in which the
sending of a message does not depend upon the readiness of the
consumer to receive it. In other words, the sender of a message
need not wait for the sending method to return before it continues
with other work. If a message consumer is busy or offline, the
message is sent and subsequently received when the consumer is
ready.
[0020] Authentication: The process by which only verified users are
allowed to set up a connection to a broker.
[0021] Authorization: The process by which a message service
determines whether a user can access message service resources,
such as connection services or destinations, to perform specific
operations supported by the message service.
[0022] Broker: The Message Queue entity that may manage, inter
alia, message routing, delivery, persistence, security, and
logging, and that provides an interface for monitoring and tuning
performance and resource use.
[0023] Client: An application (or software component) that
interacts with other clients using a message service to exchange
messages. The client can be a producing client, a consuming client,
or both.
[0024] Connection: A communication channel between a client and a
broker used to pass both payload messages and controls.
[0025] Messages Connection Factory: The administered object the
client uses to create a connection to a broker. This can be a
Connection Factory object, a Queue Connection Factory object or a
Topic Connection Factory object.
[0026] Consumer: An object (Message Consumer) created by a session
that is used for receiving messages sent from a destination. In the
point-to-point delivery model, the consumer is a receiver or
browser (Queue Receiver or Queue Browser); in the publish/subscribe
delivery model, the consumer is a subscriber (Topic
Subscriber).
[0027] Data store: A database where information (e.g., durable
subscriptions, data about destinations, persistent messages,
auditing data) needed by the broker is permanently stored.
[0028] Delivery mode: An indicator of the reliability of messaging:
whether messages are guaranteed to be delivered and successfully
consumed once and only once (persistent delivery mode) or
guaranteed to be delivered at most once (non-persistent delivery
mode).
[0029] Delivery model: The model by which messages are delivered:
either point-to-point or publish/subscribe. In JMS, there are
separate programming domains for each, using specific client
runtime objects and specific destination types (queue or topic), as
well as a unified programming domain.
[0030] Destination: The physical destination in a Message Queue
broker to which produced messages are delivered for routing and
subsequent delivery to consumers. This physical destination is
identified and encapsulated by an administered object that a client
uses to specify the destination for which it is producing messages
and/or from which it is consuming messages.
[0031] Encryption: A mechanism for protecting messages from being
tampered with during delivery over a connection.
[0032] Group: The group to which the user of a Message Queue client
belongs for purposes of authorizing access to connections,
destinations, and specific operations.
[0033] Message service: A middleware service that may provide
asynchronous, reliable exchange of messages between distributed
components or applications. It may include a broker, the client
runtime, the several data stores needed by the broker to carry out
its functions, and the administrative tools needed to configure and
monitor the broker and to tune performance.
[0034] Messages: Asynchronous requests, reports, or events that are
consumed by messaging clients. A message may have a header (to
which additional fields can be added) and a body. The message
header specifies standard fields and optional properties. The
message body contains the data that is being transmitted.
[0035] Messaging: A system of asynchronous requests, reports, or
events used by applications that may allow loosely coupled
applications to transfer information reliably and securely.
[0036] Producer: An object (Message Producer) created by a session
that is used for sending messages to a destination. In the
point-to-point delivery model, a producer is a sender (Queue
Sender); in the publish/subscribe delivery model, a producer is a
publisher (Topic Publisher).
[0037] Queue: An object created by an administrator to implement
the point-to-point delivery model. A queue is available to hold
messages even when the client that consumes its messages is
inactive. A queue may be used as an intermediary holding place
between producers and consumers.
[0038] Selector: A message header property used to sort and route
messages. A message service may perform message filtering and
routing based on criteria placed in message selectors.
[0039] Session: A single threaded context for sending and receiving
messages. This can be a queue session or a topic session.
[0040] Topic: An object created by an administrator to implement
the publish/subscribe delivery model. A topic may be viewed as a
node in a content hierarchy that is responsible for gathering and
distributing messages addressed to it. By using a topic as an
intermediary, message publishers may be kept separate from message
subscribers.
[0041] Transaction: An atomic unit of work that must either be
completed or entirely rolled back.
Integration Gateway--Middleware
[0042] FIG. 1 illustrates a network 10 including an integration
gateway module 12 for enabling communications among a number of
heterogeneous components. In one embodiment, the network 10 may
comprise a gaming network located within at least partially within
a gaming property. However, in other embodiments, the network 10
may comprise any of a variety of intranets, extranets, or other
networks.
[0043] As illustrated, the heterogeneous components within the
network 10 include applications 14, 16, other software components
18, and a number of servers 20a, b, c (collectively 20). The
applications 14, 16 and other software components 18 may
communicate with the integration gateway 12 via an application
programming interface 22 ("API"), while the servers 20 communicate
via their respective server interfaces 24a, b, c (collectively 24).
In one embodiment, the servers 20 may comprise a plurality of
different platforms and may communicate via their respective
platform interfaces.
[0044] As illustrated, the integration gateway module 12 may be
accessible via a computing system 26. As would be well understood
by those skilled in the art, the computing system 26 may comprise
any of a variety of computers/servers. In one embodiment, the
computing system 26 may enable administration and configuration of
the integration gateway 12.
[0045] The integration gateway 12 allows the components of the
network 10 to communicate despite their differences. Thus, these
heterogeneous components do not need to be recreated as homogeneous
elements. The integration gateway 12, sometimes referred to as
"middleware," may enable the software components (e.g.,
applications, enterprise java beans, servlets, and other
components) that have been developed independently and that run on
different networked platforms to interact with one another. In some
embodiments, the integration gateway 12 resides between the
application layer and the platform layer (i.e., the operating
system and underlying network services).
[0046] Applications distributed on different network nodes (e.g.,
applications executing on the servers 20) may use the integration
gateway 12 to communicate without having to be concerned neither
with the details of the operating environments that host other
applications nor with the services that connect them to these
applications. In addition, an administrative interface may be
provided on the computing system 26. This administrative interface
may enable personnel working on the network 10 to keep this virtual
system of interconnected applications reliable and secure. The
performance of the network 10 can also be measured and tuned, and
the network 10 may even be scaled without losing function.
[0047] In one embodiment, the integration gateway 12 may serve as a
single implementation/communication point to communicate with
various enterprise products. Each of these various enterprise
products (e.g., each of the servers 20) may use industry-specific
protocols, like the System to System (S2S) Protocol promulgated by
the Gaming Standard Association, in order to communicate with the
integration gateway 12. Indeed, a variety of different protocols,
including proprietary and standard protocols, may be used to
communicate via the integration gateway 12. The integration gateway
12 may also facilitate real-time information access among disparate
systems within the network 10, thereby helping to streamline
business processes and improve organizational efficiency.
[0048] Middleware can be generally grouped into the following
categories, which may each be supported by or integrated into the
integration gateway 12:
[0049] Remote Procedure Call or RPC-based middleware: Such
middleware may allow procedures in one application to call
procedures in remote applications as if they were local calls. The
middleware can implement a linking mechanism that locates remote
procedures and makes these transparently available to a caller.
This type of middleware may be handled by procedure-based or
object-based programs or components.
[0050] Object Request Broker or ORB-based middleware: Such
middleware may enable an application's objects to be distributed
and shared across heterogeneous networks.
[0051] Message Oriented Middleware or MOM-based middleware: Such
middleware may allow distributed applications to communicate and
exchange data by sending and receiving messages.
[0052] Each of these categories makes it possible for one software
component to affect the behavior of another component over the
network 10. They are different in that RPC- and ORB-based
middleware may create systems of tightly-coupled components,
whereas MOM-based systems may allow for a looser coupling of
components. In an RPC- or ORB-based system, when one procedure
calls another, the procedure may wait for the called procedure to
return before it can do anything else. As mentioned before, in each
of these categories, the middleware (i.e., the integration gateway
12, in one embodiment) functions partly as a super-linker, locating
the called procedure on the network 10 and using network services
to pass function or method parameters to the procedure and then to
return results.
Message Oriented Middleware
[0053] In general, MOM-based systems may make use of a messaging
provider to mediate messaging operations. The basic elements of a
MOM-based system are Clients, messages, and the MOM messaging
provider, which may include an API and administrative tools. The
MOM provider may use a variety of different architectures to route
and deliver messages: it can use a centralized message server, or
it can distribute routing and delivery functions to each Client
machine. Some MOM-based systems combine these two approaches.
[0054] Using a MOM-based system, in one embodiment, a Client makes
an API call to send a message to a destination managed by the MOM
provider. The call invokes provider services to route and deliver
the message. Once it has sent the message, the Client can continue
to do other work, while the MOM provider retains the message until
a receiving Client retrieves it. The message-based model, coupled
with the mediation of the MOM provider, makes it possible to create
a system of loosely-coupled components. The MOM-based system may
therefore be able to continue to function reliably, without
downtime, even when individual components or connections fail.
[0055] The MOM provider may also include an administrative
interface, using which an administrator can monitor and tune
performance. Client applications are thus effectively relieved of
messaging-related tasks except those of sending, receiving, and
processing messages. The MOM-based system and the administrator can
work to resolve issues like interoperability, reliability,
security, scalability, and performance, without modifying the
client applications.
Integration Gateway Overview
[0056] The integration gateway 12 may comprise a Java-based MOM
solution that allows client applications to create, send, receive,
and read messages in a distributed enterprise system, such as
network 10. Of course, in other embodiments, the integration
gateway 12 may be written in other programming languages, and may
run on a variety of platforms. The integration gateway 12 may
reduce the complexity of embedding diverse communication protocols
within the client applications, making it faster and easier to
integrate third-party host/legacy applications with newer products.
The integration gateway 12 may also improve the reliability,
flexibility and scalability of messaging. The heterogeneous nature
of the network 10 may arise from both the technology on which the
products in the network 10 are based and/or the protocols that they
support to communicate with the other systems.
[0057] The integration gateway 12 can play a variety of roles
within the network 10: it may comprise a stand-alone product or may
be used as an embedded component in a larger distributed runtime
system. As a standalone product, the integration gateway 12 may
define the backbone of an enterprise application integration
system. Embedded in an application server, the integration gateway
12 may support inter-component messaging. For example, J2EE uses a
JMS provider to implement message-driven beans and to allow EJB
components to send and receive messages. In one embodiment, message
mapping/conversion according to the destination requirements may be
implemented as a pluggable component. This may enable various
channels and products to exchange messages without being concerned
about potential incompatibilities.
[0058] The integration gateway 12 may provide a number of
features/advantages within the network 10: the integration gateway
12 may be flexible, scalable, reliable, and may provide synchronous
and asynchronous messaging across various platforms; the
integration gateway 12 may provide fast, guaranteed message
delivery, receipt notification, transaction control and a data
persistence mechanism for multiple products and platforms; the
integration gateway 12 may eliminate complexity of embedding
communication protocols in business logic; the integration gateway
12 may provide support for cross-platform Clients and servers; the
integration gateway 12 may support platform dependent communication
protocols, data formats and encoding; the integration gateway 12
may also support for the following messaging models:
Publish-Subscribe Messaging, Point-to-Point Messaging, and/or
Request-Reply Messaging; the integration gateway 12 may also
provide a stand-alone GUI for setup and maintenance, and may
support common message formats such as stream, text, and byte.
[0059] In one embodiment, the integration gateway 12 may provide a
flexible MOM solution, which may be easily customized according to
the needs of internal products which differ in technology and in
the interfaces used for communication. In another embodiment, the
integration gateway 12 may allow legacy systems to communicate
(e.g., indirectly via the integration gateway 12) with newer
products based on evolving technologies.
Integration Gateway Architecture
[0060] FIG. 2 shows one example architecture for the integration
gateway 12. As illustrated, the integration gateway 12 may include
the following: Local Configuration Cache Services 200, a Common
Services Layer 202, a Data Transformation Layer 204, a Messaging
Layer 206, a Communication Services Layer 208, and an Interceptor
Services Layer 210.
[0061] Each of these services comprising the integration gateway 12
is detailed in greater detail in the following sections.
Local Configuration Cache Services
[0062] The local configuration cache services 200 represent the
services configuration folder structure in the integration gateway
12. This services configuration folder structure may be created
during the installation process of the integration gateway 12 and
may be used to manage the configurations for each service provided
by the integration gateway 12. In one embodiment, the integration
gateway 12 does not include a database. Although, in other
embodiments, of course, the integration gateway 12 may include one
or more databases.
Common Services Layer
[0063] The common services layer 202 acts as a common services
layer. That is, the common services layer 202 may represent (and
provide access to) the common functions used by the integration
gateway 12, such as, logging, configuration, database access and
other foundation classes.
Data Transformation Layer
[0064] The data transformation layer 204 may include code that
forms the outlet for custom or platform-specific data manipulation
and formatting. This layer 204 may be used for data in both inbound
and outbound message Queues. The business logic execution may be
based on the message types used. (Example: Responding with an ACK
message in the S2S protocol for incoming messages.)
[0065] In one embodiment, the data transformation layer 204
supports the following data types: Simple Strings, XML (Complex),
Files, Images & Bitmaps (Byte Streams), and Serializable
Objects (Marshal By Value). In other embodiments, of course, other
data types may be supported.
[0066] The data transformation layer 204 may also support the
following data encoding options: ASCII, EBCDIC, and UTF-8. Again,
in other embodiments, other data encoding options may be
supported.
Messaging Layer
[0067] In one embodiment, the messaging layer 206 acts as a central
layer for the integration gateway 12, and enables the management of
messages and objects for inter-application communication. The
messaging layer 206 may be designed based on Publisher/Subscriber
or Point-to-Point (Asynchronous) messaging models utilizing JMS
Topics (Producer/Consumer Object classes). The messaging layer 206
may also use the Request/Response (Synchronous) model using JMS
Queues.
[0068] In one embodiment, the messaging layer 206 may enable
message persistence using Durable Topics/Queues, and may enable the
administration of integration gateway services using a stand-alone
user interface. The messaging layer 206 may also enable
configuration of certain services (e.g., Publisher/Subscriber and
Point-to-Point) using the stand-alone user interface. Finally, the
messaging layer 206 may include failover and load-balancing, which
may be implemented using Sun Java System Message Queue 4 2005Q1
Enterprise Edition.
[0069] Messaging Domains
[0070] Generally, the integration gateway 12 (and, in particular,
the messaging layer 206) may allow components and applications to
communicate by producing and consuming messages. The integration
gateway 12 defines two patterns or messaging domains that govern
this communication. These messaging domains are Point-to-Point
Messaging and Publish/Subscribe Messaging (as described above). The
integration gateway 12 may be configured to support either or both
of these patterns. The basic integration gateway objects include
connections, sessions, Producers, Consumers, destinations, and
messages that are used to specify messaging behavior in both
domains.
Point-to-Point Messaging
[0071] In the Point-to-Point domain, message Producers are called
Senders and Consumers are called Receivers. The senders and
receivers may exchange messages by means of a destination called a
Queue: senders produce messages to the Queue, and receivers consume
messages from the Queue.
[0072] Point-to-Point messaging may provide a number of features.
First, more than one Producer may be allowed to send messages to a
Queue. Such Producers can share a connection or use different
connections, even though they may all access the same Queue.
Second, more than one Receiver may be allowed to consume messages
from a Queue. However, in one embodiment, each message can only be
consumed by one Receiver. Thus Msg1, Msg2, and Msg3 will be
consumed by different Receivers. Third, Receivers can share a
connection or use different connections, but they may all access
the same Queue. Fourth, the sending and receiving of messages via
Point-to-Point messaging may be enabled with no timing
dependencies. Thus, a Receiver can fetch a message even if it was
running when the Client sent the message. Fifth, Senders and
Receivers may be added and deleted dynamically at runtime. This
feature may allow the integration gateway 12 to expand or contract
as needed. Sixth, messages may be placed on the Queue in the order
sent, but the order in which they are consumed may depend on
factors such as message expiration date, message priority, and
whether a selector is used in consuming messages.
[0073] The Point-to-Point domain may also offer certain advantages.
For example, the fact that multiple Receivers can consume messages
from the same Queue may allow effective load-balancing of message
consumption, as long as the order in which messages are received is
not important. As another example, messages destined for a Queue
may be retained, even if there are no Receivers. Finally, Clients
may be able to use a Queue browser object to inspect the contents
of a Queue. The Clients can then consume messages based on the
information gained from this inspection. That is, although the
consumption model is normally FIFO (first in, first out), in some
embodiments, Clients can consume messages that are not at the head
of the Queue if they know what messages they want based at least in
part on message selectors. Administrative Clients may also use the
Queue browser to monitor the contents of a Queue.
Publish/Subscribe Messaging
[0074] In the Publish/Subscribe domain, message Producers are
called Publishers, and message Consumers are called subscribers.
The Publishers and Subscribers may exchange messages by means of a
destination called a topic: Publishers produce messages to a topic,
and Subscribers subscribe to a topic and consume messages from a
topic.
[0075] The subscribers to these topics can be non-durable or
durable. The Broker may be configured to retain messages for all
active subscribers, but it may be configured to only retain
messages for inactive subscribers if these subscribers are
durable.
[0076] In the Publish/Subscribe domain, more than one Producer may
be allowed to publish messages to a topic. Such Producers can share
a connection or use different connections, but they may all access
the same topic. In some embodiments, more than one subscriber can
consume messages from a topic. The subscribers may retrieve all of
the messages published to a topic unless they use selectors to
filter out messages or the messages expire before they are
consumed. Subscribers can also share a connection or use different
connections, but they may all access the same topic. As described
above, durable subscribers can be active or inactive. However, even
when a durable subscriber is inactive, the Broker may be configured
to retain messages for them. Publishers and subscribers may be
added and deleted dynamically at runtime, thus allowing the
integration gateway 12 to expand or contract as needed. In one
embodiment, messages are published to a topic in the order sent,
but the order in which they are consumed depends on factors such as
message expiration date, message priority, and whether a selector
is used in consuming messages. Publication and subscription may
include a timing dependency. For example, a topic subscriber may be
able to consume only those messages published after it has created
the subscription.
[0077] In some embodiments, the Publish/Subscribe domain may allow
message to be broadcast to subscribers.
[0078] A session object may be used to create a Durable Subscriber
to a topic. The Broker may then retain messages for such
subscribers even when the subscriber becomes inactive.
[0079] In some embodiments, because the Broker must maintain the
state for the subscriber and resume delivery of messages when the
subscriber is reactivated, the Broker can identify a given
subscriber during its comings and goings. The subscriber's identity
may be constructed from a Client ID, a property of the connection
that created the subscriber, and a subscriber name specified at the
time of its creation. Other means of identifying the subscriber may
be used in different embodiments.
Communication Services Layer
[0080] The Communication Services Layer 208 may serve as the
primary layer responsible for inter-system communication. Message
integrity may be achieved with ACK/NAK messaging architecture,
while the Keepalive supports a real-time Request/Response message
protocol.
[0081] The Web services provided by the Communication Services
Layer 208 may enable communication among different products
produced by different companies.
[0082] For example, communication between a Third Party Debit
Ticket Kiosk system and ACSC for the Ticket number sequence may be
enabled. In such an embodiment, the Debit Ticket Kiosk may send out
messages using the S2S protocol to the integration gateway 12, and
the integration gateway 12 can then communicate with ASCS, obtain a
response and form an S2SMessage to send back to Debit Ticket
Kiosk.
[0083] The Web Services may use message processor plug-ins to
translate messages into the format required by the requested
system.
[0084] In one embodiment, the communication services layer 208 may
support the following protocols: Basic low-level Client/Server
TCP/IP sockets, Secure File Transfer Protocol (SFTP), HTTP/HTTPS,
SOAP (e.g. using Apache Axis2), .NET Remoting using IIOP ORB
protocol, RMI (EJB), and Database Stored Procedures. Of course, in
other embodiments, additional protocols, including proprietary
protocols, may be supported by the communication services layer
208.
Interceptor Services Layer
[0085] The Interceptor Services Layer 210 may serve as a
lightweight middleware object in the integration gateway 12 that
coexists with applications and/or systems (e.g., applications and
systems distributed by Bally Gaming) utilizing the integration
gateway services. This layer 210 may communicate with the local
application using simple Java programs, RMI, IIOP and/or database
stored procedures.
Programming Objects
[0086] In one embodiment, the objects used to implement messaging
by the integration gateway 12 may remain essentially the same
across programming domains. These objects may include--Connection
Factories, Connections, Sessions, Producers, Consumers, Messages,
and Destinations. Table 1, below, summarizes exemplary steps for
sending and receiving messages. Note that steps 1 through 6 are the
same for senders and receivers.
TABLE-US-00001 TABLE 1 Producing a Message Consuming a Message 1.
The administrator creates a connection factory administered object.
2. The administrator creates a physical destination and the
administered object that refers to it. 3. The client obtains a
connection factory object through a JNDI lookup. 4. The client
obtains a destination object through a JNDI lookup. 5. The client
creates a connection and sets any properties that are specific to
this connection. 6. The client creates a session and sets the
properties that govern messaging reliability. 7. The client creates
a message The client creates a message Producer. Consumer. 8. The
client creates a message. The client starts the connection. 9. The
client sends a message. The client receives a message.
[0087] The following sections describe objects that may be used by
Producers and Consumers, such as the Connections, Sessions,
Messages, and Destinations. A description of the production and
consumption of messages follows.
[0088] Connection Factories and Connections
[0089] In one embodiment, a Client uses an object (e.g., a
Connection Factory) to create a connection. The connection object
(i.e., Connection) represents a Client's active connection to the
Broker. It may use an underlying connection service that is either
started by default or explicitly started by the administrator for
this Client.
[0090] The allocation of communication resources and authentication
of the Client may take place when a connection is created. The
Connection may comprise a relatively heavyweight object, and
Clients may do all their messaging with just a single connection.
In some embodiments, Connections support concurrent use, i.e., any
number of Producers and Consumers can share a connection.
[0091] When a connection factory is created, the behavior of all
connections derived from it may be configured by setting the
properties of the connection factory. For example, for a Message
Queue, the following information may be specified: the name of the
host on which the Broker resides, the connection service desired,
and the port through which the Client can access the service; how
to handle automatic reconnection to the Broker if a connection
fails (This feature may reconnect the Client to the same Broker (or
to a different Broker) if a connection is lost. Data failover may
not be guaranteed as persistent messages and other state
information may be lost when reconnecting to a different Broker.);
the ID of Clients that need the Broker to track durable
subscriptions; the default name and the password of a user
attempting the connection (This information may be used to
authenticate the user and to authorize operations if a password is
not specified at connection time.); whether Broker acknowledgements
should be suppressed for those Clients who are not concerned with
reliability; how to manage the flow of control and payload messages
between the Broker and the Client runtime; and whether certain
message header fields should be overridden.
Sessions
[0092] If a connection represents a communication channel between a
Client and a Broker, a session may designate a single conversation
between the Client and Broker. The session object may be used to
create messages, message Producers, and message Consumers. When a
session is created, reliable delivery may be enabled through a
number of different acknowledgement options or through
transactions.
[0093] A session may comprise a single-threaded context for
producing and consuming messages. Multiple message Producers and
message Consumers may be created for a single session, but a
restriction may be instituted to use these message Producers and
message Consumers serially. A session object may also be used to do
the following: create and configure destinations for those Clients
that do not use administered objects to define destinations; create
and configure temporary topics and Queues (These topics and Queues
may be used as part of the request-reply pattern (discussed in
greater detail below).); support transaction processing; define a
serial order for producing or consuming messages; and/or serialize
the execution of message listeners for asynchronous Consumers.
Messages
[0094] In one embodiment, each message is composed of three parts:
a header, the header's properties, and a body.
[0095] The message header may be a requirement for every valid
message. The header may, inter alia, contain the following
exemplary fields, set forth in Table 2.
TABLE-US-00002 TABLE 2 Header Field Description Destination
Specifies the name of the destination object to which the message
is sent. (Set by the provider.) Expiration Specifies the time when
the message will expire. (Set by default by the provider or by the
client for a Producer or for an individual message.) Priority
Specifies the priority of the message within a range (e.g., 0-low
to 9-high). (Set by default by the provider or set explicitly by
the client for a Producer or for an individual message.) Timestamp
Specifies the time when the provider received the message. (Set by
the provider.) Type A value that can be evaluated by a message
selector. (Set by the client if needed.)
[0096] Another field that may be used is a Delivery Mode field,
which may determine the reliability of message delivery. This field
may indicate whether a given message is persistent.
[0097] The message body contains the data that Clients want to
exchange. The type of message may determine the contents of the
message body as well as how the message body should be processed by
the consumer. Some exemplary types are set forth in Table 3. The
Session object may include a create method for each type of message
body.
TABLE-US-00003 TABLE 3 Type Description Stream Message A message
with a stream of primitive values in its body. It is filled and
read sequentially. Map Message A message with a set of name-value
pairs in its body. The order of the entries is not defined. Text
Message A message with a string in its body, such as an XML
message. Object Message A message with a serialized Java object in
its body. Bytes Message A message with a stream of uninterrupted
bytes in its body. Message A message that contains a header and
properties but no body.
[0098] Java Clients may be configured to set a property so that the
Client runtime compresses the body of a message being sent. The
Message Queue runtime on the consumer side may then decompress the
message before delivering it.
[0099] Producing a Message
[0100] In one embodiment, messages may be sent or published by a
message Producer, within the context of a connection and/or
session. In one embodiment, a Client uses a message Producer object
(Message Producer) to send messages to a physical destination,
represented in the API as a destination object.
[0101] When a Message Producer is created, a default destination
may be specified to which all the Message Producer's messages will
be sent by default. Default values for the message header fields
that govern persistence, priority, and time-to-live may also be
specified. These default values may then be used by all messages
issued from that Producer unless they are over-ridden. In one
embodiment, these default values may be easily over-ridden, if, for
example, an alternate destination is specified when sending a
message, or if alternate values for the header fields are entered
for a message.
[0102] Consuming a Message
[0103] The messages produced above may be received by a message
consumer, within the context of a connection and/or session. In one
embodiment, the client uses a message consumer object (Message
Consumer) to receive messages from a specified physical
destination, represented in the API as a destination object.
[0104] In one embodiment, three factors may affect how the Broker
delivers messages to a consumer: (1) whether consumption is
synchronous or asynchronous; (2) whether a selector is used to
filter incoming messages; and (3) if messages are consumed from a
topic destination, whether the subscriber is durable.
[0105] Another factor that may affect message delivery and client
design is the degree of reliability needed for the consumer.
[0106] Exemplary Messaging Process Flow
[0107] Referring to FIG. 3, one exemplary messaging process is
illustrated. As illustrated therein, client A 300a and client B
300b are message Producers, sending messages 302a, b, c
(collectively 302) to client C 304c, client D 304d, client E 304e,
and client F 304f by way of two different kinds of
destinations.
[0108] Messaging between clients A, C, and D 300a, 304c, 304d
illustrates a Point-to-Point pattern. Using this pattern, client A
300a may send a message Msg1 302a or Msg 2 302b to a Queue
destination 306 from which only one of the Receivers 304c, 304d may
get it. In the illustrated embodiment, each message may be received
by only one receiver, and no other receiver accessing the Queue
destination 306 can get that message.
[0109] Messaging between clients B, E, and F 300b, 304e, 304f
illustrates a Publish/Subscribe pattern. Using this broadcast
pattern, client B 300b may send a message Msg3 302c to a Topic
destination 308 from which both consuming subscribers 304e, 304f
can retrieve it. Each subscriber 304e, 304f may obtain its own copy
of the message 302c.
[0110] Asynchronous/Synchronous Communication
[0111] Message Consumers in either the Point-to-Point or
Publish/Subscribe domains may choose to get messages synchronously
or asynchronously. Synchronous Consumers may be required to make an
explicit call to retrieve a message, while asynchronous Consumers
may specify a callback method that is invoked to pass a pending
message. In some embodiments, consumers can also filter out
messages by specifying selection criteria for incoming
messages.
[0112] Asynchronous communication can be defined as communication
where one party simply sends a message to another. Problems may
arise when the sending party expects a response to the message, or
when the timeframe during which a sending entity can remember that
it sent a message and that it expects a reply is short.
[0113] Synchronous communication can be defined as communication
where one party has a conversation with another. This may be
presented as a request-response scenario. An interface may be
defined between two Objects or Services where an invocation results
in a response once the requested processing has been completed.
Indeed, in some embodiments, even if there is no actual response, a
void response may be required.
Services
[0114] In one embodiment, the integration gateway 12 provides
support for the following protocol definitions, discussed in
greater detail below: Database Interface; DotNet Client; DotNet
Server; FTP Get; FTP Put; HTTP Get; HTTP Post; iSeries Data Queue
Writer; iSeries Data Queue Reader; Object Serializer; Object
Deserializer; RMI Client DotNet Server; RMI Server DotNet Client;
Socket Server; Socket Multiplexer; Socket Relay Client; Socket
Client; S2S Message Client; S2S Message Service; S2S Voucher End of
Day Report Service. These services and related protocols may
facilitate intersystem communication and message processing.
[0115] Database Interface
[0116] This protocol may be used to create a service that
communicates with a database by making a stored procedure call. The
service can take configurable parameters for connecting and
executing a stored procedure on a database. It can then pass an
entry to the host in alphanumeric form and then get a response too
in alphanumeric form.
[0117] Apart from the database connection parameters, the following
parameters may also be configurable: Source Event (the point on the
Queue where the service listens for incoming messages); and
Destination Event (the point on the Queue where the stored
procedure reply is written).
[0118] In one embodiment, the service created listens to an event
on a Queue associated with the integration gateway 12. When a
message arrives in the Queue, if configured, the service may then
process the message and pass it on to the stored procedure. If the
stored procedure returns a response, the response is then written
back to the Queue at an event configured as its destination.
[0119] All database connection parameters, such as Source Event and
Destination Event, may be configurable on a user interface of the
integration gateway 12 while creating a Database Interface
service.
[0120] DotNet Client and Server
[0121] In one embodiment, the DotNet protocols may use IOP
(Internet Inter-ORB Protocol) to communicate with a .NET Remoting
server and/or a .NET Remoting Client. .NET Remoting is a feature of
Microsoft's DotNet that provides RPC/RMI-like capabilities.
[0122] IOP is a protocol that enables distributed programs written
in different programming languages to communicate over the
Internet. IOP forms a part of the industry standard, Common Object
Request Broker Architecture (CORBA).
[0123] In one embodiment, the DotNet Client service listens to a
Queue associated with the integration gateway 12. When a message
arrives, the service may access a remote object on a DotNet system
(e.g., a .NET Remoting Server) by passing that message as a
parameter to the method on that object. In some embodiments, the
following parameters may be configured for the DotNet Client
service: Context Provider URL (the factory for ORB API), and Object
URI (the URI of the object exposed on the .NET Remoting
Server).
[0124] The DotNet Server service may allow a DotNet system (e.g., a
.NET Remoting Client) to access an object exposed via the
integration gateway 12, by passing a message as a parameter to the
method on this object. The DotNet Server service may then write to
a Queue associated with the integration gateway 12 on the
configured event. In some embodiments, the following parameters may
be configured for the DotNet Server service: Context Provider URL
(the factory for ORB API), and Object URI (the URI of the object
exposed on the integration gateway Server).
[0125] FTP Get & Put
[0126] The FTP Get Service may be used to poll a remote directory
periodically using the File Transmission Protocol (FTP). Once any
new and relevant file is found, the service can then download the
file and write the file object to a Queue associated with the
integration gateway 12. The Queue may be monitored by other
programs (e.g., by FTP Put), which may retrieve the file object
from the Queue.
[0127] The FTP Put Service may be used to listen to Message Events
of the Queue. Once a message is written to the Queue, the service
may check whether it is a file object. If so, the FTP Put service
may retrieve and upload the file to an FTP Server.
[0128] HTTP Get & Post
[0129] The HTTP Post service may send the data of a file in a local
file system to a configured http server. The HTTP Post request can
also send additional data to the host server, which may be
specified after the URL, the headers, and a blank line to indicate
the end of the headers.
[0130] The HTTP Get service may be used to download files from the
configured http Server to the local file system.
[0131] In some embodiments, these HTTP services may also provide
other processing options, e.g., by marking the downloaded/uploaded
files by deleting or renaming the files.
[0132] iSeries Data Queue Reader/iSeries Data Queue Writer
[0133] These services may be included to allow writes/reads to/from
iSeries Data Queues. The iSeries Data Queue Reader service may be
configured to read messages from an iSeries Data Queue and write
them to the Queue associated with the integration gateway 12. The
iSeries Data Queue Writer service may be configured to listen to
the Queue associated with the integration gateway 12, and, when a
message is received, write that message to an iSeries Data
Queue.
[0134] In some embodiments, a variety of iSeries Data Queue access
parameters may be configured on a user interface of the integration
gateway 12. For example, the iSeries Data Queue service may be
configured for the following: iSeriesDataQueueRx, and
iSeriesDataQueueTx.
[0135] RMI Server DotNet Client & RMI Client DotNet Server
[0136] These RMI-related protocols may enable a Java system and a
DotNet system to communicate using RPC based on IOP. The difference
between the RMI Server/Client DotNet protocols and other DotNet
protocols described herein is that these RMI protocols may be
designed so as not to include a Queue concept. Thus, these RMI
Server/Client DotNet protocols may be used for synchronous,
inter-system communication.
[0137] Object Serializer/Deserializer
[0138] Object Serialization is the process of saving an object's
state to a sequence of bytes, and may also be used to describe the
process of rebuilding those bytes into a live object at a later
point in time. In the integration gateway 12, the Object Serializer
service may allow all of the files in a selected directory (e.g., a
source directory) to get serialized and may then write the object
form of these files to the Queue associated with the integration
gateway 12.
[0139] The Object Deserializer service that resides on the Queue
may listen for Object messages and may deserialize them into files
in a configured path.
[0140] Socket-Based Services
[0141] Sockets are interfaces that can "plug into" each other over
a network, such as network 10. Once "plugged in", the programs or
software components so connected can communicate with each other. A
socket represents a single connection between exactly two pieces of
software. When more than two pieces of software communicate in
client/server or distributed systems (for example, many web
browsers simultaneously communicating with a single web server),
multiple sockets may be required. Socket-based software may execute
on two separate computers on the network 10; however, sockets can
also be used to communicate locally (i.e., inter-process) on a
single computer. Various socket-based services may be made
available on the network 10 via the integration gateway 10.
[0142] Sockets may be bi-directional, i.e., either side of the
connection is capable of sending and receiving data. The
application that initiates communication may be termed the client,
and the other application may be termed the server.
TCP/UDP
[0143] There are two types of Internet Protocol (IP) traffic,
described generally in Table 4. These two types of traffic may have
very different uses.
TABLE-US-00004 TABLE 4 Transmission Control Protocol (TCP) User
Datagram Protocol (UDP) TCP is a connection-oriented protocol, a A
simpler message-based connectionless connection can be made from
client to protocol. With UDP, you send messages server, and from
then on, any data can be (packets) across the network in chunks.
sent along that connection. Reliable - When a message is sent along
Unreliable - Message receipts are not a TCP socket, the message
will reach its guaranteed. The messages may or may destination
unless the connection fails not be transmitted. completely. If so,
the server will send a request for the lost portions of the file
again. Ordered - Messages are sent and listed in Not ordered -
Messages sent may not be the order in which they are sent. listed
in the order in which they are sent. Heavyweight - When the
low-level parts of Lightweight - There is no ordering of the TCP
"stream" arrive in the wrong messages, no tracking connections,
etc. It order, requests must be re-sent, and all of is often
quicker, and the network card/ the out of sequence parts must be
put operating system have little work to do in back together before
sending them. translating data back from the packets.
[0144] For socket-based protocols, the integration gateway 12 may
allow configuration of the type of the protocol, i.e., whether it
is TCP or UDP.
Socket Server
[0145] Once a socket server service is started, a server socket may
wait at the configured port for requests to come in over the
network 10. The socket server may then perform operations based on
those requests, and then possibly return results to the
requester.
[0146] In some embodiments, this protocol enables different socket
behaviors based on two configuration parameters: the parameter
`Listener`, and the parameter `Full Duplex`. The parameter
`Listener` is a Boolean parameter and may cause the socket to act
as a server. If set to true, the socket waits for requests, and
accepts connections. If set to false, the socket may connect to an
external server socket on the network 10.
[0147] The parameter `Full Duplex` is a Boolean parameter related
to two-way communication on the same line. When set to true, the
socket may behave in a two-way fashion. When the Full Duplex
parameter is configured to true, a `Full Duplex Event` value may
also be configured in order to identify the point where the service
listens to the Queue of the integration gateway 12 for incoming
messages. This value may be written to the socket. If the Full
Duplex parameter is set to false, the communication is one way.
That is, the socket listens at a port and writes the incoming
message to the Queue associated with the integration gateway 12 at
the specified point configured in `Request Event`.
[0148] The Full Duplex parameter may be used to define the type of
communication between the Queue and the Socket Server Service.
However, irrespective of the Full Duplex value, a socket may be
configured to send or receive data.
Socket Multiplexer
[0149] For the socket multiplexer service, the integration gateway
12 may enable configuration of the following parameters: port
number IP (IP address where the server socket will be opened);
multiplexer ports (a list of values, each value in the format of
`IPaddress: Port`; the assumption being that server sockets are
listening at all of these ports at the corresponding IP address);
and single pipe (when set to true, the conversation ends with a
single request/response scenario, the Client socket is closed, and
looped for the next Client connection).
[0150] The socket multiplexer service may be configured to open a
server socket at the specified IP address and port and listen for
incoming connections. When a Client connects, the incoming messages
may be routed to a list of server sockets (configured by the
parameter `multiplexer ports`) sequentially. The first message to
the first socket, the second message to the second socket, and so
on.
[0151] In some embodiments, this service will help with load
balancing in a high message traffic scenario.
Socket Relay Client
[0152] The socket relay client service may constitute two threads:
Receiver and Transmitter. These two threads may enable two-way
communication between a server socket and a regular socket. Each of
these threads may be configured to read from one socket and write
to another socket, which may help in controlling traffic between
the two sockets.
Socket Client
[0153] Socket client services may listen to the Queue of the
integration gateway 12. When a message is received, the socket
client service writes to the configured IP address and port number.
In some embodiments, a `Listener` value can be configured to obtain
Server Socket attributes. The period of delay in sending the
acknowledgment after sending the message may also be configured
using the parameter `ackWait`. If an acknowledgement is not
received within the scheduled time, the message may be re-sent.
[0154] All of the socket services discussed above may also include
other values that can be configured, such as: Start of Message
(SOM); End of Message (EOM); and/or Acknowledgment Message
(ACK).
[0155] S2S Protocol
[0156] The System to System (S2S) Messaging standard set by the
Gaming Standard Association provides a set of communication
protocols between gaming host systems (e.g., accounting, security,
progressive controllers, advertising, and promotion displays), as
well as between gaming and non-gaming host systems. This S2S
standard has emerged as a hospitality-gaming industry solution. The
current version of the S2S standard includes support for the
following types of gaming and non-gaming communications: patron
registration; player ratings (e.g., with respect to table games,
slots, bingo, keno, poker, sports book); table games accounting
(hourly estimates, open and closing, fills and credits, marker and
chip purchase vouchers support); comps (e.g., complimentary awards,
points, money, or hospitality products); system, data and device
configurations (such as defining active/inactive game types and
calculations, progressive controllers, chip sets, regional
settings, shifts, or codes for particular types of data, such as
club or badge identifiers).
S2S Message Service
[0157] The S2S Message Service on the integration gateway 12 may
comprise a web service that is exposed to Clients who want to
communicate using the S2S protocol. Both synchronous and
asynchronous versions of S2S may be supported. An interceptor value
may be configured based on the synchronous or asynchronous nature
required. An interceptor may function as an entry point to the
integration gateway 12 for the incoming messages over the network
10, and it may also handle the message processing tasks required
for requests and responses. This message processing may even
include translations performed for messages according to the target
system requirements. In one embodiment, the following interceptors
may be supported:
[0158] Asynchronous Interceptor: This interceptor may write
incoming messages to a socket, which in turn writes the message to
the Queue of the integration gateway 12. This interceptor may be
configured to achieve asynchronous S2S attributes.
[0159] Database Interceptor: This interceptor may make a stored
procedure call using the configured database connection parameters
and return a response.
[0160] Java Interceptor: This interceptor may make a Java RMI call
to a remote method for which the message is sent as a parameter, in
order to receive a response.
[0161] DotNet Interceptor: This interceptor may access an exposed
object on a .Net Remoting server to access a remote method by
passing the message as a parameter.
[0162] iSeries Interceptor: This interceptor may make a call to a
service program written on iSeries.
S2S Message Client
[0163] The S2S message client service may be configured to listen
to the Queue for S2S responses and then write these S2S responses
to a Web Service Client. The target URL may be configured as a
parameter in some embodiments.
S2S End of the Day Voucher Report Service
[0164] For Debit Ticket Kiosk functionality, a Client may generate
a request for a report that lists the ticket details for tickets
issued during the current day. A corresponding S2S message may
contain login details to the remote host and the required report
name. The integration gateway 12 can then perform S2S translations
to generate a flat string message for ACSC.
[0165] ACSC may then respond with the link of the server to the
integration gateway 12, which, in turn, may use FTP to download the
report from the identified server. The downloaded report may then
be translated to S2S format and returned to the Client.
Service Settings on GUI
[0166] The integration gateway 12 may allow the creation of
multiple groups and services based on the application and
requirements. In one embodiment, the groups may be logically named.
Groups and services may also be created within the groups. In one
embodiment, the same service may exist multiple times in the same
group; however, it may have to be renamed. The following actions
can be performed for each service: Start Service (used to start a
selected service); Stop Service (used to stop a selected service);
Configure Service; Save Service (used to save a service selected
after the configuration); and Delete Service (used to remove a
selected service).
[0167] The services may be configured in a variety of ways,
depending on the Identity, Message, Filter and Client within a
group. These settings may be common to all of the different
service/protocol settings.
[0168] Identity On The GUI
[0169] In one embodiment, an Identity tab displayed in the
graphical user interface ("GUI") of the integration gateway 12 may
be used to name and describe the services and their respective
characteristics. For example, the Identity tab may be used to
access the Log, Process, Persistence, Acknowledgement and
Transaction settings described below.
[0170] Log
[0171] The integration gateway 12 may provide a logging facility to
trace the run time of services. These logging facilities may log
information at various levels, such as the Engine, Service &
Message levels. For each service, the log level may be set
independently according to information requirements.
[0172] The following types of messages may be made available in the
Log files: All (all messages); Debug (messages generated during
debugging); Info (information messages, excluding Debug messages);
Warning (all warning messages excluding debug and information
messages); and Error (only error messages).
Process
[0173] The process configuration on the integration gateway 12 may
allow the runtime of each service to be independently controlled.
Using a Priority field, the priority for each service may be
defined. This priority setting may help in identifying those
service threads that should execute prior to other configured
service threads. The default priority for each service may be set
to five (i.e., the "normal priority"). One may be set to the
highest priority, and ten to the lowest priority. The service pause
time may also be defined via this process configuration.
Persistence
[0174] Persistence configuration may enable the definition of the
Request and Response Event names for the service. These names, in
turn, may determine the location of the respective message
destinations on the JMS Queue.
[0175] The Response event may be configured for a number of
services, such as: Database Interface; DotNet Client; DotNet
Interceptor; Database Interceptor; S2S Message Client; and/or S2S
Voucher End Of Day Report Service.
Acknowledgment Modes
[0176] An acknowledgment mode may also be configured to determine
the way a service handles the exchange of acknowledgment
information when receiving messages from the Queue associated with
the integration gateway 12. In one embodiment, the services may be
configured to have any of four possible acknowledgment modes:
[0177] Auto-Acknowledge: In Auto-Acknowledge mode, the client
runtime sends a Client acknowledgment instantly for each message it
delivers to the message consumer. The client runtime may then
block, waiting for a return Broker acknowledgment confirming that
the Broker has received the Client acknowledgment. This
acknowledgment "handshake" between the Client and the Broker may be
handled automatically by the Client runtime.
[0178] Client-Acknowledge: In Client-Acknowledge mode, the Client
application must explicitly acknowledge the receipt of all
messages. This enables the deferment of acknowledgment until after
the Client application has finished processing the message,
ensuring that the Broker will not delete it from persistent storage
before processing is complete.
[0179] Dups-OK-Acknowledge: In Dups-OK-Acknowledge mode, the
session automatically sends a Client acknowledgment each time it
has received a fixed number of messages, or when a fixed time
interval has elapsed since the last acknowledgment was sent. (This
fixed batch size and timeout interval may be set to 10 messages and
7 seconds, respectively, but may also be configured differently. In
one embodiment, however, the client may not itself configure the
batch size or timeout interval.) Unlike in the first two
acknowledgment modes described above, the Broker may not
acknowledge receipt of the Client acknowledgment, and the session
thread does not block awaiting such return acknowledgment from the
Broker. Thus, there may be no way to confirm that the Client
acknowledgment has been received, and, if that acknowledgment has
been lost in transmission, the Broker may redeliver the same
message more than once.
[0180] No-Acknowledge: In No-Acknowledge mode, the Client
application does not acknowledge receipt of messages nor does the
Broker expect any such acknowledgment. In this mode, there may be
no guarantee that any message sent by the Broker has been
successfully received. This mode thus sacrifices reliability for
maximum message traffic throughput.
Transactions
[0181] By enabling transactions, an entire series of incoming and
outgoing messages may be grouped together, such that they may be
treated as an atomic unit. The message Broker (e.g., the
integration gateway 12) may then track the state of the
transaction's individual messages, but may be configured to not
complete their delivery until the transaction as a whole is
committed. In the event of a failure, the transaction may be rolled
back, canceling all of the associated messages and restarting the
entire series from the beginning.
[0182] A transacted session may be defined to have exactly one open
transaction, encompassing all messages sent or received since the
session was created or the previous transaction completed.
Committing or rolling back a transaction ends that transaction and
automatically begins another.
[0183] Message Settings on GUI
[0184] In one embodiment, the Message settings associated with the
integration gateway 12 may allow the configuration of Data
transformational parameters.
Message Configurations
[0185] In one embodiment, the Message Processor Plug-ins for
Request and Response messages may be configured. Other message
settings may also be configured, such as: message type (e.g.,
string, xml, etc.). Messages may also be prioritized according to a
particular `type` field of the message. This prioritization may
help in filtering the messages that should be processed before
other messages. Message scheduling may also be used to define the
time for processing a given message. For more information on
possible configurations that may be made using the user interface
of the integration gateway 12, the User Guide for the Bally
Integration Gateway (p. 38 et seq.) may be consulted. This User
Guide provides some exemplary user interface examples and examples
regarding how one example integration gateway may be
implemented.
[0186] The above description of illustrated embodiments, including
what is described in the Abstract, is not intended to be exhaustive
or to limit the embodiments to the precise forms disclosed.
Although specific embodiments of and examples are described herein
for illustrative purposes, various equivalent modifications can be
made without departing from the spirit and scope of the disclosure,
as will be recognized by those skilled in the relevant art. The
various embodiments described above can be combined to provide
further embodiments. To the extent that they are not inconsistent
with the specific teachings and definitions herein U.S. patent
publication No. 2008/0162729A1; U.S. patent publication No.
2007/0082737A1; U.S. patent publication No. 2007/0006329A1; U.S.
patent publication No. 2007/0054740A1; U.S. patent publication No.
2007/01111791; U.S. provisional patent application Ser. No.
60/865,345, filed Nov. 10, 2006, entitled "COMPUTERIZED GAME
MANAGEMENT SYSTEM AND METHOD"; U.S. provisional patent application
Ser. No. 60/865,575, filed Nov. 13, 2006, entitled "COMPUTERIZED
GAME MANAGEMENT SYSTEM AND METHOD"; U.S. provisional patent
application Ser. No. 60/865,332, filed Nov. 10, 2006, entitled
"DOWNLOAD AND CONFIGURATION SERVER-BASED SYSTEM AND METHOD"; U.S.
provisional patent application Ser. No. 60/865,550, filed Nov. 13,
2006, entitled "DOWNLOAD AND CONFIGURATION SERVER-BASED SYSTEM AND
METHOD"; U.S. nonprovisional patent application Ser. No.
11/938,121, filed Nov. 9, 2007, entitled "GAMING SYSTEM DOWNLOAD
NETWORK ARCHITECTURE" (Atty. Docket. No. 110184.454); U.S.
nonprovisional patent application Ser. No. 11/938,228, filed Nov.
9, 2007, entitled "GAMING SYSTEM CONFIGURATION CHANGE REPORTING"
(Atty. Docket. No. 110184.45401); U.S. nonprovisional patent
application Ser. No. 11/938,155, filed Nov. 9, 2007, entitled
"REPORTING FUNCTION IN GAMING SYSTEM ENVIRONMENT" (Atty. Docket.
No. 110184.45402); U.S. nonprovisional patent application Ser. No.
11/938,190, filed Nov. 9, 2007, entitled "SECURE COMMUNICATIONS IN
GAMING SYSTEM" (Atty. Docket. No. 110184.45403); U.S.
nonprovisional patent application Ser. No. 11/938,163, filed Nov.
9, 2007, entitled "METHODS AND SYSTEMS FOR CONTROLLING ACCESS TO
RESOURCES IN A GAMING NETWORK" (Atty. Docket. No. 110184.45404);
U.S. nonprovisional patent application Ser. No. 11/938,150, filed
Nov. 9, 2007, entitled "NETWORKED GAMING ENVIRONMENT EMPLOYING
DIFFERENT CLASSES OF GAMING MACHINES" (Atty. Docket. No.
110184.453); U.S. nonprovisional patent application Ser. No.
11/938,231, filed Nov. 9, 2007, entitled "DOWNLOAD AND
CONFIGURATION SERVER-BASED SYSTEM AND METHOD WITH STRUCTURED DATA"
(Atty. Docket. No. 110184.449); U.S. nonprovisional patent
application Ser. No. 11/938,225, filed Nov. 9, 2007, entitled
"PACKAGE MANAGER SERVICE IN GAMING SYSTEM" (Atty. Docket. No.
110184.455); U.S. patent application Ser. No. 11/278,937, filed
Apr. 6, 2006, entitled "LOGIC INTERFACE ENGINE SYSTEM AND METHOD";
U.S. Provisional Patent Application Ser. No. 60/676,429, filed Apr.
28, 2005, entitled "LOGIC INTERFACE ENGINE SYSTEM AND METHOD"; U.S.
patent application Ser. No. 11/470,606, filed Sep. 6, 2006 entitled
"SYSTEM GAMING"; U.S. Provisional Patent Application Ser. No.
60/714,754, filed Sep. 7, 2005, entitled "SYSTEM GAMING APPARATUS
AND METHOD"; U.S. Provisional Patent Application No. 60/865,332,
filed Nov. 10, 2006, entitled "DOWNLOAD AND CONFIGURATION
SERVER-BASED SYSTEM AND METHOD"; and U.S. Provisional Patent
Application No. 60/865,396, filed Nov. 10, 2006, entitled "DOWNLOAD
AND CONFIGURATION CAPABLE GAMING MACHINE OPERATING SYSTEM, GAMING
MACHINE, AND METHOD" are incorporated herein by reference, in their
entirety. Aspects of the embodiments can be modified, if necessary,
to employ systems, circuits and concepts of the various patents,
applications and publications to provide yet further
embodiments.
[0187] For instance, the foregoing detailed description has set
forth various embodiments of the devices and/or processes via the
use of block diagrams, schematics, and examples. Insofar as such
block diagrams, schematics, and examples contain one or more
functions and/or operations, it will be understood by those skilled
in the art that each function and/or operation within such block
diagrams, flowcharts, or examples can be implemented, individually
and/or collectively, by a wide range of hardware, software,
firmware, or virtually any combination thereof. In one embodiment,
the present subject matter may be implemented via Application
Specific Integrated Circuits (ASICs). However, those skilled in the
art will recognize that the embodiments disclosed herein, in whole
or in part, can be equivalently implemented in standard integrated
circuits, as one or more computer programs running on one or more
computers (e.g., as one or more programs running on one or more
computer systems), as one or more programs running on one or more
controllers (e.g., microcontrollers) as one or more programs
running on one or more processors (e.g., microprocessors), as
firmware, or as virtually any combination thereof, and that
designing the circuitry and/or writing the code for the software
and or firmware would be well within the skill of one of ordinary
skill in the art in light of this disclosure.
[0188] In addition, those skilled in the art will appreciate that
the mechanisms of taught herein are capable of being distributed as
a program product in a variety of forms, and that an illustrative
embodiment applies equally regardless of the particular type of
signal bearing media used to actually carry out the distribution.
Examples of signal bearing media include, but are not limited to,
the following: recordable type media such as floppy disks, hard
disk drives, CD-ROMs, digital tape, and computer memory; and
transmission type media such as digital and analog communication
links using TDM or IP based communication links (e.g., packet
links).
[0189] The various embodiments described above can be combined to
provide further embodiments. To the extent that they are not
inconsistent with the specific teachings and definitions herein,
all of the U.S. patents, U.S. patent application publications, U.S.
patent applications, foreign patents, foreign patent applications
and non-patent publications referred to in this specification
and/or listed in the Application Data Sheetare incorporated herein
by reference, in their entirety. Aspects of the embodiments can be
modified, if necessary, to employ systems, circuits and concepts of
the various patents, applications and publications to provide yet
further embodiments.
[0190] These and other changes can be made to the embodiments in
light of the above-detailed description. In general, in the
following claims, the terms used should not be construed to limit
the claims to the specific embodiments disclosed in the
specification and the claims, but should be construed to include
all possible embodiments along with the full scope of equivalents
to which such claims are entitled. Accordingly, the claims are not
limited by the disclosure.
* * * * *