Introducing a new kind of enterprise integration engine

Inter-table and inter-database relationships can survive changes to most any part of the schema on either side (or both) of the connecting relationship.

EDP’s new way of establishing connections uses a “smart” translation system. Translations are automatically adjusted to maximize the continuance of processing.

Every element of metadata is automatically related to a “core understanding”. In effect, the system has a rudimentary understanding of the database schema.

Turning databases into resources

If 70% of the cost and time is going to be invested in integration, then doesn’t it make sense to start by building a solid and flexible integration approach?

Let’s decouple the integration itself by implementing a supporting Enterprise Service Bus (S-ESB) that understands dynamic integration.

Let us introduce you to the first object oriented “smart” bus. With our Smart Enterprise Service Bus (S-ESB) network demand is reduced up to 66% and direct to database access can be done by simply defining rules.

Smart bus allows you to attach to popular Service Bus middleware products. It insulates the more labor intensive aspects of development from your new SOA environment.

For example, you can integrate wireless or embedded systems direct to the enterprise infrastructure.

It extends the programmer’s reach and positive effect in the production and deployment of new Objects.

Unityware’s Smart Bus does the same thing for database access as the popular Enterprise Service Bus (ESB) products do for application services.

Now there is an enterprise foundation on which to build that works even when your plans and governance are not completely up to par.

Having to plan the whole of SOA in advance and implement a full governance organization is well and good. But for many folks the need to implement the foundation shouldn’t get in the way of planning.

Now there is a way to implement as many of your databases as you need as a dynamic service which can then be used to support future SOA architectures without having to wait.

The key is in the flexibility of a “smart” bus, where you won’t have to change program code or “adapters” in the future to match new SOA strategy or architecture.

Is this a bullet-proof or fail-safe way to SOA? Perhaps, but if it isn’t, then it is the closest thing you can get today.

A new way to SOA – Environment to start, grow and stay.

The Enterprise Data Bus (EDB) lives within the Enterprise Data Pump (EDP). The pump is responsible for directing traffic and translating between data “understandings” at different points in the networked system.

You can almost view the pump as a network layer above the bus.

More than just a bus, the pump can cause dynamic translations between metadata and actual data. It can sense when a database has changed and then automatically issue new commands to update data in-memory or in a database. It can trigger events and automatically handle all of the database connections.

The bus acts as a virtual community consisting of applications, databases, external and internal clients. Each of the community members see the data landscape as a single context sensitive virtual database.

The bus can very efficiently transport just pure data (without the need for any form of meta descriptions), events and exceptions between the various members of the application community.

Adapter integration (connecting your systems to the Enterprise Data Pump) only requires two classes and can be accomplished in as little as four lines of code (one for connection and the other for communication).

Database requests can be issued without knowing the actual database (just the context) or issuing SQL statements. The EDP can automatically generate SQL code directly from messages.

Message mux is responsible for “demodulating” the messages into data, events and exceptions.

The clients see the data returned as standard messages without any need to identify the kind of message or divine the metadata.

Built-in facilities to translate messages into data sets which not only match metadata, but can be accessed and managed via the metadata.

Data is presented (along with its metadata) translated into a local “understanding” which does not need to be consistent with understanding anywhere in the enterprise.

The mechanism for enforcing loosely-coupled implementation is removed from the programmer’s responsibility and assumed by the Enterprise Data Pump. In fact, you can change the messaging structure (even names or data types at the metadata level) without effecting any other connection to the messaging bus.

Enterprise Data Pump transports contextually marked objects. This enforces a context over the otherwise random environment without adding any limitations as to the cargo of the transported objects.

The context provides a frame of reference which only has to be understood by the Enterprise Data Pump. On the other hand the pump is responsible for making sure that the delivered objects align themselves to the context that is understood at the receiving end.

In this way the same data can be transported and delivered in multiple forms without having to know anything about the targets.

Data becomes “environment agnostic” in that no member of the community need know how anyone else thinks the data is formatted, stored or defined.

The data pump automatically aligns returned data and any exceptions to the original request by simply passing it back in the same object.

The same GUI tool that manages connections to databases also provides a way to define context (done only once) when a new schema is connected to the bus.