BeePlex Version 1.0

A hub for integrating all your ZigBee nodes from the furthest edge of your RF network to any server or process within your enterprise infrastructure.

BeePlex is an Event Driven Architecture (EDA) that provides an extremely modular and flexible system for making the data collected in your ZigBee mesh networks readily available and accessible to your organization's internal procedures and processes. BeePlex has an adaptive architecture that uses a message bus and XML messaging so that you can easily implement rich workflow and process flow scenarios. Reliable store-and-forward messaging guarantees delivery of events and ensures that your system is robust. Because BeePlex provides you with an inherently decoupled architecture, it gives you unparalleled flexibility and component reuse. Incremental development of your integration solution is greatly facilitated by our discrete "building blocks". BeePlex is quick and easy to deploy and allows for the versioning and retirement of service components.

BeePlex features all the tools necessary to run a mission critical Service Oriented Architecture (SOA) including security, centralized management, built in monitoring and fail-over capabilities in addition to extensive statistical reporting.

Event Driven Architectures (EDAs)

An Event Driven Architecture (EDA) is an Open Standard software integration framework that uses reliable messaging and intelligent routing to connect totally decoupled and highly distributed service instances in a robust, highly (HA) available and flexible way. Each service is like a wrapper for application adapters, data repositories, legacy systems, gateways or any other enterprise function that you, as an information technologist or executive, need to interconnect with your ZigBee network. Using a service wrapper allows us to present a unified interface to other enterprise services across highly distributed and heterogeneous topologies. In an EDA, services communicate using an event driven model that makes integration modular, efficient, flexible and orderly.

SolutionsWorks pioneered the concept of a ZigBee EDA with its groundbreaking Java product, BeePlex. Our development team collectively had decades of systems integration experience in the field before even a line of code was written. Their collaboration produced one of the most powerful and appropriate solutions to the problem of integration that has appeared in the market to date. Our intimate understanding of what works in integration and what doesn't, garnered from many years of practical experience with messaging and integration brokers, was crystallized into our EDA. The result is a uniquely elegant solution to the problems that have traditionally plagued attempts to unify disparate systems. Our software products and methodology is equally appropriate for implementing your workflow scenarios, process integration, process automation and systems integration.

What is a Service Oriented Architecture (SOA)?

The concept of SOAs dates back almost a decade, having their origins in DCOM and Object Request Brokers like CORBA. Their evolution can be traced to the difficulties that arose when organizations tried interconnecting the fragmented systems that resulted from the wave of downsizing and migration away from monolithic mainframes that occurred in the late eighties and early nineties. The first serious attempts at addressing the problem came in the form of store-and-forward messaging systems like DEC's DecMessageQ and IBM's MQSeries. That was progress of a sort, but the success of point-to-point messaging pipes soon became their weakness as they very quickly became unmanageable tangles of "integration spaghetti". One of the lasting legacies that was salvaged from this era were the successful concepts of assured delivery through two-phase commit protocols and the realization that message translation and machine and operating system architecture independence were best achieved with the use of some form of messaging layer.

What became obvious was that the task of untangling the knot of integration spaghetti needed to be addressed by formalizing and homogenizing message exchanges in an organized manner. Thus arose the concept of the centralized "Integration Broker" in the late nineties.

Centralized integration brokers had many advantages - they forced applications to conform to rules-of-exchange, they introduced the concept of application adapters that could wrapper applications so that they could all communicate using the same "language" of exchange. Before integration brokers even really had time to mature their shortcomings were becoming well known. They were expensive, they used proprietary standards that locked the customer in to a specific vendor, and whereas messaging systems created "integration spaghetti," centralized brokers soon garnered their own internal rules and process "spaghetti" that, albeit centralized, introduced top-heavy, process-bound systems that had no clear strategy for scaling or performance improvement. Reuse was low or non-existent. Though some attempts were made to correct these defects, centralized brokers never really successfully demonstrated scalability or high availability features and were always prone to be "hot spots" and single points-of-failure in an enterprise.

What eventually came to the rescue a few years ago was a technology that had been lurking in the background since the first store-and-forward messaging systems - the concept of broadcast or publish/subscribe (pub/sub) messaging. Though almost as old as point-to-point messaging systems, pub/sub technologies were just becoming popular when the public Internet revolution broke onto the scene after 1996 and their potential was forgotten in the rush to the Web. When the Internet hype eventually settled down the industry returned to the original challenges facing integration, which were now exacerbated by the plethora of three-tier architectures that had grown up to service the Web. Serendipity now stepped in with the fortuitous convergence of three technologies: Java, XML and pub/sub. The result was the concept of the ESB.

What is an Enterprise Service Bus (ESB)?

An ESB is a framework that unifies messaging, web services, data transformation and translation into a loosely coupled or completely decoupled architecture.

Java provides the means to achieve platform independence. XML is the industry standard format for achieving data portability. Java's specified messaging interface is the Java Messaging Service (JMS) and the JMS specification mandates the inclusion of pub/sub messaging. Using the concept of pub/sub, services can be decoupled so that they are independent of each other. The result is architecture with unparalleled flexibility and extensibility.

This neat package of Java, XML and pub/sub work together so that the entire integration infrastructure in your organization (or even just a small island within it) can be organized into abstraction layers that drastically simplify the task of achieving highly available, robust, scalable and feature-rich solutions that can cut costs and boost project delivery schedules.

Conceptually the highly abstracted layered architecture of the SolutionsWorks ESB can be represented as illustrated in the diagram above.

The important points to note are:

• The system is highly modular. Reusability of components is high.
• Components communicate via dynamic discovery at runtime.
• Communication is abstracted using pub/sub "topics" - analogous to TV Channels or broadcast radio stations. The transmitters of information have no specific knowledge of the receivers.
• Services can be added incrementally, unobtrusively substituted or removed (e.g. "hot-updates").
• Services can share subscriptions - this allows you to replicate identical instances of a service so that you can scale up for performance (through workload balancing) or you can improve systems availability (through redundancy).
• The details of message routing and delivery are abstracted away into the messaging layer "plumbing" so that message consumers and producers are relieved of the underlying details of a message exchange.

What can BeePlex do for me?

• It allows you to integrate your ZigBee RF networks into your wider infrastructure.
• BeePlex allows you to organize data consumed and produced by ZigBee devices into a logical hierarchy of abstract schemas which greatly simplifies intercommunication.
• BeePlex simplifies integrating heterogeneous platforms across your enterprise with your ZigBee networks and other distributed devices.
• It allows you to do selective deployment.
• You can extensively reuse stock services (like database and application adapters) or custom components that you create (like message filters, message pre-processors, message post-processors, custom event handlers, triggered actions, templates, message transformers etc.).
• You can achieve faster development cycles (because of an emphasis on configuration rather than coding/testing).
• You systems development and management is aided by having full transparency - components are accessible through graphical interfaces giving you automatic auditing, logging, error handling and quick problem diagnosis.
• You have built in flexibility - deployment across machines or environments is as simple as a drag-and-drop in a graphical console.
• You have a built in test harness that allows developers and testers to easily drop messages onto the message "bus".
• You have the advantage of developing using industry standard Java and associated technologies.