`
`
`
`\ |
`
`—— ee
`
`L = &\'/ 0) & r¢ BEEJETC
`‘ny,IPR2022-00368
`
`12,99
`
`6.55
`
`Zynga Ex. 1019, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Summary of Contents
`
`Introduction
`
`Chapter 1:
`
`Chapter 2:
`
`Chapter 3:
`
`Chapter 4:
`
`Chapter 5:
`
`Chapter 6:
`
`Chapter 7:
`
`Introduction to Java Networking
`
`Network Basics
`
`Network Application Models
`
`Web Basics
`
`Java I/O
`
`Threads
`
`Java Security Model
`
`Chapter8:
`
`Intennet Addressing and Naming,
`
`Chapter 9:
`
`TCP Programming
`
`Chapter 10:
`
`UDP Programming
`
`Chapter 11:
`
`Muilticasting
`
`Chapter 12:
`
`Java URL Handler Architecture
`
`Chapter 13:
`
`implementing an HTTP Server
`
`Chapter 14:
`
`Making Network Applications More Secure
`
`Chapter 15:
`
`Object Serialization
`
`Chapter 16:
`
`RMI
`
`Chapter 17:
`
`CORBA
`
`Chapter 18:
`
`Servlets
`
`Chapter 19:
`
`E-mail With JavaMail
`
`Chapter 20:
`
`Messaging with JMS
`
`Chapter 21:
`
`Networking in JDK 1.4
`
`Appendix A:
`
`Java Network Connectivity Exceptions
`
`Appendix Bi:
`
`nstalling and Configuring Tomcat 4.0
`
`index:
`
`E
`
`7
`
`7
`
`
`
`eiseebetkteeggssee
`
`=|=
`
`77?
`
`Zynga Ex. 1019,p. 2
`Zynga v.
`IPR2022-00368
`
`Zynga Ex. 1019, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Beginning Java Networking
`
`Chad Darby
`John Griffin
`Pascal de Haan
`Peter den Haan
`Alexander V. Konstantinou
`Sing Li
`Sean MacLean
`Glenn E. Mitchell
`Joel Peach
`Peter Wansch
`William Wright
`
`Wrox Press Lid. ®
`
`Zynga Ex. 1019, p. 3
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1019, p. 3
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Beginning Java Networking
`
`C 2001 Wrox Press
`
`All rights reserved. No part of this book may be reproduced, stored in a retrieval system or
`transmitted in any form or by any means, without the prior written permission of the publisher,
`except in the case of brief quotations embodied in critical articles or reviews.
`
`The author and publisher have made every effort in the preparation of this book to ensure the
`accuracy of the information. However, the information contained in this book is sold without
`warranty, either express or implied. Neither the authors, Wrox Press, nor its dealers or
`distributors will be held liable for any damages caused or alleged to be caused either directly or
`indirectly by this book.
`
`wrox
`Published by Wrox Press Ltd,
`Arden House, 1102 Warwick Road, Acocks Green,
`Birmingham, B27 6B1i. UK
`Printed in the United States
`ISBN 1861005601
`
`Zynga Ex. 1019, p. 4
`Zynga v. IGT
`IPR2022-00368
`
`

