Friday, December 9, 2011
Friday, January 21, 2011
TIMCO JMS(EMS) Message Structure
A JMS message has three sections:
• Header (some header fields are required)
• Properties (optional)
• Body (optional)
Header Fields
The header contains ten predefined fields that contain values used to route and deliver messages.
Properties
TIBCO Enterprise Message Service includes several vendor-specific properties in this area. TIBCO-specific property names begin with JMS_TIBCO.
Message Bodies
A JMS message has one of several types of message bodies, or no message body at all.
Message Persistence
JMS defines two message delivery modes, persistent and non-persistent. This mode is set by the message sender or publisher in the JMSDeliveryMode message header field. Non-Persistent messages are never written to persistent storage.
Persistent messages are logged to persistent storage when they are sent.
Messages with the persistent delivery mode are always written to persistent storage, except when they are published to a topic that has no durable subscribers. When a topic has no durable subscribers, there are no subscribers that need messages resent in the event of a server failure. Therefore, messages do not need to be saved, and performance is improved because disk I/O is not required.
File Locking
Each EMS server writes persistent messages to a store file. To prevent two servers from using the same store file, each server restricts access to its store file for the duration of the server process.
On Windows platforms, servers use the standard Windows CreateFile function, supplying FILE_SHARE_READ as the dwShareMode (third parameter position) to restrict access to other servers.
Character Encoding in Messages
TIBCO Enterprise Message Service clients can specify a variety of common character encodings for strings in messages. The character encoding for a message applies to strings that appear in any of the following places within a message:
• property names and property values
• MapMessage field names and values
• data within the message body
The EMS client APIs (Java, .NET and C) include mechanisms for handling strings and specifying the character encoding used for all strings within a message.
Message Compression
TIBCO Enterprise Message Service allows the message body to be compressed by the client before the message is sent to the TIBCO Enterprise Message Service server.
Message compression is especially useful when messages will be stored on the server (persistent queue messages, or topics with durable subscribers). Setting compression ensures that messages will take less memory space in storage.
When messages are compressed and then stored, they are handled by the server in the compressed form. Compression assures that the messages will usually consume less space on disk and will be handled faster by the EMS server.
Setting Message Compression
To set message compression, the application that sends or publishes the message must access the message properties and set the boolean property JMS_TIBCO_COMPRESS to true before sending or publishing the message. For example:
message.setBooleanProperty("JMS_TIBCO_COMPRESS",true);
Compressed messages are handled transparently. The client code only sets the JMS_TIBCO_COMPRESS property. The client code does not need to take any other action.
Message Acknowledgement
The specification defines three levels of acknowledgement:
• DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicate messages.
• AUTO_ACKNOWLEDGE, in which the session automatically acknowledges a client’s receipt of a message.
• CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the message’s acknowledge method.
• Header (some header fields are required)
• Properties (optional)
• Body (optional)
Header Fields
The header contains ten predefined fields that contain values used to route and deliver messages.
Properties
TIBCO Enterprise Message Service includes several vendor-specific properties in this area. TIBCO-specific property names begin with JMS_TIBCO.
Message Bodies
A JMS message has one of several types of message bodies, or no message body at all.
Message Persistence
JMS defines two message delivery modes, persistent and non-persistent. This mode is set by the message sender or publisher in the JMSDeliveryMode message header field. Non-Persistent messages are never written to persistent storage.
Persistent messages are logged to persistent storage when they are sent.
Messages with the persistent delivery mode are always written to persistent storage, except when they are published to a topic that has no durable subscribers. When a topic has no durable subscribers, there are no subscribers that need messages resent in the event of a server failure. Therefore, messages do not need to be saved, and performance is improved because disk I/O is not required.
File Locking
Each EMS server writes persistent messages to a store file. To prevent two servers from using the same store file, each server restricts access to its store file for the duration of the server process.
On Windows platforms, servers use the standard Windows CreateFile function, supplying FILE_SHARE_READ as the dwShareMode (third parameter position) to restrict access to other servers.
Character Encoding in Messages
TIBCO Enterprise Message Service clients can specify a variety of common character encodings for strings in messages. The character encoding for a message applies to strings that appear in any of the following places within a message:
• property names and property values
• MapMessage field names and values
• data within the message body
The EMS client APIs (Java, .NET and C) include mechanisms for handling strings and specifying the character encoding used for all strings within a message.
Message Compression
TIBCO Enterprise Message Service allows the message body to be compressed by the client before the message is sent to the TIBCO Enterprise Message Service server.
Message compression is especially useful when messages will be stored on the server (persistent queue messages, or topics with durable subscribers). Setting compression ensures that messages will take less memory space in storage.
When messages are compressed and then stored, they are handled by the server in the compressed form. Compression assures that the messages will usually consume less space on disk and will be handled faster by the EMS server.
Setting Message Compression
To set message compression, the application that sends or publishes the message must access the message properties and set the boolean property JMS_TIBCO_COMPRESS to true before sending or publishing the message. For example:
message.setBooleanProperty("JMS_TIBCO_COMPRESS",true);
Compressed messages are handled transparently. The client code only sets the JMS_TIBCO_COMPRESS property. The client code does not need to take any other action.
Message Acknowledgement
The specification defines three levels of acknowledgement:
• DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicate messages.
• AUTO_ACKNOWLEDGE, in which the session automatically acknowledges a client’s receipt of a message.
• CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the message’s acknowledge method.
The following describes the steps in message delivery and acknowledgement:
1. A message is sent from the message producer to the machine on which the TIBCO Enterprise Message Service server resides.
2. The EMS server acknowledges that the message was received.
3. The server sends the message to the consumer.
4. The consumer sends acknowledgement to the server that the message was received.
5. In many cases, the server then confirms acknowledgement to the consumer.
Acknowledgement from the consumer to the server prevents the delivery of duplicate messages.
Undelivered Message Queue
If a message is to be removed from the system in any way besides being properly consumed by a message consumer, the server checks the message for the JMS_TIBCO_PRESERVE_UNDELIVERED property.
When JMS_TIBCO_PRESERVE_UNDELIVERED is set to true, the server moves the message to the undelivered message queue, $sys.undelivered. This undelivered message queue is a system queue that is always present and can not be deleted.
To set use of the undelivered message queue, the application that sends or publishes the message must set the boolean JMS_TIBCO_PRESERVE_UNDELIVERED property to true before sending or publishing the message. For example:
message.setBooleanProperty("JMS_TIBCO_PRESERVE_UNDELIVERED",true);
EMS Message Delivery Mode Extensions
JMS has PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. In addition to these modes, you can use Tibjms.RELIABLE_DELIVERY mode from TIBCO Enterprise Message Service.
PERSISTENT and NON_PERSISTENT delivery require the server to return a system message to the client application to ensure proper handling of messages. Using Tibjms.RELIABLE_DELIVERY as the JMSDeliveryMode precludes the TIBCO Enterprise Message Service server from sending this system message.
In reliable delivery mode, the client application does not wait for this system message—indeed, the server does not send it. Reliable mode decreases the volume of message traffic, allowing better usage of system resources, and higher message rates. You can set the delivery mode to reliable in one of two ways:
• Use a publish() or send() method that accepts a javax.jms.DeliveryMode as a parameter.
• Set the delivery mode for the message producer using the following expression:
No-Acknowledgement Message Receipt
TIBCO Enterprise Message Service provides a mechanism for not acknowledging the receipt of messages. In no-acknowledge receipt mode, after the server sends a message to the client, all information regarding that message for that consumer is eliminated from the server. Therefore, there is no need for the client application to send an acknowledgement to the server about the received message. Not sending acknowledgements decreases the message traffic and saves time for the receiver, therefore allowing better utilization of system resources. No-acknowledgement receipt mode is configured at the session level. Add the com.tibco.tibjms.Tibjms.NO_ACKNOWLEDGE constant when you create the session. For example:
javax.jms.TopicSession session =
topicConnection.createTopicSession(
false,com.tibco.tibjms.Tibjms.NO_ACKNOWLEDGE);
Wednesday, November 10, 2010
Book Review: Oracle Fusion Middleware Patterns
Book Review: Oracle Fusion Middleware Patterns by Harish Gaur and, Markus Zirn: Publisher- Packt: ISBN- 13: 978-1847198327
Oracle Fusion Middleware pattern book is a collection of case studies for Oracle Fusion Middleware across the globe and across the industry. This book is primarily targeted to planners and high level business decision makers with hints of technical stuff. With respect to target audience, packtpb site indicates for IT manager but, I differ here.
Book can be read online at http://www.oracle.com/technetwork/articles/entarch/index-098853.html.
Book is divided into three groups: Process Improvement, Business Visibility, and Collaboration and Security to club case studies accordingly.
Book is good read for staff members of enterprises who are moving to Oracle Fusion Middleware stack.
Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.
One can get more information about book and related topics from:
1. Book’s web presence http://www.oracle.com/technetwork/articles/entarch/index-098853.html
2. Amazon: http://www.amazon.com/Oracle-Fusion-Middleware-Patterns-Harish/dp/1847198325
3. Publisher -- Packtpb https://www.packtpub.com/enterprise-solution-architecture-patterns-by-oracle-fusion-middleware/book
4. Harish Gaur’s Blog: http://blogs.oracle.com/harishgaur/2010/10/fusion_middleware_patterns.html
5. Surachart Opun’s Review: http://surachartopun.com/2010/09/oracle-fusion-middleware-patterns-book.html
6. Wow Books Review: http://www.wowebook.com/business/oracle-fusion-middleware-patterns.html
Oracle Fusion Middleware pattern book is a collection of case studies for Oracle Fusion Middleware across the globe and across the industry. This book is primarily targeted to planners and high level business decision makers with hints of technical stuff. With respect to target audience, packtpb site indicates for IT manager but, I differ here.
Book can be read online at http://www.oracle.com/technetwork/articles/entarch/index-098853.html.
Book is divided into three groups: Process Improvement, Business Visibility, and Collaboration and Security to club case studies accordingly.
Book is good read for staff members of enterprises who are moving to Oracle Fusion Middleware stack.
Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.
One can get more information about book and related topics from:
1. Book’s web presence http://www.oracle.com/technetwork/articles/entarch/index-098853.html
2. Amazon: http://www.amazon.com/Oracle-Fusion-Middleware-Patterns-Harish/dp/1847198325
3. Publisher -- Packtpb https://www.packtpub.com/enterprise-solution-architecture-patterns-by-oracle-fusion-middleware/book
4. Harish Gaur’s Blog: http://blogs.oracle.com/harishgaur/2010/10/fusion_middleware_patterns.html
5. Surachart Opun’s Review: http://surachartopun.com/2010/09/oracle-fusion-middleware-patterns-book.html
6. Wow Books Review: http://www.wowebook.com/business/oracle-fusion-middleware-patterns.html
Sunday, October 17, 2010
To find the tasks that is triggered with in process definition in OIM
select pkg.pkg_name, org.mil_name as taskname, rsc_data as status, gen.mil_name as triggered
from mil gen, mil org, rsc, rgm, tos, pkg
where
gen.mil_key = rgm.mil_key
and rsc.rsc_key = rgm.rsc_key
and tos.pkg_key = pkg.pkg_key
and gen.tos_key = tos.tos_key
and pkg.pkg_name like '%PackageName%'
and org.mil_key = rsc.mil_key
order by org.mil_name;
from mil gen, mil org, rsc, rgm, tos, pkg
where
gen.mil_key = rgm.mil_key
and rsc.rsc_key = rgm.rsc_key
and tos.pkg_key = pkg.pkg_key
and gen.tos_key = tos.tos_key
and pkg.pkg_name like '%PackageName%'
and org.mil_key = rsc.mil_key
order by org.mil_name;
Wednesday, October 13, 2010
Performance Tuning in OFMW SOA Suite
A. SOA Component Level
a. BPEL/BPMN Engine Level
i. Concurrency
1. # of Threads to process invocation messages (dspInvokeThreads)
2. # of Threads to process engine messages (dspEngineThreads)
3. # of Threads to process system messages dspSystem Threads
ii. Memory/DB
1. Audit Trail logging levels (AuditLevel)
2. Message Persistence (oneWayDeliveryPolicy)
iii. CPU
1. XML Validations (validateXML)
2. Statistics for most recently processed requests (statsLastN)
b. BPEL/BPMN Process Level
i. Response Time:
1. Parallel processing of invole in multiple branches (nonBlockingInvoke)
2. Synchronous / Transient process design
ii. Database
1. Dehydration needed or not (inMemoryOptimization)
2. Instance data storage in DB (completionPersistPolicy)
iii. CPU
1. Payload Validation (validateXML)
c. Mediator
i. Concurrency
1. Parallel Routing ( # of parallel threads for message processing )
2. Resequencer ( # of worker threads )
ii. Database
1. Audit Level
2. Parallel Routing (# of rows that are fetched by each thread per iteration )
3. Resequencer (# of Groups that are locked by each thread at a time )
iii. CPU
1. Metrics Level
2. Sleep intervals before next polling
d. Database Adapters
i. Concurrency
1. # of worker / Poller / Dequeue threads
ii. Database
1. # of rows to be processed per transaction (MaxTransactionSize)
2. # of file records to be processed (MaxRaiseSize)
3. Collect stats on relevant tables
4. Large files
iii. CPU
1. Process design
2. IO
3. # Threads at the application server level
B. SOA Infrastructure Level
a. Database
i. Audit Level
ii. Purging
b. CPU
i. Payload Validation
C. Generic
a. Operating System
b. JVM
i. Heap Size
ii. Nursery Size
iii. GC Algorithm
iv. Use Large pages
v. 64 bit vs 32 bit
c. Database
i. SOA & Application Schema tuning
ii. Tuning Parameters
iii. Redo Logs
d. WebLogic Application Server
i. Production Mode
ii. Connection Pooling
iii. Logging
iv. Self tuning
a. BPEL/BPMN Engine Level
i. Concurrency
1. # of Threads to process invocation messages (dspInvokeThreads)
2. # of Threads to process engine messages (dspEngineThreads)
3. # of Threads to process system messages dspSystem Threads
ii. Memory/DB
1. Audit Trail logging levels (AuditLevel)
2. Message Persistence (oneWayDeliveryPolicy)
iii. CPU
1. XML Validations (validateXML)
2. Statistics for most recently processed requests (statsLastN)
b. BPEL/BPMN Process Level
i. Response Time:
1. Parallel processing of invole in multiple branches (nonBlockingInvoke)
2. Synchronous / Transient process design
ii. Database
1. Dehydration needed or not (inMemoryOptimization)
2. Instance data storage in DB (completionPersistPolicy)
iii. CPU
1. Payload Validation (validateXML)
c. Mediator
i. Concurrency
1. Parallel Routing ( # of parallel threads for message processing )
2. Resequencer ( # of worker threads )
ii. Database
1. Audit Level
2. Parallel Routing (# of rows that are fetched by each thread per iteration )
3. Resequencer (# of Groups that are locked by each thread at a time )
iii. CPU
1. Metrics Level
2. Sleep intervals before next polling
d. Database Adapters
i. Concurrency
1. # of worker / Poller / Dequeue threads
ii. Database
1. # of rows to be processed per transaction (MaxTransactionSize)
2. # of file records to be processed (MaxRaiseSize)
3. Collect stats on relevant tables
4. Large files
iii. CPU
1. Process design
2. IO
3. # Threads at the application server level
B. SOA Infrastructure Level
a. Database
i. Audit Level
ii. Purging
b. CPU
i. Payload Validation
C. Generic
a. Operating System
b. JVM
i. Heap Size
ii. Nursery Size
iii. GC Algorithm
iv. Use Large pages
v. 64 bit vs 32 bit
c. Database
i. SOA & Application Schema tuning
ii. Tuning Parameters
iii. Redo Logs
d. WebLogic Application Server
i. Production Mode
ii. Connection Pooling
iii. Logging
iv. Self tuning
Saturday, March 20, 2010
Thursday, March 18, 2010
Subscribe to:
Posts (Atom)
