Your SlideShare is downloading. ×
  • Like
Top 6 goals - Evangelism
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Top 6 goals - Evangelism

  • 514 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
514
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
11
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Slide Purpose: Introduction Slide Main message(s): Introductions This presentation is a overview of the challenges faced by organizations today, and how Service-Oriented Architectures and the Enterprise Service Bus address these challenges.
  • O’Reilly has published a book by Richard Monson-Haefel and SonicMQ’s Dave Chappell entitled “Java Message Service”. Aside from the JMS specification, it is the most comprehensive document on the market that covers all the intricacies of JMS.
  • For more information about how SOAP, JAXM, ebXML, and JMS complement each other, please refer to chapter 7 of this book – due out end of November 2001.
  • Slide Purpose: Introduce Sonic as a standards leader. Main message(s): Standards support is critical for your business. Sonic is driving and supporting industry standards. Factoid: Sonic Software is 1 of 36 Authorized J2EE Licensed companies( Feb 2002) Factoid: SonicMQ is the first message oriented middleware to pass J2EE 1.3 certification- which is over 14,000 individual tests! Today, it is imperative that applications be built using standards, so you can maximize your IT investment. Our products have an open and flexible architecture using industry standards. Why is standards support important? This means that you are not locked into a single vendor – you can pick best-of-breed solutions, e.g. the best J2EE AppServer and the best JMS Messaging Solution. You do not need to subscribe to a “one-size-fits-all” approach, which may be both expensive and not completely meet your needs. Standards support enables seamless interoperability between applications, minimizes coding efforts and improves quality. Sonic Software drives several standards, e.g. JMS, Web services, JAXM, JCA– we are an Expert Group Member on several of the Java Specification Request (JSR) efforts within the Java Community Process. Sonic Software (through their parent Progress Software) is a member of the W3C – XML Schema committee. Sonic participates in the OASIS ebXML Messaging Technical Committee and the Joint Committee. Overall, Sonic Software’s role in defining standards translates into your applications being more “plug-and-play”.
  • Slide Purpose: High level overview of Sonic Software Main message(s): Sonic is entrepreneurial and has strong financial backing. (not an unstable Dot Com startup) Sonic Software was established in 1998 with funding and resources from parent company, Progress Software. Progress Software is a recognized 20 year veteran and leader in the development tools, middleware and database markets. This environment offers Sonic Software the best of both worlds – Sonic Software is a focused, energetic, entrepreneurial company and has long term financial stability from PSC With this focus, Sonic Software has become the # 1 JMS and #1 OEM embedded Message Oriented Middleware. As enterprise customers require enterprise support, Sonic Software provides 24x7 worldwide support with offices in USA (Bedford, MA HQ), EMEA (Netherlands), and Asia Pacific (Australia).
  • Slide Purpose: High level example of Messaging Main message(s): Here we apply the JMS concepts that we have just discussed an applied them to a distributed application infrastructure which LINKS: HEAD OFFICE Regional Office Trading Partner Marketplace (which has a trading partner) <click> Here we see how these entities can be linked using a JMS which provides: Ability to do synchronous or asynchronous communication Use point-to-point or pub sub model Brokers allows easy and flexible integration Reliability Fault-tolerance
  • JMS is simply an API and a set of semantics that define how JMS-based clients access the facilities of an enterprise messaging product. It was introduced by Javasoft in 1998 as part of an industry effort to standardize messaging requirements. The JMS specification was an industry effort based on the messaging vendors that were around at the time. The intent was to create a standard set of APIs and message delivery semantics. However, the intent changed over the course of the work to create a specification for a first class middleware in its own right, on equal footing with RPC-like technologies such as CORBA and RMI. The net result is not a least-common-denominator approach, but a rich set of APIs and semantics that cover a “best-of” conglomeration of all the messaging products that have existed over the past decade. “ Message Delivery Semantics” include definitions for: guaranteed delivery of messages through asynchronous store and forward mechanisms. A range of delivery modes Once-and-only-once delivery, which means that regardless of the deployment topology, or vendor specific architecture, that Purchase Order is guaranteed to get there once, and only once. The other range of the spectrum is at-most-once. The example most often used is that of a stock ticker broadcast What the specification does not address is: Load balancing/fault tolerance Error/Advisory notification Administration Security
  • JMS is simply an API and a set of semantics that define how JMS-based clients access the facilities of an enterprise messaging product. It was introduced by Javasoft in 1998 as part of an industry effort to standardize messaging requirements. The JMS specification was an industry effort based on the messaging vendors that were around at the time. The intent was to create a standard set of APIs and message delivery semantics. However, the intent changed over the course of the work to create a specification for a first class middleware in its own right, on equal footing with RPC-like technologies such as CORBA and RMI. The net result is not a least-common-denominator approach, but a rich set of APIs and semantics that cover a “best-of” conglomeration of all the messaging products that have existed over the past decade. “ Message Delivery Semantics” include definitions for: guaranteed delivery of messages through asynchronous store and forward mechanisms. A range of delivery modes Once-and-only-once delivery, which means that regardless of the deployment topology, or vendor specific architecture, that Purchase Order is guaranteed to get there once, and only once. The other range of the spectrum is at-most-once. The example most often used is that of a stock ticker broadcast What the specification does not address is: Load balancing/fault tolerance Error/Advisory notification Administration Security
  • Slide Purpose: Relate to previous MOM slide on how JMS fits in Main message(s): JMS is conceptually just like MOM Here, we take the messaging middleware components we talked about earlier and relate them to the terms used to describe each as defined in the JMS specification. 3 PARTS: API: There is a standardized API that you call from your Java-based application, which in turn calls …. CLIENT: JMS client , which contains messaging logic, recovery, and security mechanisms. BROKER: The JMS Broker , is responsible for: - gathering requests - queuing the requests - ensuring they arrive.
  • NOTE: This is a build slide. The JMS specification identifies 5 basic message types that address the majority of the requirements of applications today. These message types are: Bytes message – a message that contains a stream of uninterrupted bytes. Map message – a message whose body contains a set of name-value pairs where names are Strings and values are Java primitive types Object message – a message that contains a Serializable object Stream message – a message whose body contains a stream of Java primitive values Text message – a message whose body contains a java.lang.String <next build> SonicMQ extends the JMS Text Message object to create an XML Message type. This message type simplifies the processing of an XML-formatted message by allowing it to be represented as a DOM (document object model). Sun is considering revising the JMS specification to include XML as a separate message type.
  • SonicMQ provides different Quality of Service (QoS) support depending on the needs of the application. In the case of where you want to protect the messaging environment from the event of hardware failure, it is advised to use persistent messaging. This diagram shows the steps taken in the publishing of a message in a persistent manner. The JMS client (producer) uses the publish method to publish a message on a topic of interest. It’s the client that specifies whether the message is sent to a topic or queue persistently as part of the JMS properties in the message header (JMSDeliveryMode). In this case, the message is written to the persistent store before acknowledgement is sent back to the client indicating that the message was successfully received. If in the event that the server should go down during the process of receiving and storing the message, the message is considered undelivered by the client. This is especially powerful when you use clustered servers. If a client did not receive acknowledgement of receipt of the message, it will attempt redelivery to that server or another server in its static routing table. Acknowledgement doesn’t necessarily mean that the message was delivered to its final destination. Once the server acknowledges receipt of the message, the client is alleviated of any further responsibility. It is then up to the SonicMQ server and it’s facilities to ensure reliable guaranteed delivery from that point forward. When the server recovers from a failure, any persistent undelivered messages will then be delivered to their intended recipients.
  • This diagram shows 2 transacted messages; one on the producers side and one on the consumer’s side. From the producers side, transacted messages sent to the server must be followed by a commit() method call from the client. It’s only at that point that the server will acknowledge and process the messages. The client can also chose to rollback() the message at any point. The server will not process anything sent within the bounds of the transaction. The same is true for the receipt of message on the consumer’s side. Transaction scope are not limited to just to sending or receiving messages individually. A transacted messages can include many send and many receipts of messages as a single unit of work. As these are not considered “database” transactions, there is no requirement for a transaction monitor to be used.
  • The vendors could be the EIS vendors themselves
  • Slide Purpose: Show example of service-centric view Main message(s): <This is meant as a quick supporting graphic – not a detailed discussion> With a service centric view – services are talking to applications and other services.
  • Slide Purpose: Introduce concept of Service-oriented Architecture Main message(s): Business systems today, however, are being constructed by tying together reusable logic components. Thus, instead of duplicating code, existing systems are being exposed as services for other systems to consume and new processes are being created that cross multiple applications. They are: loosely-coupled -meaning that services can operate on their own as well as with each other when they need to; can communicate asynchronously, so senders and receivers are not dependent on the availability of each other; and are coarse-grained-meaning that they are a collection of higher level processes. A service-oriented architecture is a design to reuse components in this manner and can be distributed across an internal network or the Internet. Web services, simply put, are software as a service over a network. You are probably very familiar with some basic “services over the web” such as a Stock Quote (I.e. send a Ticker Symbol to a system, and get the current price), or using the UPS online tracking system -it will send to you the status of your package. Web services are considered an implementation of a Service-Oriented Architecture. The primary concept here is investment protection in your current technology. Even without Web services, all companies should be architecting building SOA today.
  • Clients use JAXM, JAX-RPC, ApacheSoap, Axis, or .NET Send SOAP messages through the internet over HTTP Map SOAP messages to the JMS enterprise message bus Use J2EE CA to Connect to EIS/legacy apps Use MDB to call into EJB server when necessary