`

`20
`
`Messaging with JMS
`
`In any enterprise, many applications are used to support the business processes. Just as departments of
`enterprises need to communicate with each other to get their work done, different applications will need
`to communicate with each other to achieve the same. The communication between applications within
`one enterprise is sometimes called enterprise messaging. Other forms of communication between
`applications also exist, examples of these forms are:
`
`O Business to business: Here applications belonging to different enterprises interact
`
`O
`
`Inter-application: Here an application is a distributed solution with components (perhaps
`viewed as an application) on several different pieces of hardware
`
`Enterprise messaging applications exchange information using the concept of message passing. This
`means an application will inform another application it wants something done by sending a message to
`it. For example, a sales department would send a copy of an order to the finance department for it to
`send out a bill.
`
`This chapter explains the basics of using enterprise messaging with Java applications. It will cover the
`different techniques for enterprise messaging and make clear what the respective advantages and
`drawbacks are. At the end of the chapter, you will be able to implement enterprise messaging in your
`own applications.
`
`In particular, this chapter will cover:
`
`O Message oriented middleware
`
`O Hub and spoke architecture
`▪
`Java Messaging Service (JMS)
`
`Enterprise Messaging
`Before getting started on programming enterprise messaging applications, we must examine the basic
`models on which our applications will be built. The explanations will often refer to the scenario of the
`interaction between a sales application and a finance application. For instance. the sales application
`might send details of an order to a finance application so the customer can be billed. This finance
`application could then send a payment history back.
`
`Zynga Ex. 1019, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Chapter 20
`
`}
`
`Sales apt:ideation
`
`Order
`
` Payment
` History
`
`Finance application
`
`Enterprise messaging is the communication between different applications within the same company
`and there are many ways to achieve this communication.
`
`To get a more complete picture of the various methods we'll look at some of the common ones:
`
`q Raw network
`
`•
`
`Remote procedure calls (RPC)
`
`3 Electronic Mail
`• Message Oriented Middleware (MOM)
`
`1
`
`t
`
`Raw Network Communication
`The use of raw network communication techniques, such as named pipes or TCP/IP sockets, form the
`basis for all the other techniques. Achieving communications between applications using this low-level
`technique is the most time-consuming for a programmer to accomplish. As a programmer you spend a
`lot of time dealing with adverse network conditions and how best to cope with such situations on top of
`processing the messages. Some examples of the problems you have to solve include the temporary loss
`of a connection, requiring you to reconnect and the encoding of your information into a byte format
`that is understood at the destination. The received information also needs to be transformed from an
`array of bytes to a convenient programming object like a string or integer. The main advantage of using
`raw network communication techniques is the potential of high data throughput. An example of this is a
`live streaming application that needs continuous video feeds.
`
`Remote Procedure Calls
`To make it easier for programmers to invoke methods in other applications, remote procedures calls
`were devised (see Chapter 16 for more details on doing RPC calls with Java by using Remote Method
`Invocation. RMI). This communication technique deals with the data encoding issues and most network
`communication aspects, like opening a TCP/IP port. Remote procedure calls (RPC) make it easy to
`invoke a specific piece of logic within another application. The logic in the remote application must be
`exposed as a method suitable for invocation through RPC.
`
`Although RPC is a powerful method for network programming, it does have some important
`disadvantages. Applications communicating with one another using RPC need to be running at the same
`time. Upgrades and configuration changes that require an application to be temporarily offline may
`result in errors in the other application. Maintenance should thus be planned at the same time or the
`logic that uses RPC will have to be intelligent enough to retry the invocation later.
`
`Applications that use RPC must run at a similar speed if overall performance is to be guaranteed, as
`each component should be able to handle requests at a comparable rate. Going back to our example,
`you will see that the finance application should be able to process orders just as fast as the sales
`application, othenvise the sales application is slowed down in its order intake.
`690
`
`a,
`
`Zynga Ex. 1019, p. 6
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Messaging with JMS
`
`Electronic Mail
`To allow applications to run at a different speed one could make use of mail. Mail is an asynchronous
`way of exchanging messages - if the sales application mailed the order to the finance application then it
`can continue processing new orders, while the finance application can take its time processing the order,
`so you will not be billed so fast.
`
`Mail abstracts raw network aspects from the programmer and it has several ways to encode information
`with the use of MIME or XML messages, however it has a big disadvantage in that it is not reliable. The
`chance of a mail message being lost, certainly within the same enterprise, can be very small but it is a
`possibility. If the sales department processes an order and the items are shipped, you will want the
`absolute guarantee that the finance department will bill that customer.
`
`Also, keep in mind that electronic mail (e•mail) is a method of communication between people, or
`between software applications and people. However, it is not ideally suited for communication between
`software applications or software components. Although programs shuffle the data from place to place,
`the actual writing of the message and more importantly the interpretation of a received message is done
`by a human. E-mail has no means for helping applications interpret the received message or invoke a
`new action within that application.
`
`Message Oriented Middleware
`The communication techniques provided by message oriented middleware (MOM) deal with all the
`issues described earlier. MOM allows for reliable message exchange between applications. It also
`abstracts all network problems from the application programmer. Message-exchange can be achieved
`asynchronously and synchronously. In most cases, MOM implementations support multiple message
`formats and provide tools to encode and decode information within a message.
`
`All this additional functionality can affect performance and this form of intracompany communication is
`not always the best solution. If an application needs to stream data continuously to another application,
`the use of raw network communication techniques will be a wiser choice.
`
`Message oriented middleware is software that connects otherwise separate applications through the
`passing of messages. The software creates an infrastructure that insulates the application developer from
`the details of the various operating systems and network interfaces.
`
`Message oriented middleware has several key concepts:
`
`3 Clients
`
`q Message agents
`
`3 Destinations
`
`Messages
`
`The messaging system is often a peer-to-peer facility. This means that a messaging client can send
`messages to, and receive messages from, any other messaging client. There is no central server that
`distributes the messages, as with e-mail.
`
`A messaging agent provides facilities for creating. sending, and receiving messages. Each client connects
`to its own messaging agent to make use of these facilities. The messaging agent will see to it that a
`message is delivered to the requested destination or other client.
`
`691
`
`Zynga Ex. 1019, p. 7
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Chapter 20
`
`Messages are not sent to applications or message agents directly, but to an abstract location called a
`destination, this is a unique address within the message oriented middleware software. A messaging
`agent is needed to send messages to. or read messages delivered to a specific destination. A destination
`can point to a location on the same machine or anywhere on the network.
`
`Illustrated in the diagram above is the structure of the sales/finance application we discussed in the last
`section if it was implemented using message oriented middleware.
`
`A message can be separated into roughly two parts. One part, referred to as the message header,
`contains information intended only for the message agent. The other part, referred to as the
`message body or payload, holds information intended for the target-application or message
`receiving application.
`
`The message header instructs the messaging agent on where to deliver the message and how it should
`be transported. The header also contains other instructions, like indications about the desired assurances
`or the number of times a delivery was attempted. Other information describes the return address (also a
`destination) to which the target-application should send its response (if any).
`
`The message body is mostly left untouched by the MOM software. However, transformations are
`made on the information intended for the target application if the platform on which the application
`runs, requires such transformations. The transformation should only involve changes in byte ordering
`when crossing big endian and little endian boundaries or when the character encoding differs (like
`ASCII or Unicode).
`
`Transformation of a message body does not occur when using the Java APL
`Regardless of operating system or hardware platform, Java always uses the same byte
`iirdering (big endian) and character encoding (Unicode).
`
`Hub and Spoke Architecture
`Creating applications that use enterprise messaging requires a design that spans across the several
`applications communicating with each other. This overall design is often referred to as system
`architecture.
`
`As you let more and more applications communicate with enterprise messaging, your
`architecture can slowly grow to be a mesh of one-to-one connections between applications. The
`figure below shows such a mesh between applications. Each arrow indicates a set of destinations
`known to each application.
`
`692
`
`Zynga Ex. 1019, p. 8
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Messaging with JMS
`
`Each enterprise messaging application may need to create a connection for each application within your
`company. When a new application is created, every existing application that requires interaction with
`this new application, needs to be modified. Several solution strategies for dealing with this mesh of
`connections may immediately pop into your mind. You might think of creating additional end-points to
`prepare your application for possible future expansion. However, this leads to unnecessary message
`sending when no expansion is created. The strategy is also useless after all the end-points have been
`used up.
`
`One of the solutions to this problem is the hub and spoke architecture. This architecture defines a
`central application, called a message broker or message server, to be the destination of all applications.
`It is the responsibility of the message broker to route messages to the correct target application based on
`information within the message. The message broker is not part of the message oriented middleware
`software, but a separate application, so the argument mentioned earlier stating that message oriented
`middleware does not have a central server still holds, however the use of the hub and spoke architecture
`does introduce such an application.
`
`Message brokers differ in level of complexity. Simple ones are only capable of forwarding messages,
`more advanced ones have the additional capability of transforming the message content from one
`format to another format by rearranging them or adding information. The most complex message
`brokers offer administrative capabilities, like logging, and they can perform alternative transformations
`or forwarding if error conditions occur. Some can even be configured to expect a level of service from
`an application, meaning that if an application doesn't respond to a send message within a certain
`timeframe or with a specific message (format), the message broker can take alternative actions. These
`could include resending the message or contacting an administrator. Any new application added to the
`enterprise messaging system will only require changes in the message broker.
`
`When you look at the architecture you can make an analogy with a hub (message broker) and spokes
`(applications) of a wheel. The next figure illustrates this architecture. As you can see this is a simpler
`architecture. For instance, adding a new module doesn't require changes to the other modules. Nor
`do the individual modules now have to know where the others are or how to communicate with them.
`
`693
`
`Zynga Ex. 1019, p. 9
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Chapter 20
`
`7
`
`There is an easy way to use the hub and spoke architecture without having to buy or create a message
`broker application. You can use the publish and subscribe domain of Java Messaging Service UMS).
`Note that Java Messaging Service UMS) implementations are not free. The one provided with Java 2
`Platform, Enterprise Edition PEE) reference implementation is not suitable for production use. If you
`do have another J2EE implementation, which is supplied with most application servers, you can use the
`publish and subscribe domain. Also, note that most message broker applications cost several times the
`cost of an application server.
`
`The Java Message Service (JMS)
`The first part of this chapter gave you the run-down on what enterprise messaging is, what
`technologies you can use and some of the architectures that are possible. The remaining sections will
`guide you through programming enterprise messaging applications with the use of the Java
`Messaging Service (JMS). Two examples will be used to demonstrate program applications or
`software components that can communicate with each other via messages. But before we get to that
`we must examine the JMS in detail.
`
`The Java Message Service is a Java API that allows applications to create, send, receive, and read
`messages. The API defines a common set of interfaces and associated semantics that allow programs
`written in the Java programming language to communicate with message oriented middleware.
`
`Java Messaging Service UMS) applications are capable of communicating with heterogeneous
`applications that are written in other programming languages, run on other operating systems or
`machine architectures. This is because messages, created with the JMS API, can match most formats
`used by existing, nonJMS applications. The non Java and non JMS application will need to access their
`messages through means provided by the Java Messaging Service UMS) vendor-implementations.
`Examples of these are proprietary APIs or other standards like the CORBA Messaging Service from the
`Object Management Group (OMG).
`
`The use of the JMS API in your programs will give them the flexibility to switch between messaging
`implementations. This is similar to the way the use of the JDBC API makes your programs flexible in
`switching between database management systems. This portability is only valid if your applications use
`only JMS and not the vendor-specific API for communications with MOM.
`
`694
`
`Zynga Ex. 1019, p. 10
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Messaging with JMS
`
`The advent of Java Messaging Service also brought about a consensus on what components are used in
`messaging. One messaging system would require the use of a separate configuration-component, while
`another incorporated the configuration options within methods of the message client directly.
`Previously, conceptually similar components would also be called something different across messaging
`systems. With the creation of the unified API for various messaging strategies, JMS minimized the set of
`components that a Java language programmer must learn to create enterprise messaging products.
`
`The behavior of messaging systems is different. Some systems provide only facilities for delivering
`messages to a client as they arrive (push model), while others only support means for clients to
`actively request messages (pull model). The semantic specifications within JMS remove these
`differences, by describing completely how and when messages arrive at clients. Semantics are also
`defined at a low level with various rules, for instance on how and when the properties of a message
`header are (can be) set. At the high level the specifications divide the behavior of key components
`within the two messaging domains.
`
`Messaging Domains in JMS
`Java Messaging Service (JMS) describes the many difference in messaging systems with just two
`messaging domains.
`
`Point-to-Point
`
`q Publish and Subscribe
`
`The point-to-point domain has a lot of similarity to the postal service; addresses are predefined and
`messages sent to a specific address are mostly intended for one person. This domain uses message
`queues instead of postal addresses as destinations. Each message is addressed to a specific queue; clients
`extract messages from the queue(s) established to hold their messages. Similar to postal addresses, you
`will find that queues are generally predefined, so they are known at design time. Just as with a queue at
`the checkout in the supermarket, the first to arrive will be helped (delivered) first.
`
`The publish and subscribe (or Pub/Sub) domain is built around the idea of a content hierarchy. It lets
`clients, called publishers, send messages to a node located somewhere within a content hierarchy.
`Subscribers are clients that subscribe to a node in the content hierarchy in order to receive messages,
`published to this particular node. The system takes care of distributing messages arriving from a node's
`multiple publishers to its multiple subscribers. Publishers and subscribers are generally anonymous and
`may dynamically publish or subscribe to a content hierarchy. Messages intended for several clients or
`messages intended for unknown clients are best sent using the publish and subscribe domain of Java
`Messaging Service UMS).
`
`The JMS Specification defines rules for compliance for each domain. A standalone JMS provider may
`implement one or both domains. A Java 2 Platform, Enterprise Edition (J2EE) provider must implement
`both domains. Most current implementations of the JMS API provide support for both the point-to-
`point and publish/subscribe domains. JMS clients are allowed to combine the use of both domains in a
`single application.
`
`Application Architecture
`Previous we defined the key components of a MOM-based messaging service: clients, message agents,
`destinations, and messages. Java Messaging Service (JMS) refines these key components and adds a few more.
`
`695
`
`Zynga Ex. 1019, p. 11
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Chapter 20
`
`JMS calls a messaging system that implements the interfaces and provides administration and control
`features, a JMS Provider. Message clients are separated into the JMS clients and non:JMS clients
`categories. JMS clients are programs or components written in the Java programming language and that
`send and receive messages by using the JMS API. All other programs, regardless of their programming
`language, are considered non JMS clients. Communication between clients of both categories is
`possible; the JMS Provider is tasked to solve this problem. JMS introduces another key component,
`called administered objects; these are preconfigured JMS objects such as destinations or connection
`factories. They are created and configured by an administrator for use by client applications. Later on,
`the benefits and such of administered objects will be explained further.
`
`Java Messaging Service calls clients that send messages message producers and clients that receive
`messages message consumers. Depending on the message domain used within your program the JMS API
`refers to message producers, message consumers and destinations differently. The table below supplies an
`overview of the way JMS refers to key components of MOM within a particular messaging domain.
`
`JMS
`
`Destination
`
`Point to point domain
`
`Pub/Sub domain
`
`Queue
`
`Topic
`
`Message producer
`
`QueueSender
`
`TopicPublisher
`
`Message consumer
`
`QueueReceiver
`
`TopicSubscriber
`
`What's Not in JMS
`At this point, the Java Messaging Service (JMS) might seem the ideal solution for all your enterprise
`application needs; however, JMS does not completely cover every aspect of large distributed
`intracompany communications software.
`
`The specification does not address the following functionality:
`
`• Wire protocol: Vendors are allowed to implement JMS with no restrictions made on the wire
`protocol (network communication protocol) used. A message sent from one vendor does not
`need to be interpretable by another vendor simply by reading the network message. The
`exchange between different implementations is only required at the API level, using code.
`
`q Administration: Administered objects are a core piece of Java Messaging Service (JMS). The
`storage and removal of these objects are done through the Java Naming and Directory
`Interface (JNDI). Apart from storage of Java objects, administration also involves other
`activities like the configuration of wire protocol resources (IP numbers, sockets etc.).
`O Security: JMS is part of the Java 2 Platform, Enterprise Edition (J2EE) so most security aspects
`(such as login) are delegated to other parts of the platform. Controlling privacy and integrity of
`messages or the way digital signatures or keys should be used or distributed among clients are
`not specified within JMS. JMS considers security to be a JMS provider-specific feature that is
`configured by an administrator. Clients should not control security aspects through the JMS API.
`Resilience: Enterprise messaging applications usually need a high level of service. This means
`high availability and reliability, preferably achieved by using load balancing and fault
`tolerance capabilities of the messaging product. A popular way to support these capabilities in
`a messaging product involves combining multiple, cooperating clients into one critical service.
`How such clients work together to be a single, unified service is not defined in the JMS
`specification - this is left to providers to realize.
`
`•
`
`696
`
`Zynga Ex. 1019, p. 12
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Messaging with JMS
`
`Choosing a resilience level can be achieved in a variety of ways, more hardware (RAM or
`processors), making use of OS features (duplicate processes), or software capabilities, such as
`clustering. When solving a resilience 'problem', any of these solutions might be the right one,
`taking into account budget, current environment, company standards, business ambitions,
`available time, experience etc. Considering all these options means that choosing a JMS
`provider is not an easy task.
`O Error/Advisory Notification: Clients receive messages asynchronously from most MOM
`products informing them of problems or system events. A standard for system messages or
`notifications does not exist in the JMS specification. Conformance to the guidelines defined by
`JMS will prevent clients from using these messages. Good JMS clients are not allowed to
`depend on any system messages. Any portability problems introduced by the use of or the
`dependency on error/ advisory notifications through messages is thus prevented by
`conformance to the Java Messaging Service (JMS) specification.
`
`O
`
`Triggering: The arrival of a message or the signaling of a problem (like no more room for
`messages) will likely need a particular client to be running, and there's no guarantee that it
`will be. Some JMS providers support such triggering mechanism through their own
`administrative facilities; JMS however does not provide a mechanism for triggering the
`execution of a client.
`
`3 Persistent message storage: Messages sent through an enterprise messaging system will
`conform to a certain type definition. The type definition describes for instance the fields
`present in a message and in what sequence they can be found. These type definitions may be
`stored within a repository by messaging products. There are no means to define type
`definitions or store them in repositories using the JMS API.
`
`The list of functionalities that are not a part of the Java Messaging Service (JMS) specification may seem
`a long one. Not having these functionalities however does not mean that the specification of JMS is
`incomplete. In fact, JMS describes only those things that directly relate to messaging. Because the focus
`lies on just the kind of producers, consumers, message formats, associated behavior and so on,
`implementing and using JMS only requires knowledge of messaging. This results in a low learning curve
`for using Java Messaging Service (JMS).
`
`Also, bear in mind that JMS is part of the Java 2 Platform, Enterprise Edition (J2EE). The other
`functionalities mentioned above, are most likely a required part of an enterprise messaging application.
`The J2EE contains the necessary standards for most of these functionalities. Mentioning them in the
`Java Messaging Service (JMS) specification would mean that this specification would redefine standards
`that are already implemented elsewhere.
`
`Anatomy of JMS Messages
`Before delving into the depths of the Java Messaging Service VMS) API, this section focuses on the
`fundamental part of any messaging service: the messages. You have read about enterprise messaging,
`message oriented middleware and had an introduction to the Java Messaging Service (JMS). This section
`discusses mainly the anatomy of messages within the context of the JMS specification.
`
`\Then discussing message exchange between applications, the JMS specification defines its own terms -
`consume and produce.
`
`697
`
`Zynga Ex. 1019, p. 13
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Chapter 20
`
`a The term consume is defined as the receipt of a message by a JMS client. This in turn means
`that a JMS provider has received a message through the MOM and has given the message to
`the client. The specification makes no difference in the term consume, even though it does
`distinguish between asynchronous and synchronous receipt of messages.
`The term produce means the sending of a message in the most general sense, without regard
`to the way the message is distributed among destinations by the messaging system. In
`conclusion, produce stands for the giving of a message to aJMS provider with the intent that
`the provider should deliver it to one or more destinations that then consume this message.
`
`Properties
`In a previously, messages were described as consisting of a header and a body: the header contains
`instructions intended for MOM; the body contains the information intended for the target
`application(s). The JMS specification adds another part to a message called properties. The properties
`section defines addition of optional fields that can be added to the message header. The order in which
`property values are stored, is not defined.
`
`The value of a property can be any primitive Java language type (boolean, byte, short, int, long,
`float, double) or of type java lang . String. The JMS specification supports automatic
`transformations between property values. The transformations occur when using the typed property
`retrieval methods, which follow the pattern get<Type> Proper ty ( ). If a conversion cannot be
`performed. a MessageFormatException will be thrown. In cases of String to numeric conversion
`problems a NumberFormat Except ion will be thrown.
`
`Properties are divided into three categories:
`
`U Standard: These properties are non-mandatory attributes of any JMS message, but have a
`standardized name and meaning
`Provider specific: These properties are mainly intended for providers to send additional
`information with messages, helping them process the messages correctly to non-JMS clients
`Application specific: These are used by the sending and receiving applications to help with
`their message processing
`
`Java Messaging Service (JMS) specifies several standard properties that are not mandatory. The optional
`header fields have property names that are prefixed by the text ' JMSX '
`
`The following table shows most of the standard properties in aJMS message, who sets their value and
`what they are used for.
`
`Name
`
`JMSXUserID
`
`SMSKApp ID
`
`Set by
`
`Provider just before a message is
`produced
`
`Use
`Identifies the user of the
`sending application
`
`Provider just before a message is
`produced
`
`Identifies the sending
`application
`
`698
`
`Zynga Ex. 1019, p. 14
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Messaging with JMS
`
`Name
`
`Set by
`
`Use
`
`JMSXDeliveryCount
`
`Provider just before a message is
`consumed
`
`The number of attempts made
`to deliver the message (starts
`with 1)
`
`JMSXRcvTimestamp
`
`Provider just before a message is
`consumed
`
`The time the message is
`delivered to the consumer
`
`JMSXGrouplD
`
`JMSXGroupSeq
`
`Client
`
`Client
`
`The identity of message group
`
`Indicates the sequence
`number of the message in a
`message group (starts with 1)
`
`The value for JMSXRcvTimes tamp is set by the provider just before consumption of the message by
`the consumer. The provider is part of the JMS implementation and should not be confused with the
`producer or sending application of the message.
`
`The names of provider-specific properties are prefixed with the text "JMS_<vendor_name>", the
`values and the types stored under these names are determined by the vendors of messaging software.
`Provider-specific properties can be used to store information needed to support JMS with provider-
`native clients. They are not intended to help coordinate JMS-to-JMS messaging.
`
`T