1 / 28

JMS in der Praxis

JMS in der Praxis. Stefan Kischel Product Manager. Messaging = MOM (Message Oriented Middleware). Application-driven Messaging Within or across systems. Application A. Application B. Message Server. Messaging API. Messaging API. M. Messaging Client. Messaging Client. M.

eithne
Download Presentation

JMS in der Praxis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. JMS in der Praxis Stefan Kischel Product Manager

  2. Messaging = MOM(Message Oriented Middleware) Application-driven Messaging Within or across systems Application A Application B Message Server Messaging API Messaging API M Messaging Client Messaging Client M Networking Stack Networking Stack Networking Stack Point-to-Point (11) - Or - Publish and Subscribe (1Many)

  3. Building Distributed Applications A New Landscape • Internet B2B applications and services • Creating the global enterprise • Disparate systems acquired via mergers and acquisitions • Increase of disconnected users • Handheld, mobile • Growth of embedded systems

  4. Building Distributed Applications • Potential for explosive success • High-performance, massive scalability • Built on most common Internet protocols  TCP and HTTP • Heterogeneous (multi-company, multi-vendor) • Standard interfaces and data formats  JMS and XML • Comprehensive security, encryption and firewall support • Diversity in application styles and devices • Flexible Topology: 11and 1Many • Wide range of platforms & mobile devices  100% Java • Highly distributed, unpredictable environment • Fault-Resilient with guaranteed delivery and QoS • “Loosely Coupled” communications architecture

  5. Building Distributed Applications Limitations of Current Technology • Not optimized for the Internet • No support for disconnected users • Proprietary systems over private networks • Unwieldy and inflexible • Large footprint • Limited support for standards

  6. Frequent Limitations of current Technologies* • Forces “tightly coupled” synchronous model • Not designed for the Internet or firewalls • Inflexible & cumbersome • No guaranteed delivery • Large “footprint” & not easily embedded • Difficult to maintain or administer • No support for intermittent or mobile clients • No explicit support for XML * e.g., CORBA, COM, RPC or RMI, Native Sockets, Custom Programming on HTTP, or Proprietary Middleware

  7. Today’s Religious Dividefor the Underlying Communications Architecture Tightly Coupled Loosely Coupled Client/Server B2C B2B B2C EAI Integration Brokers Application Servers Asynchronous Synchronous Choices: Messaging Favored for distributedInternet applications& Enterprise Integration Choices: CORBA, COM, RMI, RPC& Messaging Favored for traditional Enterprise applications& simple web apps

  8. Enter ... Java Messaging • Service allowing Java-based applications to communicate • Two models: • Publish and Subscribe (1Many) • Messages passed between publishers and subscribers via topics • Point-to-Point (11) • Messages passed between senders and receivers via queues

  9. Java Messaging Service (JMS)The Only Industry Standard for Messaging • Developed and maintained by Javasoft • Standardized since 1998 • A way for Java programs to interact • Embraced within J2EE specification • An API and set of semantics • A common programming framework for: • Point-to-Point (PTP) • Publish & Subscribe (Pub/Sub)

  10. Messaging Models Point-to-Point (11) Queue Sender Receiver Sends message to a Queue Queue = “Location” for the messages of a given type Only one client receives the message, (but several receivers may share load) Publish & Subscribe (1Many) Subscriber(s) Topic Publisher Posts messages to a Topic Topic = “Subject” of communication Available to “registered” participants Each receive messages on topics to which they register

  11. Publish & Subscribe Publisher Topic Subscriber New Flavor Price Increase

  12. Point-to-Point Sender Queue Receiver Can Send Sausages Can Send Potatoes

  13. How is Messaging Being Used? • “E-Tail” • Supply Chain Management • Workflow Management • Data Dissemination / Integration • Distributed monitoring • Enterprise Application Integration

  14. E-Tailer:Business to Consumer Message 1:“Product Order” Consumer E-Tailer Message 2:“Credit Check” Message 3:“Credit OK” Credit Bureau

  15. Supply Chain Management:Wholesalers and Retailers Message 1:“Item on Sale” Wholesaler Chain Retailer Small Retailer Message 2:“Place Order” Wholesaler

  16. Workflow Management:Mobile Loan Processors Loan Agent A Message 1:“Loan Request” Mortgage Company Message 3:“Need More Info” Message 2:“ Loan Approved” Loan Agent B

  17. Limitations of the JMS Standard It Does Not Address • Security • Load Balancing • Fault Tolerance • Error Notification • Administration • Repositories • XML Support • Wire Protocols It Does Not Require • Support for Both Messaging Models • Transaction Support • Asynchronous Reply • Naming Conveniencesfor Topics & Queues • 100% Java

  18. SonicMQMessaging for Next Generation Internet Centric Applications ...Get the Message!

  19. SonicMQ:Many Applications Exchanges& Auctions New Internet Services New CollaborativeCommunication Real-timeBusiness Info Distributed E-tail On-lineReservations Reliable “Push” WorkflowAutomation Web SiteManagement Mission CriticalMonitoring CRM & SCM Traditional Enterprise Fast Data&ObjectReplications EAI SonicMQ

  20. SonicMQ Feature SummaryFull Implementation of JMS Standard and More • MESSAGE BROKER • Transaction Support • Security • Message Persistence • QoS Delivery • Asynchronous Reply • Abstraction of • Communications Java Clients • Broker Clusters ActiveX Clients C++ Clients • ADMINISTRATION CLIENT • Command Line & GUI • Remote access 100% Java • TOPICS & QUEUES • PTP & Pub/Sub • XML Messages • Durable Subscribers • Hierarchical Name • Spaces • Client Push • Subject-based • Addressing

  21. SonicMQ ArchitectureScalability & Flexibility via Clustering C/C++Client* Admin Client *Future ActiveX Client JMS Client Distributed Broker Cluster Broker Broker Queue Topic Broker Topic

  22. SonicMQ Delivers: Speed & Scalability The highest performance for “Loosely Coupled” Internet applications B2B B2C EAI Integration Brokers SonicMQ TCP/IP or HTTP

  23. SonicMQ Delivers:Reliability The guaranteed delivery & security for business critical services & transactions SonicMQ Roll-back of Whole Sets of Messages SSL Authentication Persistent Messages 40 and 128 BitEncryption Durable Subscriptions

  24. SonicMQ Delivers:Flexibility The right kind of flexibility for today’s diverse Internet environment SonicMQ XML Message Type Choice of Client API(Java, ActiveX, C/C++, more) Pub/Sub &Point-to-Point Choice of Databasewith JDBC QoS Delivery Optionsand “Firewall Tunneling”

  25. SonicMQ Delivers:Ease of Use and Low TCO* The only product designed to be “built-in”to new Internet centric applications SonicMQ Remote Administrationover the Internet Subject-based and Hierarchical Addresses Small “Footprint”& Easy Install Embedded Database Included Abstraction of Communication Layer *TCO= Total Cost of Ownership

  26. SonicMQ Product Line • SonicMQ Developer Edition • Single broker, 5 clients • Supported on WinNT only • SonicMQ Small Business Edit. • Single broker, 50 clients • Includes first year support • SonicMQ Enterprise Edition • Clustered brokers no client limitations

  27. SonicMQ Customer Success Reference Accounts to Date • IONA • GemStone • SAG America

More Related