Transcript

  • 1. Using Message-Driven Beans in a Service-Oriented Architecture
    • Dave Chappell
      • VP & Chief Technology Evangelist, Sonic Software
  • 2.  
  • 3. O’REILLY
  • 4.  
  • 5. Tell Them About the Book Raffle
  • 6. Sonic Software
    • 1st J2EE 1.3 Certified MOM!
    • HTTP(S), XML, SOAP, WSDL, JMS, JCA
    • Java Message Service (JMS)
    • Apache Axis
    • Web services, JAXM, J2EE CA
    • XML Schema
    • ebXML
    • WS-I
    Driving Industry Standards
  • 7. SonicMQ AppServer Integration
    • Borland Appserver
    • HP/Bluestone Total-e-server
    • BEA Weblogic
      • CMT,Clustering, Failover/Reconnect, Design Patterns
    • IBM WebSphere
    • Oracle Appserver
    • MacroMedia
    • JBoss (soon)
  • 8. Sonic Software
    • Recognized: Enterprise messaging Integration middleware
    • Established: Over 500 of Global 2000 rely on Sonic Software
    • Strong Independent operating company of Progress Backing: Software Corp. (NASDAQ: PRGS) $170M cash, no debt Distribution in 65 countries, 24x7 world-wide support
    • History: SonicMQ released 12/1999, #1 JMS product Today SonicMQ 4.0, SonicXQ 1.0 Enterprise Service Bus
  • 9. Agenda
    • J2EE Message Driven Topology
    • JMS Overview
    • Using JMS With EJBs
    • JMS and XA Integration
    • J2EE Connector Architecture
    • Service Oriented Architectures and Web Services
  • 10. J2EE Topology EJB Containers Web Containers JSP servlet servlet JSP servlet EJB html gifs jpegs xml Presentation Logic Business Logic xml EIS Database EJB EJB EJB EJB EJB EJB EJB EJB Internet
  • 11. J2EE Topology – Message Driven Web Containers servlet servlet JSP gifs jpegs html Presentation Logic Business Logic EIS Database JMS Internet EJB Containers EJB EJB EJB MDB MDB MDB EJB Containers EJB EJB EJB MDB MDB MDB
  • 12. J2EE Topology – Message Driven EJB Server EJB Server EJB Server Broker EJB Server EJB Server EJB Server Broker Business Partner Trading Partner Broker EJB Server EJB Server Broker Regional Office Business Partner Head Office
  • 13. Agenda
    • J2EE Message Driven Topology
    • JMS Overview
    • Using JMS With EJBs
    • JMS and XA Integration
    • J2EE Connector Architecture
    • Service Oriented Architectures and Web Services
  • 14. Java Message Service (JMS)
    • Sun standard
    • Common APIs
    • Loosely-coupled asynchronous processing
      • Senders and receivers abstractly decoupled from each other
      • Destinations administratively configurable at runtime
    • Point to Point and Pub/Sub messaging models
    • Supports synchronous or asynchronous communication
  • 15. Java Message Service (JMS)
    • Message delivery semantics
      • Guaranteed Once-and-only-once
      • At-most-once
    • Deployment architecture not addressed by specification
      • Vendor differentiators
  • 16. Java Message Service Business Application A JMS Messaging API JMS Messaging Client … standards based API… Messaging Components Business Application A JMS Messaging API JMS Messaging Client JMS Provider
  • 17. Broad Range of Message Types BytesMessage Message MapMessage ObjectMessage StreamMessage TextMessage Included in JMS Specification XMLMessage Extensions in SonicMQ MultiPartMessage
  • 18. JMS Messages Message Header Properties Body Used to identify and route the message The actual “payload” of the message (five different types, plus XML and Multipart for SonicMQ) Support application-specific values passed with the message
  • 19. JMS Reliability JMS Provider Publisher Subscriber Persistent Store 7. publish() method returns 2. Disconnect 5. Message retained in persistent store Persistent messages and durable subscriptions 1. Subscribe 6. Ack 8. Connect 10. Receive 4. Persist 3. Send 9. Retrieve
  • 20. JMS Reliability JMS Provider Consumer Producer Transactional Message Send and Receive 1. Send 3. commit() 2. Send 4. Receive 6. commit() 5. Receive
  • 21. JMS Reliability JMS Provider Producer XA Compliant Transaction Manager External Resource (DB/EJB) commit() rollback() 1. Send 2. Update
  • 22. Filtering with message selectors Message Server Publisher Departments.Sales Subscriber Departments.Sales Pipeline > 15000 JMSPriority = 2 Pipeline = 20000 delivered Subscriber Departments.Sales JMSPriority > 5 not delivered Subscriber Departments.Sales JMSPriority >= 2 AND Pipeline > 10000 delivered Subscriber Departments.Sales Pipeline > 20000 not delivered
  • 23. JMS as a J2EE Resource
    • 2 Requirements to access a Message Provider
      • ConnectionFactory
        • Creates connection to JMS providers
      • Destination Object
        • The Specific Topic or Queue
  • 24. Obtaining the ConnectionFactory
    • Resource Manager Connection Factories as Administered Objects
      • Specify standard mechanism for getting connections to resources outside the J2EE component
      • Enables the container to do pooling
    • JNDI is used for maximum portability
    QueueConnectionFactory qcf = (QueueConnectionFactory) ctx.lookup("java:comp/env/jms/TrafficConFactory");
  • 25. Accessing the Destination
    • The Specific Queue or Topic
    • Retrieved via JNDI
      • Specified in the Deployment Descriptor
      • Binding to a real Destination done at deploy time
    Topic traffic = (Topic) ctx.lookup("java:comp/env/jms/TrafficTopic");
  • 26. What the Java/API looks like // Create a connection factory TopicConnectionFactory factory; factory = (TopicConnectionFactory)jndi.lookup("TopicConnectionFactory"); // Create a connection connect = factory.createTopicConnection (username, password); // Create a session session = connect.createTopicSession(true, Session.AUTO_ACKNOWLEDGE); // Create a topics. Topic topic = (Topic)jndi.lookup(" chat ");
  • 27. What the Java/API looks like // Create Subscriber to application topics. TopicSubscriber subscriber = session.createSubscriber(topic); // Initialize the onMessage() message handler. subscriber.setMessageListener(this); // Create a publisher publsher = session.createPublisher(null); // Topic will be set for each reply // Now setup is complete, start the Connection connect.start();
  • 28. What the Java/API looks like public void onMessage( javax.jms.Message message){ TextMessage textMessage = (TextMessage) message; System.out.println(textMessage.getText()); } -- OR – ... while( true ){ textMessage = (javax.jms.TextMessage)qReceiver.receive(1000); ...
  • 29. Break
  • 30. Do the Book Raffle
  • 31. Agenda
    • J2EE Message Driven Topology
    • JMS Overview
    • Using JMS With EJBs
    • JMS and XA Integration
    • J2EE Connector Architecture
    • Service Oriented Architectures and Web Services
  • 32. EJB Design Pattern Reminder create lookup remove client Remote interface stubs home object context bean Server provides resource mgmt Container methods Deployment Descriptor Automatically invokes services based on requirements defined in deployment descriptor create lookup remove methods
  • 33. MessageDrivenBean EJB Container Publisher Bean EJB Container Subscriber Msg-driven Instance Database Durable Subscription Client App Publishes Acknowledges Delivers Stores
  • 34. MessageDrivenBean
    • Defined in EJB 2.x Specification
    • Benefits
      • Simple to write
      • Allow for asynchronous execution
    Container Msg-driven Bean Class JMS Provider Destination Msg-driven Bean instances Consumer
  • 35. MessageDrivenBean
    • Executes on receipt of a JMS message
      • javax.jms.MessageListener interface
    • Shares the following characteristics of stateless session bean
      • Is stateless and relatively short- lived
      • Security
      • Transactions
      • Concurrency
      • Management
      • All the other services that EJBs enjoy!
      • Notable difference: No home or remote interface
  • 36. MessageDrivenBean Interface
    • javax.ejb.MessageDrivenBean
      • ejbCreate(), ejbRemove()
      • setMessageDrivenContext()
    • Just like a usual javax.jms.MessageListner
      • onMessage(javax.jms.Message)
  • 37. MessageDrivenContext
    • get/setRollbackOnly()
    • getUserTransaction()
      • For BMT only
    • Others inherited from EJBContext Interface, but not allowed:
      • getCallerPrincipal()
      • isCallerInRole()
      • getEJBHome(), getEJBLocalHome()
  • 38. Serialization and Concurrency
    • Container Must Serialize all calls to an MDB
      • ejbCreate(), ejbRemove(), etc
      • No need to be coded as re-entrant
    • Concurrency
      • Container May Launch Multiple Instances of an MDB
        • No guarantee of order
        • “ Cancellation” Message May Arrive Before “Reservation” Message
  • 39. MDB Example
    • public class SubscriberMsgBean implements MessageDrivenBean {
    • <… define ejbCreate(), ejbRemove() and
    • setMessageDrivenContext( MessageDrivenContext mdc) .. >
    • MessageDrivenContext mdc = null;
    • public void onMessage( Message inMessage) {
    • TextMessage msg = (TextMessage) inMessage;
    • try {
    • < look up JDBC database >
    • < store info from message in database >
    • } catch( Exception e) {
    • mdc. setRollbackOnly();
    • }
    • }
    • }
  • 40. MDB Example – Deployment Descriptors
    • <message-driven>
    • ...
    • <ejb-class>SubscriberMsgBean</ejb-class>
    • <transaction-type>Container</transaction-type>
    • <jms-message-selector>
    • N ewsType='Metro/Region‘
    • </jms-message-selector>
    • <message-driven-destination>
    • <jms-destination-type>
    • javax.jms.Topic
    • < /jms-destination-type>
    • <jms-subscription-durability>
    • durable
    • </jms- subscription-durability>
    • </message-driven-destination>
    • ...
    • </ message- driven>
  • 41. MDB Example – Deployment Descriptors
    • <weblogic-enterprise-bean>
    • <ejb-name>QueueMessageDriven</ejb-name>
    • <message-driven-descriptor>
    • <pool>
    • <max-beans-in-free-pool> 20 </max-beans-in-free-pool>
    • <initial-beans-in-free-pool> 1 </initial-beans-in-free-pool>
    • </pool>
    • <destination-jndi-name> sonicQueue </destination-jndi-name>
    • <initial-context-factory>
    • com.sun.jndi.fscontext.RefFSContextFactory
    • </initial-context-factory>
    • <provider-url>
    • file://localhost/C:/temp/jndi/fileStore/
    • </provider-url>
    • <connection-factory-jndi-name>
    • myJMSxaqcf
    • </connection-factory-jndi-name>
  • 42. Agenda
    • J2EE Message Driven Topology
    • JMS Overview
    • Using JMS With EJBs
    • JMS and XA Integration
    • J2EE Connector Architecture
    • Service Oriented Architectures and Web Services
  • 43. Distributed Transaction Processing (DTP)
    • TM
    RM RM RM XA XA XA
    • TM
    RM RM RM RM XA XA XA
    • TM
    RM RM
    • TM
    RM RM RM XA XA XA
    • TM
    RM RM RM XA XA XA
  • 44. A local instance of a DTP system
    • TM
    • JMS Client
    RM RM
  • 45. Local DTP zoom in EJB Application Server SonicMQ Client JMS Provider Transaction Manager JMS Client JMS XA API XA Resource
  • 46. XA interfaces
    • JMS XA SPI
      • XAConnectionFactory
      • XAConnection
      • XASession
      • XAQueueConnectionFactory
      • XAQueueConnection
      • XAQueueSession
      • XATopicConnectionFactory
      • XATopicConnection
      • XATopicSession
  • 47. Agenda
    • J2EE Message Driven Topology
    • JMS Overview
    • Using JMS With EJBs
    • JMS and XA Integration
    • J2EE Connector Architecture
    • Service Oriented Architectures and Web Services
  • 48. J2EE Directions
    • J2EE 1.3
      • Web Applications
      • Asynchronous
        • JMS
        • MDB
      • EJB 2.0
    • J2EE 1.4
      • SOA Platform
      • Web Services
        • JAX-RPC
        • JSR-109
      • J2EE Connector Architecture
      • EJB 2.1
        • WSEI
  • 49. J2EE Connector Architecture Overview
    • Defines standard for connecting J2EE to enterprise information systems (EIS)
    • System contracts define interface specification with EIS
      • Connection, Transaction, Security
    Enterprise Information System Resource Adapter Application Server or EAI Framework System Contract EIS Interface
  • 50. J2EE Connector Architecture Overview
    • Resource adapters
      • Implements the EIS side of the system contracts
      • System-level software drivers for connecting to an EIS
      • Enables vendors to create standardized connectors to EIS
    • Common client interface
      • Standard API for applications to interact with heterogeneous EIS
    Enterprise Information System Resource Adapter Application Server or EAI Framework System Contract EIS Interface
  • 51. Inbound Communication Model Resource Adapter JMS Destination Enterprise Java Beans Work Mgmt JMS Disp EJB Disp JCA Container WorkManager Connection Pool Manager Transaction Manager Security Manager
  • 52. Agenda
    • J2EE Message Driven Topology
    • JMS Overview
    • Using JMS With EJBs
    • JMS and XA Integration
    • J2EE Connector Architecture
    • Service Oriented Architectures and Web Services
  • 53. Service-Oriented Architecture Global Enterprise Internet Web Service Credit Check Web Service Supplier Fulfill Service Web Service Invoicing Service Sales Service Special Orders Order Processing Regional Sales Partner App Inventory Lookup Customer App Partner App Check Inv Service Order Entry Service
  • 54. Service-Oriented Architectures (SOA)
    • System design methodology using existing application components
    • Applications expose functionality through service interfaces
      • Loosely-coupled, asynchronous, coarse-grained
    • Distributed across internal networks or the Internet
    • Web services
      • Software services built on standards: SOAP, WSDL, UDDI, XML, HTTP
    Architecture for a Distributed World
  • 55. Web Services Technology Stack Publication and Discovery (UDDI, ebXML Registry) Description Language (WSDL) Data Formatting (XML Dujour) Transport (HTTP, SMTP, TCP/IP) XML-RPC (SOAP-RPC, JAX-RPC) XML Messaging (SOAP, ebXML,JAXM)
  • 56. Web Services Technology Stack XML-RPC (SOAP-RPC, JAX-RPC) XML Messaging (SOAP, ebXML,JAXM) Publication and Discovery (UDDI, ebXML Registry) Description Language (WSDL) Data Formatting (XML Dujour) Transport (HTTP, SMTP, TCP/IP) Quality of Service JMS, ebXML-MS, HTTPR
  • 57. Connecting (Web) Services Together
    • (Web) Services aren’t Islands of Themselves
    • Network of Cooperative Services
    • Interfaces, Discovery, and Data Formats are only part of the big picture
      • Data transformation
      • Intelligent Routing based on content
      • End-to-end guaranteed delivery
      • Management, configuration, and auditing
      • Performance and scalability
      • Asynchronous and synchronous messaging
      • Security
      • Deployment tools
    What Else Do You Need?
  • 58. Standards Working Together... JAXM/RPC Client Apache Client Servlet Container .NET SOAP Client SOAP/HTTP Web Client SOAP/HTTP SOAP/HTTP SOAP/HTTP Internet JMS Messaging Backbone SOAP/HTTP SOAP/JMS SOAP/HTTP SOAP/JMS SOAP/HTTP SOAP/JMS JCA/EIS EJB Container JMS Client C++ Client JCA/EIS JMS message JMS message JMS message JMS message
  • 59. Contact Information
    • [email_address]
    • http://www.sonicsoftware.com
    Integrate with Ease. Extend at Will TM .