Process driven messaging service
 | This article, Process driven messaging service, has recently been created via the Articles for creation process. Please check to see if the reviewer has accidentally left this template after accepting the draft and take appropriate action as necessary.
Reviewer tools: Inform author |
| This article, Process driven messaging service, has recently been created via the Articles for creation process. Please check to see if the reviewer has accidentally left this template after accepting the draft and take appropriate action as necessary.
Reviewer tools: Inform author |
Comment: See also, WP:REFB & WP:NOR. Anupmehra -Let's talk! 12:18, 5 March 2014 (UTC)
A process driven messaging service (PDMS) is services that are process oriented and that exchange messages/data calls. A PDMS is a service were jobs and triggers can be put together to create a work flow for a message.
Messaging platforms are considered one of few key Internet infrastructure elements. What used to be only referred to as a few message types like email and IM has evolved into a complex multi-media email, instant messaging, and related fixed and mobile messaging infrastructure. One can argue that everything transmitted on the Internet and wireless telecommunication links is a message of one sort or another.
PDMS exchanges messages for the purpose of and all kind of messages/data calls between systems, applications and or human beings that is based upon event-driven process.[1]
Structure
A process driven messaging service is a service were jobs and triggers can be put together to create a work flow for a message. The work flow can be seen as a process.
A workflow will execute when a trigger gets triggered. That trigger will cause one or more jobs to be executed. The jobs can in turn execute more jobs. When all jobs have been executed the workflow will still be active, but nothing happens until it is triggered again.[2]
Workflows
A workflow iin PDMS is used to wrap triggers and/or jobs together to accomplish a flow of actions and events that can be invoked over and over again without repeating all configuration. What also should note that a workflow is a container. A Workflow Process is a container for a group of Workflow Statuses and Actions, moving a record from one status to another.[3] It can apart from triggers and jobs contain groups or, artifacts. These items that the workflow can contain are then available to all triggers and jobs within the workflow.
The concept of workflow can be seen as a template for a part of, or a whole business process. Workflows can with the help of triggers be invoked by a number of different reasons. For example when something happens in the domain or an explicit call to invoke.
When a workflow, its triggers and jobs are active the workflow is active and will be in a state where it waits to execute. A workflow will execute when a trigger gets triggered. That trigger will cause one or more jobs to be executed. The jobs can in turn execute more jobs. When all jobs have been executed the workflow will still be active, but nothing happens until it is triggered again.
When created, workflows expects the last part of the workflow to be added first. That last part would be a job. Also jobs and triggers wants to know the next step in the flow when they are created, meaning that they too advocate creating the workflow in reverse order.[4]
Jobs
A job is an activity in a workflow. It represents something that a system do with the data, an activity in the system domain.
Triggers
A trigger represents something that has happened and causes jobs to execute. In a way we can think of it as what starts/executes a workflow. The objects components that define business logic and behaviour are called Triggers. You can create and configure any number of Triggers to perform automated and programmatic validation, notification, data manipulation and other activities upon record creation, update and deletion.[5]
Processes
A process starts at some point in the system. For example when a trigger executes an instance of a workflow.
A process driven messaging service is often used when managing a more or less complex business processes.
With a well developed process driven messaging platform all triggers and jobs can be exposured in a public API (application programming interface) and it will be possible to create the process in the API.
Technology/programming
PDMS is based upon Event-Driven Architecture whereas the architectural pattern may be applied by the design and implementation of applications and systems which transmit events among loosely coupled software components and services. Unlike traditional information systems which work by issuing requests and waiting for responses, event-driven systems are designed to process events as they occur, allowing the system to observe, react dynamically, and issue personalized data depending on the recipient and situation.[2]
Providers
A process driven messaging service is a service based upon the methodology/service Process Driven Messaging Service were jobs and triggers can be put together to create a work flow for a message. The work flow can be seen as a process.
A workflow will execute when a trigger gets triggered. That trigger will cause one or more jobs to be executed. The jobs can in turn execute more jobs. When all jobs have been executed the workflow will still be active, but nothing happens until it is triggered again.
Mobile Response is a service that based its technology upon PDMS.
Applicable Areas
Areas whereas PDMS can be used in is System to System, A2P with the difference that other message types can be included in the PDMS, Application to Application, System to Person, M2M and all kind of messages/data calls between systems, applications and or human beings that is based upon event-driven process.
See also
- Internet Messaging Platform
- Event-driven architecture
- Architectural Pattern
- Critical Internet infrastructure
- Loose coupling
- Application-to-Person (A2P) SMS
- Machine to machine (M2M)
- Service (systems architecture)
References
- ^ Hommes, Lambertus Johannes (2004). "7". The evaluation of business process modeling techniques (PDF). [S.l.: s.n.] pp. 138–187. ISBN 90-9017698-5.
{{cite book}}:|archive-date=requires|archive-url=(help); Check date values in:|archivedate=(help) - ^ a b Opher Etzion, Peter Niblett (September 2007). Event Processing in Action 1st. Greenwich, CT, USA: Manning Publications Co. ISBN 1935182218.
{{cite book}}: horizontal tab character in|author=at position 20 (help) - ^ Progress Software Corporation. "Rollbase in action" (PDF). Chapter 10. p. 6.
- ^ UWE, ZDUN (September 19, 2007). "HENTRICH, DUSTDAR" (PDF). Modeling Process-Driven and Service-Oriented Architectures Using Patterns and Pattern Primitives. Volume 1 (Issue 3). New York: ACM, Inc.: 23–27.
{{cite journal}}:|issue=has extra text (help);|volume=has extra text (help); Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ "10". Rollbase in Action (PDF). Progress Software Corporation. pp. 266–289.
| This article, Process driven messaging service, has recently been created via the Articles for creation process. Please check to see if the reviewer has accidentally left this template after accepting the draft and take appropriate action as necessary.
Reviewer tools: Inform author |
| This article, Process driven messaging service, has recently been created via the Articles for creation process. Please check to see if the reviewer has accidentally left this template after accepting the draft and take appropriate action as necessary.
Reviewer tools: Inform author |