U.S. patent application number 13/942275 was filed with the patent office on 2013-11-14 for system and method for message sequencing in a broadband gateway.
This patent application is currently assigned to VERIZON DATA SERVICES, INC.. The applicant listed for this patent is Sameer N. Dharmadhikari, Shiv Nayak KOLAKERI, Abhitabh Kushwaha. Invention is credited to Sameer N. Dharmadhikari, Shiv Nayak KOLAKERI, Abhitabh Kushwaha.
Application Number | 20130301644 13/942275 |
Document ID | / |
Family ID | 40471500 |
Filed Date | 2013-11-14 |
United States Patent
Application |
20130301644 |
Kind Code |
A1 |
KOLAKERI; Shiv Nayak ; et
al. |
November 14, 2013 |
System and Method for Message Sequencing in a Broadband Gateway
Abstract
A system and method for message sequencing in a broadband
gateway comprising a receiver to receive two or more messages, a
data storage system to store the two or more messages, an
identifier to identify a processing sequence for the two or more
messages, and a retriever to retrieve the two or more messages for
processing based on the identified processing sequence for
providing broadband DSL service to a customer.
Inventors: |
KOLAKERI; Shiv Nayak;
(Tampa, FL) ; Kushwaha; Abhitabh; (Tampa, FL)
; Dharmadhikari; Sameer N.; (Wesley Chapel, FL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
KOLAKERI; Shiv Nayak
Kushwaha; Abhitabh
Dharmadhikari; Sameer N. |
Tampa
Tampa
Wesley Chapel |
FL
FL
FL |
US
US
US |
|
|
Assignee: |
VERIZON DATA SERVICES, INC.
TEMPLE TERRACE
FL
|
Family ID: |
40471500 |
Appl. No.: |
13/942275 |
Filed: |
July 15, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11862123 |
Sep 26, 2007 |
8488448 |
|
|
13942275 |
|
|
|
|
Current U.S.
Class: |
370/394 |
Current CPC
Class: |
H04L 47/34 20130101;
H04L 12/66 20130101 |
Class at
Publication: |
370/394 |
International
Class: |
H04L 12/801 20060101
H04L012/801 |
Claims
1-20. (canceled)
21. A method, comprising: receiving two or more messages at a
receiver of a gateway; storing the received messages in one or more
databases; identifying a processing sequence for the stored
messages by at least creating an entry in a sequence table for each
of the stored messages, each entry comprising one or more keys; and
retrieving the stored messages for processing without database
polling based on the identified processing sequence.
22. The method of claim 21, further comprising: classifying each of
the retrieved messages as one of one or more message types; and
routing, using the classifications, the retrieved messages for
further processing at one or more external systems.
23. The method of claim 22, wherein each of the retrieved messages
are routed based on one or more rules, wherein each of the one or
more rules is mapped to a message type in a mapping table.
24. The method of claim 21, further comprising: routing the
retrieved messages for further processing at one or more external
systems; and transforming the retrieved messages based on the
identified processing sequence.
25. The method of claim 24, further comprising: identifying a
message format and content associated with each of the retrieved
messages; and preventing duplicate transformation based on whether
at least one of the message format or content for at least two of
the retrieved messages is the same.
26. The method of claim 21, wherein each of the one or more keys in
each of the two or more entries in the sequence table comprises at
least one of a time of receipt, a time of delivery, a sending
source, a transaction type, or a sequence number associated with
the message corresponding to the entry.
27. The method of claim 26, wherein identifying a processing
sequence for the stored messages is further based on the one or
more keys in the sequence table associated with each of the stored
messages.
28. The method of claim 24, wherein the transformer utilizes
application server clustering.
29. A computer readable media comprising code to perform the acts
of the method of claim 21.
30. A system, comprising: at least one receiver to receive two or
more messages; at least one data storage system to store the
received messages; at least one identifier to identify a processing
sequence for the stored messages, wherein identifying the
processing sequence for the stored messages comprises creating an
entry in a sequence table for each of the stored messages, each
entry comprising one or more keys; and at least one retriever to
retrieve the stored messages for processing without database
polling based on the identified processing sequence.
31. The system of claim 30, further comprising a router to route
each of the retrieved messages for further processing at one or
more external systems.
32. The system of claim 31, wherein the router classifies each of
the retrieved messages as one of one or more message types and uses
the classifications when routing the retrieved messages for further
processing at the one or more external systems.
33. The system of claim 32, wherein the router routes each of the
retrieved messages based on at least one of the message types
associated with the message and one or more rules, wherein each of
the one or more rules is mapped to a message type in a mapping
table.
34. The system of claim 31, further comprising a transformer for
transforming the retrieved messages in sequence, wherein the each
of the retrieved messages are transformed based on the identified
processing sequence.
35. The system of claim 34, wherein the transformer is further
configured to: identify a message format and content associated
with each of the stored messages; and prevent duplicate
transformation based on whether at least one of the message format
and content for at least two of the stored messages is the
same.
36. The system of claim 30, wherein each of the one or more keys in
each of the entries in the sequence table comprises at least one of
a time of receipt, a time of delivery, a sending source, a
transaction type, or a sequence number associated with the message
corresponding to the entry.
37. The system of claim 36, wherein the identifier further
identifies a processing sequence for the stored messages based on
the one or more keys in the sequence table associated with each of
the stored messages.
38. The system of claim 34, wherein the transformer utilizes
application server clustering
Description
BACKGROUND INFORMATION
[0001] Demand for in-home data and telephony services has grown
dramatically in recent years and is expected to continue to
increase. Accordingly, providers of data and telephony services
have sought to design and deploy broadband networks with increased
delivery capacity. One broadband technology that has become
particularly popular, for example, is digital subscriber lines
(DSL). As demand for DSL service has grown, service providers have
needed to build out infrastructure for providing DSL service. One
aspect of DSL network maintenance that has proven particularly
cumbersome is provisioning of DSL services. Generally, in order to
provide service to a customer, numerous network elements need to be
configured to create a communication path, which may be referred to
as a permanent virtual circuit (PVC), from the customer through the
DSL network to an Internet service provider (ISP) or network
service provider (NSP). Processing an order for DSL service and
configuring the network elements to create the PVC is often
referred to as "provisioning." However, delays and failures
associated with provisioning are often experienced because the
process involves numerous computerized systems, configuring many
network elements to establish a PVC from the end user to an
asynchronous transfer mode (ATM) or internet protocol (IP) network,
and configuring still more network elements to complete the PVC
through an ATM/IP network to an ISP/NSP. Therefore, quickly
identifying points of failure in processing an order is essential
for efficient operation of a DSL network and to meet customer
expectations. The fact that such transactions are becoming
increasingly high in volume and are often processed by multiple
network components further complicates the provisioning process. As
a result, current broadband provisioning and activation techniques
are hard-pressed to efficiently manage all inbound and outbound
communications to ensure delivery of messages in sequence.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] In order to facilitate a fuller understanding of the
exemplary embodiments, reference is now made to the appended
drawings. These drawings should not be construed as limiting, but
are intended to be exemplary only.
[0003] FIG. 1 depicts a broadband gateway architecture for message
processing, according to an exemplary embodiment;
[0004] FIG. 2 depicts an architecture of receiving messages in a
broadband gateway, according to an exemplary embodiment;
[0005] FIG. 3 depicts a flowchart of parsing messages in a
broadband gateway, according to an exemplary embodiment;
[0006] FIG. 4 depicts a flowchart of sequencing messages in a
broadband gateway, according to an exemplary embodiment;
[0007] FIG. 5 depicts a flowchart of routing messages in a
broadband gateway, according to an exemplary embodiment;
[0008] FIG. 6 depicts a flowchart of transforming messages in a
broadband gateway, according to an exemplary embodiment;
[0009] FIG. 7 depicts a flowchart of dispatching messages in a
broadband gateway, according to an exemplary embodiment;
[0010] FIG. 8 depicts a flowchart of a broadband gateway, according
to an exemplary embodiment;
[0011] FIG. 9 depicts a flowchart of a broadband gateway, according
to an exemplary embodiment;
[0012] FIG. 10 depicts a flowchart of a broadband gateway,
according to an exemplary embodiment; and
[0013] FIG. 11 depicts a flowchart of a broadband gateway,
according to an exemplary embodiment.
DETAILED DESCRIPTION OF EMBODIMENTS
[0014] Exemplary embodiments may provide message processing in a
broadband gateway. For example, a system and method for processing
messages in a broadband assignment activation and inventory system
(BAAIS) gateway may be provided. That is, exemplary embodiments
may, among other things, expand the provisioning and activation of
broadband networks (e.g., DSL provisioning and service) to a
multi-protocol, multi-format, multi-interface, message processing,
routing, and distributing system and method. Moreover, exemplary
embodiments may provide a single point of entry and exit for all
inbound and outbound communication between external systems and
native multiple instances that exist on a per region basis in a
manner that is efficient and optimizes network utility.
[0015] FIG. 1 depicts a broadband gateway architecture 100 for
message processing, according to an exemplary embodiment. The
exemplary gateway architecture 100 is provided by way of example,
as there are a variety of architectures and components capable of
carrying out methods disclosed herein. The gateway 100 shown in
FIG. 1 may be executed or otherwise performed by one or a
combination of various modules and/or servers. Each block shown in
FIG. 1 represents one or more processes, methods, modules, or
subroutines carried in the exemplary gateway 100.
[0016] Referring to FIG. 1, the broadband gateway 100 may be a
broadband assignment activation and inventory system (BAAIS)
gateway and may include several modules for processing incoming
messages 105, (e.g., service requests or orders). In one
embodiment, the broadband gateway 100 may include an adapter module
110, a parser module 120, a router module 130, a transformer module
140, and a notifier module 150. After receiving and processing
incoming messages 105, the broadband gateway 100 may dispatch
outgoing messages 155 to complete broadband provisioning. See also,
for example, co-pending U.S. patent application Ser. No.
11/861,533, entitled "System and Method for Message Processing in a
Broadband Gateway," filed Sep. 26, 2007, which is hereby
incorporated by reference in its entirety.
[0017] Although each of the modules of the broadband gateway 100 is
depicted as a single module in FIG. 1, it should be appreciated
that each module may be combined into greater or fewer numbers. The
modules may be local, remote, or a combination thereof to each
other. It should also be appreciated that the modules of the
broadband gateway 100 may also be coupled to one or more data
storage systems and/or servers (not shown). These one or more data
storage systems and/or servers may store and process relevant
information received from one or more service clients and/or other
message senders. Exemplary information may include requests for
broadband service, such as DSL, but may also include provisioning
of other offered services. It should be appreciated that the one or
more data storage systems and/or servers may be combined into fewer
or greater numbers of data storage systems and/or servers to store
and process the received information. Furthermore, the data storage
systems and/or servers may be local, remote, or a combination
thereof to each other. Additionally, the databases and/or servers
may also store and process additional relevant information which
may further relate to provisioning or other similar services, such
personal service client information or information found in
metadata. Other variations may also be provided.
[0018] It should also be appreciated by one of ordinary skill that
each of the modules, data storages systems, and/or servers may
include one or more processors (not shown) for processing one or
more messages. The data and/or information in each of the one or
more messages or orders may be processed for storage, indexing,
interpretation, and/or conversion (transformation) by one or more
processors of the modules. By storing, indexing, interpreting,
and/or converting the data/information in one or more of the
message at the one or more modules of the broadband gateway 100,
the data/information may be shared by multiple modules. Such use
may be sequential or simultaneous. Furthermore, processing the
data/information in this way may also allow the processing logic to
cross-reference the various data/information for efficient use by
the system. Other various embodiments may also be provided.
[0019] Referring back to FIG. 1, the adapter module 110 may receive
one or more incoming messages 105 to request or order broadband
service. Once the one or more incoming messages 105 are received,
the adapter module 110 may accept the one or more incoming messages
105 and store and "persist" the one or more messages 105 in one or
more databases (not shown). Without this "persistence" capability,
data may exist only in memory (e.g., RAM) and may be lost when the
memory loses power, such as on computer shutdown. As a result,
persisting the one or more messages 105 may provide the ability to
retain data structures between program executions, such as, for
example, from one module to another module in the broadband gateway
100. The adapter module 110 may also send an acknowledgment (ACK)
to one or more senders (e.g., customers or clients requesting
broadband service) to confirm receipt of the one or more messages
105.
[0020] FIG. 2 depicts an architecture for receiving messages in a
broadband gateway 200, according to an exemplary embodiment. For
example, the adaptor module 110 may receive messages in a broadband
gateway 200. The exemplary architecture 200 is provided by way of
example, as there are a variety of architectures and components
capable of carrying out methods disclosed herein. The gateway 200
shown in FIG. 2 may be executed or otherwise performed by one or a
combination of various components, networks, modules, servers,
and/or interfaces. Other various embodiments may also be
provided.
[0021] Referring to FIG. 2, one or more service clients 202 may
include one or more service client interfaces 202a. Each of the one
or more service client interfaces 202a may support a variety of
different formats/protocols, such as web services
definition/description language (WSDL), simple object access
protocol (SOAP), or extensible markup language (XML). Other various
formats/protocols may also include messaging and queuing (MQ)
interface, Java message service (JMS), hypertext transfer protocol
secure (HTTPS), file transfer protocol (FTP), simple mail transfer
protocol (SMTP), common object request broker architecture (CORBA),
technical and office protocol communication (TOPCOM), etc.
Depending on the one or more service clients 202, these one or more
service client interfaces 202a may send and/or receive messages
through a network 204. The network 204 may support various
infrastructures 204a, such as HTTP or enterprise application
integration (EAT). One or more adaptor modules 210 may receive the
one or more messages 105 from the one or more service clients 202.
In one embodiment, the one or more adapter modules 210 may include
one or more adapter interfaces 210a, which are configured to
support a variety of formats and/or protocols similar to that of
the one or more service client interfaces 202a. As a result, the
one or more adaptor modules 210 may provide not only flexibility to
accommodate disparate systems, but also future growth with newer
and evolving, Other various embodiments may also be provided.
[0022] It should also be appreciated that the adaptor module 110
may be deployed on J2EE architecture component Service Layer
Session Bean (SLSB) or other similar architecture. Additionally,
the adaptor module 110 may employ clustering and/or instance
pooling. This may be achieved by creating a pool of multiple
instances of the module per JVM, in one or more JVMs (thereby
resulting in a cluster). This may provide efficient utilization of
server and system resources by promoting concurrent and parallel
processing to avoid system or processing contention issues. Other
various embodiments may also be provided.
[0023] FIG. 3 depicts a flowchart of parsing messages in a
broadband gateway 300, according to an exemplary embodiment. The
exemplary method 300 is provided by way of example, as there are a
variety of ways to carry out methods disclosed herein. The method
300 shown in FIG. 3 may be executed or otherwise performed by one
or a combination of various systems. The method 300 is described
below as carried out by the system 100 shown in FIG. 1 by way of
example, and various elements of the system 100 are referenced in
explaining the example method of FIG. 3. Each block shown in FIG. 3
represents one or more processes, methods, or subroutines carried
in the exemplary method 200. A computer readable media comprising
code to perform the acts of the method 300 may also be
provided.
[0024] Referring to FIG. 3, once the one or more messages 105 pass
through the adapter module 110, the parser module 120 may retrieve
these messages 105 as order messages 305 for interpreting and
parsing utilizing parsing logic 325. The parsing logic 325 may
further include several components. For example, an onMessage( )
328 may be an entry point for parsing and may obtain a parser class
for the order messages 305 being processed. An Instantiate Parser
Class 330 may load a transformer class. A Parser Registry Inventory
332 may be a repository, e.g., one or more data storage systems or
databases, for storing contents of order messages 305 being parsed.
A Process Information 334 may be the core step and/or component
where parsing occurs. Other various embodiments may also be
provided.
[0025] In one embodiment, the parser module 120 may utilize a
parallel distributed model to distribute load across one or more
application server instances while providing a single virtual
interface. In another embodiment, the parser module 120 may include
a messaging-based distributed model, in which one or more messages
105 may be distributed from the adapter module (or corresponding
database) to a queue at the parser module 120. For instance, this
may be achieved over a Java Message Service (JMS) architecture or
other similar architectural platform. A distributed asynchronous
architecture between the adapter module 110 and the parser module
120 may ensure that both modules work independent of each other and
thereby providing improved throughput to any external system.
[0026] However, it should be appreciated that when multiple
messages coming in from external systems are processed within a
distributed architecture having multiple Java Virtual Machines
(JVM), the order of processing the messages is not inherent or
typically preserved. In other words, messages received in a certain
order (e.g., M1-M2-M3-M4) may be committed out of sequence if
message M1 takes a long time to process and message M2 is much
quicker to process. In this example, message M2 may be processed
before message M1 in a typical distributed architecture.
[0027] As a result, before message parsing occurs, message
sequencing may also be preserved at a sequencing module (not shown)
without sacrificing the benefits of a decoupled broadband gateway
architecture (e.g., scalability, performance, and reliability). In
one embodiment, the sequencing module may sequence messages by at
least one of in-coming system name, event type, and source system
time. Other various sequencing elements may also be provided.
Additionally, the sequencing module may include built-in message
validation rules for meeting message formats and message components
requirements. Another embodiment may include built-in support for
region specific parsing classes (e.g., a "DSL Order Northeast
Parser" which may differ from a "DSL Order New York Parser") to
support multiple versioning and various geographical sites. Message
sequencing may help ensure that service order requests are parsed
and persisted in one or more databases for optimum network utility
and serviceability.
[0028] Sequencing may be important in the event of failure in
processing one or more messages. For example, sequencing may help
ensure provisioning steps or other processing actions occur in a
correct order. Furthermore, sequencing may help to ensure that
every step is accounted for. Even in the event multiple instances
are servicing a queue, a sequencing feature may serve to prevent
out of order actions and/or duplication of other processing
actions. In the event of failure, sequencing may provide a way to
verify which steps/actions have been successfully completed (e.g.,
received from the parser module 120 or other module). In other
words, sequencing may provide a "checklist" to ensure proper
processing of messages.
[0029] In one embodiment, for each service order, a backend
provisioning engine may generate events and/or messages to the
broadband gateway 100. The broadband gateway 100 may then be
required to process each of these events and/or messages in a
first-in, first-out (FIFO) sequence. Thus, as a part of processing,
the broadband gateway 100 may generate (depending on various
sequencing, business, or administrator-entered rules) events and/or
messages that need to be delivered to external systems (e.g., to
other modules/servers within the broadband gateway 100 or to
systems/servers outside of the broadband gateway 100), also in the
correct sequence.
[0030] For example, the following example may help define a
sequencing requirement. In this example, for a service order A, a
backend provisioning engine may generate ten (10) messages, e.g.,
M1, M2 through M10, one after another as part of an order workflow.
The broadband gateway, through the sequencing module, may ensure
that messages M1, M2 through M10 are processed in the same sequence
(e.g., message M2 never processed before message M1, etc.). It
should be appreciated that the processing order may not mean that
messages M1 through M10 will get delivered to the broadband gateway
processing server (e.g., router server 130) in the correct
sequence. In fact, it is the processing sequence, not the delivery
sequence that may get preserved. As part of processing a message,
e.g., M2, the sequencing module may provide business or
administrator rules to generate notification messages N1, N2, N3 to
three different external systems, e.g., Sys 1, Sys 2 and Sys 3,
respectively. As part of processing a message, e.g., M3, the
sequencing module may provide business or administrator rules to
generate notification messages N4, N5, N6 to the three different
external systems, e.g., Sys 1, Sys 2 and Sys 3, respectively.
Accordingly, in this scenario, the sequencing module may be
required to deliver N1 before delivering N4 to external system Sys
1, deliver N2 before N5 to external system Sys 2, and deliver N3
before N6 to external system Sys 3 as part of the notification
sequencing requirement to deliver messages in sequence for a given
entity (in this case a service order). As a result, in order to
meet this sequencing requirement and also come up with a solution
that avoids database polling, which is resource intensive, certain
rules may be further provided to ensure sequence processing for
distributed, multi JVM messaging architecture.
[0031] In one embodiment, these rules may rely on a database set of
tables and rules. Two rules designed for this purpose may include:
(1) avoiding parallel processing of message in the event the
message are to be processed in sequence and (2) delegating a next
message call responsibility on "Processed Message" to ensure
sequential message processing. As part of this design, for each
message received and in the event sequencing is required, the
sequencing module may create an entry in a sequence table, where
the sequence table includes the following exemplary identifications
(IDs) and/or keys to identify messages FIFO in a distributed
architecture: "id," "ext_tran_id," "source_system," "seq_no,"
"time," etc. In this example, "id" may be a primary key and
generated in the following format:
[0032] "Key"|"Transmitting System"|"Sequence Number," where Key may
include an order number, transaction number, global information
relating to sequencing, etc.
[0033] The "ext_tran_id" may be a Key for which messages are to be
sequenced. The "source_system" may identify the system transmitting
the message. The "seq_no," (e.g., seq_no 2) may provide auto
numbering sequencing. The "time" may provide date and time
information for which a message may be transmitted. [may be
logged]. other various embodiments may also be provided.
[0034] FIG. 4 depicts a flowchart of sequencing messages in a
broadband gateway, according to an exemplary embodiment. The
exemplary method 400 is provided by way of example, as there are a
variety of ways to carry out methods disclosed herein. The method
400 shown in FIG. 4 may be executed or otherwise performed by one
or a combination of various systems. The method 400 is described
below as carried out by the system 100 shown in FIG. 1 by way of
example, and various elements of the system 100 are referenced in
explaining the example method of FIG. 4. Each block shown in FIG. 4
represents one or more processes, methods, or subroutines carried
in the exemplary method 400. A computer readable media comprising
code to perform the acts of the method 400 may also be provided.
Referring to FIG. 4, the exemplary method 400 may begin at block
410.
[0035] At block 410, one or more messages or events 405 may be
received. For example, at least one receiver at a sequencing module
may receive one or more messages or events 405 from one or more
external systems (e.g., senders, gateway modules, servers, etc.).
In another embodiment, the one or more messages 405 may also be
received in a sequential order.
[0036] At block 420, the one or more messages or events 405 may be
stored (or persisted). For example, at least one data storage
system 425 at the sequencing module may store (or persist) the one
or more messages or events 405. In one embodiment, storing the one
or more messages or events may include numbering the one or more
messages/events based on the received sequential order. In another
embodiment, the one or more messages may be numbered based on a
delivered sequence. Other various embodiments may also be provided,
such as automatic numbering or sequencing rules.
[0037] At block 430a, 430b, the one or more messages 405 may be
sequenced or be identified for sequence. For example, at least one
identifier (e.g., a sequencing module 435) at the sequencing module
may identify a processing sequence for the one or more messages. In
one embodiment, identifying the processing sequence may be based on
the received or delivered sequential order. In another embodiment,
identifying the processing sequence may be based on an independent
sequential order governed by broadband gateway rules. In yet
another embodiment, identifying the processing sequence for the one
or more messages may be based on at least one of the following: a
time of receipt, a time of delivering, a sending source, a
transaction type, and an assigned number. In this example, one or
more message keys may be inserted 430b in sequence tables for each
of the one or more messages.
[0038] Additionally, identifying the processing sequence for the
one or more messages may further include determining use of
parallel processing or sequential message delegation. For instance,
even though parallel processing may be avoided in the event
messages are to be processed in sequence, as discussed above,
parallel processing may still be employed to efficiently process
messages as long as message are ultimately retrieved in sequence.
In this example, messages M1, M2, and M3 may be parallel processed
with messages M4, M5, and M6. In order to efficiently use network
resource availability, M4 through M6 may processed quicker than M1
through M3. But as long as M1 through M3 is made available before
M4 through M6 (which may be stored/persisted in one or more data
storage systems), parallel processing may remain a viable
sequencing option.
[0039] At block 440a, 440b, the one or more messages 405 may be
retrieved for processing. For example, at least one retriever
(e.g., the sequencing logic 435) at the sequencing module may
retrieve the one or more messages 405 from the at least one data
storage system 425 for further processing based on the identified
processing without database polling. In one embodiment, sequential
message delegation may be utilized to determine the next message in
sequence and whether the next message in sequence as arrived or
not. While the features and functionalities of message sequencing
are primarily discussed with respect to the sequencing module
above, it should be appreciated that the features and
functionalities of one module may be similarly executed by other
modules and/or other gateway components. It should also be
appreciated that in another embodiment, method 400 may further
include delivering the one or more messages 405 for further
processing at one or more external systems.
[0040] Referring back to FIG. 3, once the sequencing module
sequences the messages and once the parsing logic 325 of the parser
module 120 completes its processing of an order message 305, the
parser module 120 may output the message 355 for routing. Other
various embodiments may also be provided.
[0041] FIG. 5 depicts a flowchart of routing messages in a
broadband gateway 500, according to an exemplary embodiment. The
exemplary method 500 is provided by way of example, as there are a
variety of ways to carry out methods disclosed herein. The method
500 shown in FIG. 5 may be executed or otherwise performed by one
or a combination of various systems. The method 400 is described
below as carried out by the system 100 shown in FIG. 1 by way of
example, and various elements of the system 100 are referenced in
explaining the example method of FIG. 5. Each block shown in FIG. 5
represents one or more processes, methods, or subroutines carried
in the exemplary method 500. A computer readable media comprising
code to perform the acts of the method 500 may also be
provided.
[0042] Referring to FIG. 5, one or more inbound messages 502 that
have been parsed may arrive at the router module 130 for
distribution. In one embodiment, the router module 130 may route
service orders to various appropriate destinations by defining
message flow 504. For example, this may be achieved by providing a
routing directory routing definitions which may be persisted and
retrieved from a repository such as a database or a directory.
Additionally, the one or more parsed messages 502 may be defined as
one or more outbound message types 506 for distribution to one or
more outbound transformer queues 508.
[0043] In one embodiment, the router module 130 may also include a
message driven distributed architecture, such as JMS. In another
embodiment, load may be distributed across multiple JVM
architecture using message-oriented middleman (e.g., MOM). Other
various architectural platforms may also be provided.
[0044] Message routing in a broadband gateway 100 (e.g., BAAIS) may
be achieved by deploying various rules contained in a routing
engine (not shown) in the router module 130. Different kinds of
rules may yield different kinds of actions on different types of
messages. Rules governing routing may be immutable once the router
module 130 determines its value. The value for rules may be "true"
or "false." Actions, therefore, are causation of changes based on
rules and therefore function based on outcome of such rules. For
example, if a rule outcome is "true," a resulting action may be
that a system (e.g., System A) is alerted. However, if a rule
outcome is "false," another system or systems (e.g., System B or C)
may be notified. Accordingly, actions are performed at the instant
the value of the corresponding rules are evaluated. It should be
appreciated that these determinations are calculated at the various
components of the BAAIS gateway 100, but appear "instantaneous" to
service clients. It should also be appreciated that the router
module 130 may be dependent on various internal components of the
BAAIS gateway 100. Other various embodiments may also be
provided.
[0045] Messages may be classified in several ways. Event Types may
be one way to logically name inbound and outbound messages entering
and leaving the BAAIS gateway 100. This way of providing identifier
tags (e.g., Event Types) for messages may help to associate Parser
and/or Transformer classes to process messages. Furthermore,
providing identifier tags may also make it possible to route rules
and definitions so that they may be tied to Event Types for routing
messages in desired manner. Event Types may be stored in
inbound-outbound message mapping tables. In one embodiment, the
Event Types may be mapped with a Rule ID for each Type of message
type, as depicted in TABLE 1 below.
TABLE-US-00001 TABLE 1 In Event Type Out Event Type Destination
System Rule ID OrderAddEvent OrderNotifyEvent System A Rule A
OrderAddEvent OrderRecordEvent System B Rule B OrderAddEvent
OrderTaskEvent System C Rule C
[0046] Other various Event Types may also be provided, such as
OrderUpdateEvent, OrderRejectEvent, etc.
[0047] Rules attributes may be dynamic values associated with one
or more messages (which need to be routed). For example, these may
include PRODUCT, SYSTEM, ORDER TYPES, STATUS, etc. A rules engine
may further assign values to these rules attributes for additional
evaluation. A rules engine may also function as a central component
for storing, parsing, and validating rules, and setting up a system
based on these rules. Routing rules of the router module 130 may by
cached in memory to provide optimal performance on peak load. In
this example, the router module 130 may include a routing engine
supported by lexical parsing based on truth statements. For
example, the routing engine may provide a generic in-bound message
type mapping to an out-bound event map based on in-bound parsed
data, e.g., Order Type, Order System, Order Service, etc.
Accordingly, the routing engine may be a central component for all
region and message types. Furthermore, the routing engine may also
define one or more out-bound message types based on in-bound
messages.
[0048] As discussed above, one example of lexical parsing utilized
to generate rules and rule outcomes may be provided as: [0049]
((PRODUCT=DSL) AND (SOURCE_SYSTEM=SGW AND ORDER_TYPE=ADD AND
STATUS=JEOPARDY))
[0050] Accordingly, lexical parsing may then generate the following
outcome: [0051] (TRUE) AND (TRUE AND FALSE AND TRUE).fwdarw.outcome
as FALSE.
[0052] Additionally, various user interfaces may also be provided
to manage rule creation and Event Type mapping with rules and
attributes.
[0053] Various operators, expressions, and rules (facts) may also
be used. These may include, but not limited to EQUALS, NOT_EQUALS,
MATCHES, AND, OR, LESS_THAN, GREATER_THAN, OPEN_BRACKET,
CLOSE_BRACKET, etc. Once these rules have been loaded to an inbound
message type (e.g., Event Type for inbound message), all the rules
may be automatically parsed as one or more truth statement
generated based on inbound message attributes one after another.
For example, this may be expressed as follows: [0054]
((PRODUCT=DSL) AND (SOURCE_SYSTEM=SGW AND ORDER_TYPE=ADD AND
STATUS=JEOPARDY))
[0055] Accordingly, lexical parsing may then generate following
outcome: [0056] (TRUE) AND (TRUE AND TRUE AND TRUE).fwdarw.outcome
as TRUE
[0057] Once the outbound messages have been distributed by the
router module 130, the one or more outbound transformer queues 508
may receive the messages to begin a message transforming process.
Other various embodiments may also be provided.
[0058] FIG. 6 depicts a flowchart of transforming messages in a
broadband gateway 600, according to an exemplary embodiment. The
exemplary method 600 is provided by way of example, as there are a
variety of ways to carry out methods disclosed herein. The method
600 shown in FIG. 6 may be executed or otherwise performed by one
or a combination of various systems. The method 600 is described
below as carried out by the system 100 shown in FIG. 1 by way of
example, and various elements of the system 100 are referenced in
explaining the example method of FIG. 6. Each block shown in FIG. 6
represents one or more processes, methods, or subroutines carried
in the exemplary method 600. A computer readable media comprising
code to perform the acts of the method 600 may also be
provided.
[0059] The transforming logic 625 may further include several
components. For example, an onMessage( ) 628 may be an entry point
for transforming and may obtain a transformer class for the order
messages 605 being processed. An Instantiate Transformer Class 630
may load a transformer class. A Transformer Registry Inventory 632
may be a repository, e.g., one or more data storage systems or
databases, for storing contents of order messages 605 being
transformed. A Process Information 634 may be the core step and/or
component where parsing occurs. Other various embodiments may also
be provided.
[0060] Messages 605 may also be transformed in sequence. For
example, utilizing a message sequencing function 636 such as
OutboundCreateTime (e.g., as established in a previous routing
step) may help ensure that steps happen in proper order. Another
example may include establishing a PVC before testing the PVC.
Other various actions may also be provided.
[0061] In addition, if the message format and/or content is the
same for multiple outbound messages (e.g., CDI messages), the
transformer module 140 may also protect against duplicate
transformation. In another embodiment, the transformer module 140
may utilize application server clustering to distribute load across
multiple JVM, such as using message-oriented middleman (e.g., MOM),
which may achieve optimum resource utilization. Other various
embodiments may also be provided.
[0062] After messages 605 are passed through the transformer module
140, the notifier module 150 may retrieve the processed messages
655 for completing the provisioning process.
[0063] FIG. 7 depicts a flowchart of dispatching messages in a
broadband gateway 700, according to an exemplary embodiment. The
exemplary method 700 is provided by way of example, as there are a
variety of ways to carry out methods disclosed herein. The method
700 shown in FIG. 7 may be executed or otherwise performed by one
or a combination of various systems. The method 700 is described
below as carried out by the system 100 shown in FIG. 1 by way of
example, and various elements of the system 100 are referenced in
explaining the example method of FIG. 7. Each block shown in FIG. 7
represents one or more processes, methods, or subroutines carried
in the exemplary method 700. A computer readable media comprising
code to perform the acts of the method 700 may also be
provided.
[0064] Referring to FIG. 7, the notifier module 150, for example,
may retrieve the outbound event 705 (e.g., from the transformer
module 140) and follow a dispatch logic 725 to disseminate outbound
event messages 755. The dispatch logic 725 may further include
several components and/or steps. For example, after verifying that
a Notification Subscription 726 is ON, an onMessage( ) 728 may
obtain message content for an event being processed. A Notification
Ext System 730 may then check if messages are in sequence 732 (as
discussed above), and if this is verified, the Notification Ext
System 730 may establish at least one communication 734 to deliver
the one or more messages 750. However, if communications cannot be
established, an Interface Watch 736 may be invoked and one or more
attempts may be made to establish communication at a predetermined
interval (e.g., 5 minutes or less). Additionally, the Notification
Subscription 726 may be turned OFF 738 and an Interface Status may
also be marked as DOWN 740. Once communication is established, the
Notification Subscription 726 may be turned back ON 738 and the
Interface Status may be marked as UP 740. As discussed above, a
Transformer Registry Inventory 742 may be a repository, e.g., one
or more data storage systems or databases, for storing contents of
order messages 705 being transformed.
[0065] Similar to the adapter module 120, the notifier module 150
may support the following formats/protocols to dispatch outbound
messages: CORBA, JMS/MQ, HTTPS, SOAP/WSDL, SMTP, FTP, etc.
Notification channels of the notifier module 150 may include a per
interfacing system. Here, notification support strategy for service
license agreements (SLAs) may be included to watch which timeout on
an interface in the event there is failure to respond in a
predetermined (configured) time. In another embodiment, sequencing
logic may be implemented to ensure that outbound messages 755 are
delivered to external systems in a predetermined order, such as the
manner the service requests were initially received. Furthermore,
these outbound notification messages 755 may be transmitted to the
original sender of the service order or to BAAIS regional centers
(not shown) for distribution. Additionally, the outbound messages
755 may include Acceptance, Assignment, Activation, Completion, or
other similar messages to indicate notification status. Other
various embodiments may also be provided.
[0066] Although each of the modules of the broadband gateway 100 is
depicted as a single module in FIG. 1, it should be appreciated
that these modules may be combined into greater or fewer numbers.
For example, FIG. 8 depicts an architecture of a broadband gateway
800, according to an exemplary embodiment. In this example, rather
than having a separate transformer module and a separate notifier
module, the broadband (e.g., BAAIS) gateway 800 has a
transformer/notifier module 845. The transformer/notifier module
845 may perform all of the functions and features of a separate
transformer module and a separate notifier module. By combining
modules, in this case the transformer and notifier module, the
broadband gateway 800 may be more streamlined and efficient in
processing messages. The broadband gateway 800 may also be better
suited to adapt to various physical settings depending on space
availability or limitations of data centers. In one embodiment, the
modules of the broadband gateway 100 may be local, remote, or a
combination thereof to each of the other modules. Other various
embodiments may also be provided.
[0067] It should also be appreciated that the modules of the
broadband gateway 100 may be coupled to one or more data storage
systems and/or servers (not shown). In one embodiment, the one or
more data storage systems and/or servers, which may be coupled to
one or more of the modules described above, may store and process
relevant information received from one or more service clients
and/or other message senders. Exemplary database and processing
information may include requests for broadband service, such as
DSL, but may also include other similar information, such as
provisioning of other services. Although databases and/or servers
are not shown, it should be appreciated that the contents of these
databases and/or servers may be combined into fewer or greater
numbers of databases and may be stored on one or more data storage
systems and/or servers. Furthermore, the databases and/or servers
may be local, remote, or a combination thereof to each other.
Additionally, the databases and/or servers may also store
additional relevant information, such as metadata or personal
service client information, which may further relate to
provisioning or other similar services. Other variations may also
be provided.
[0068] It should also be appreciated by one of ordinary skill that
each of the modules, data storages systems, and/or servers may
include one or more processors (not shown) for processing inbound
and outbound messages. The data and/or information in each of the
one or more messages or orders may be processed for storage,
indexing, interpretation, and/or conversion (transformation) by one
or more processors of the broadband modules. Other various
embodiments may also be provided.
[0069] Storing, indexing, interpreting, and/or converting the
data/information in one or more of the message at the one or more
modules of the broadband gateway 100 may allow use of the same
data/information by multiple modules. Such use may be sequential or
simultaneous. Furthermore, processing the data/information in this
way may also allow the processing logic to cross-reference the
various data/information for efficient use by the system. Other
various embodiments may also be provided.
[0070] Embodiments of message processing by broadband gateway may
provide several advantages. For example, a variety of different
types of formats and protocols may be serviced. As discussed above,
the adapter module 110 and the notifier module 150 may support a
variety of formats/protocols (e.g., WSDL/SOAP, XML, MQ, JMS, HTTPS,
FTP, SMTP, CORBA, TOPCOM, etc.) from a variety of various external
systems and/or mO, g., SGW, 10M, O, CABS, SSP, SOAC, VCHK, LFAC,
SWITCH, TOM, SOM, WAP, etc.). This enables the broadband gateway to
improve communication for various service clients.
[0071] Another advantage of the broadband gateway for message
processing is that a decoupled architecture is provided. The fact
that there are at least five distinct modules, each one being
decoupled to each other, a BAAIS gateway, for example, may provide
asynchronous modules that are capable of performing functions
independent of other modules or other network components. Such a
structure not only provides improved flexibility, but also a more
streamlined approach to provisioning. In fact, a decoupled
architecture may provide greater reliability.
[0072] For example, load balancing, scalability, and improved data
recovery may also be achieved through this structure. By spreading
the work (load balancing) between many modules, servers, computers,
processors, data storage systems, and/or other similar components,
resource utilization may be optimized. In addition, load balancing
may provide overall decreased computing time, ultimately providing
improved provisioning and related services to various customers and
clients.
[0073] Furthermore, having asynchronous handoff capabilities may
also provide a beneficial scalability feature. For example, the
fact that the various modules, servers, computers, processors, data
storage systems, and/or other similar components needed to
provision and activate broadband services remains unfixed, the
BAAIS gateway may possess less or more of any one of these
components on an as needed basis to further improve efficiency and
resource utilization.
[0074] Another benefit of a decoupled structure may include
enhanced data recovery and decreased error rates. For example, as
soon as a module complete its job, it passes the one or more
messages to the next module to pick up whenever it is ready to
perform its job. This creates a more seamless processing of
messages and minimizes potential hiccups or error signals along the
way. As a result, the quality of processing messages may not be
lost to the quantity of messages ordered for processing.
[0075] Advantages in business and marketing may also be apparent.
For example, having a customer-friendly design for receiving
messages and sending notifications in various formats and/or
protocols may decrease incompatibility issues and improve quality
of service. Moreover, optimizing network resource utility may
provide more efficient and reliable provisioning. Accordingly, the
broadband gateway structure described above provides a substantial
business and marketing advantage that conventional systems and
techniques simply cannot offer.
[0076] FIG. 9 depicts an architecture of a broadband gateway 900,
according to an exemplary embodiment. In this example, a
transformer module 940 may transmit outbound messages tione or more
notifier modules 950a, 950b. Multiple notifier modules 950a, 950b
may provide message notification to a variety of recipients. In one
embodiment, a notifier module 950a may provide notification to one
or more additional broadband gateways, e.g., BAAIS 1, BAAIS 2, etc.
In this example, the additional broadband gateways may be
regionally situtated for further processing the one or more message
orders for dissemination to respective service clients within that
particular region. In another embodiment, a notifier module 950b
may provide direct notifications in a variety of formats/platforms
to other service clients or for additional repairs, as depicted in
FIG. 9. In yet another embodiment, a notifier module 950a may
transmit message to multiple parties, such as to a broadband
regional gateway or service client, as depicted in FIG. 9.
Accordingly, such a broadband gateway structure 900 may provide a
more flexible approach to provisioning, especially one that is
capable of providing greater efficiency message delivery.
[0077] FIG. 10 depicts an architecture of a broadband gateway 1000,
according to an exemplary embodiment. In this example, a first
broadband gateway (Box 1) 1010 may interact with external inbound
interfaces 1020, external databases 1022, and external outbound
interfaces 1024. A second broadband gateway (Box 2) 1030 may also
interact with the external inbound interfaces 1020, the external
databases 1022, and the external outbound interfaces 1024. It
should be appreciated that FIG. 10 depicts a gateway architecture
in a multi-JVM environment and a multi-JVM, multi-box (clustered)
environment that may allow applications to operate in a load
balanced and redundant, high availability configuration with
potential to scale as needed as the load increases.
[0078] FIG. 11 depicts a flowchart of a broadband gateway 1100,
according to an exemplary embodiment. In this example, Box 1 1110
may include a first set of BAAIS gateways 1112, 1114, 1116, 1118
that communicate with inbound interfaces 1120, databases 1122, and
outbound interfaces 1124 that are all internal or local to Box 1
1110. Box 2 1130 may include a second set of BAAIS gateways 1132,
1134, 1136, 1138 that communicate with the inbound interfaces 1120,
the databases 1122, and the outbound interfaces 1124. It should be
appreciated that FIG. 11 depicts a gateway architecture in a
multi-JVM environment and a multi-JVM, multi-box (clustered)
environment that may allow applications to operate in a load
balanced and redundant, high availability configuration with
potential to scale as needed as the load increases.
[0079] Since the role of each of the broadband gateway components
is well-defined, the modules and corresponding components may
therefore provide services available to each other in a controlled
and secure manner. In addition, since the broadband gateway as
described above uses heterogeneous communication protocols that
stress location transparency and interoperability, it may better
serve clients' requests and orders. Embodiments of the broadband
gateway provide the ability to incrementally extend the initial
deployment to reflect evolving requirements and may therefore also
integrate additional systems. Another beneficial feature of
embodiments of the BAAIS gateway may include an infrastructure that
has capabilities to route and deliver service requests message to
the correct service provider in sequence.
[0080] While the features and functionalities of the broadband
gateway and message processing modules are primarily discussed with
respect to the embodiments above, it should be appreciated that the
features and functionalities of one embodiment may be similarly
applied to other embodiments. Furthermore, while provision and
activation of broadband services discussed above pertain to DSL, it
should be appreciated by one skilled in the art that the functions
and features of the program information menu may apply similarly to
other types of broadband provisioning or other similar
communication services as well, where applicable. Other variations
may also be provided.
[0081] In the preceding specification, various embodiments have
been described with reference to the accompanying drawings. It
will, however, be evident that various modifications and changes
may be made thereto, and additional embodiments may be implemented,
without departing from the broader scope of the disclosure as set
forth in the claims that follow. The specification and drawings are
accordingly to be regarded in an illustrative rather than
restrictive sense.
* * * * *