Neuron ESB User Network

The Service Bus for the Connected Business

Three approaches to avoiding the spider web

One of the primary advantages of using an intermediary is defeating the n(n-1) integration problem.

Leveraging the intermediary involves one of three approaches.

The first way is classic SOA and involves a modeling stage before any development moves forward. In this approach architects model the canonical representation of entities that represent their business. So Customer, Sale etc. are created and the web services exposed are those entities. This is a great approach if you have the time and if you have a strong architecture team. I rarely see it used in practice however because most organizations will not commit the SME resources necessary to produce the entitities and many SOA "architects" talk about contract first and then proceed to create point to point web services based on exposing aggregations to current back end systems. Proper SOA modeling is about modeling the business not the systems of the moment.

The second method is to think more in terms of leveraging a flexible intermediary designed for change. In this approach there is a defacto acceptance that services will constantly be changing and that spending a lot of time on entity modeling won't be done. The easiest way to accomplish this is to stand up a typeless endpoint or "OnRamp" combined with a flexible routing, transformation,and aggregation framework. This model will not give the stability benefits of canonical modeling but it will accomodate evolving interfaces driven by either the consumer or producer.

The third involves the best of both worlds. Model the entities then expose them via a single endpoint and binding. Location transparency, binding consolidation and all of the SOA goodness all in one shot...

The good news for Neuron users is Neuron can be used for all of these. Want to stand up an endpoint for each entity Neuron can do that.(Neuron doesn't produce WSDL for those endpoints but as a dedicated and serious SOA architect you would never depend on WSDL that had to be generated by an active endpoint and couldn't be sent out of band would you?) Want an OnRamp? Neuron can do that..And of course since Neuron supports both building blocks you can support the third.

Views: 88

Comment

You need to be a member of Neuron ESB User Network to add comments!

Join Neuron ESB User Network

Neuron ESB Product Support Forums and Communities

Latest Activity

Sayantini Basak posted a discussion

Maximum payload size(REST API) for requests interfacing to NeuronESB

I am new to Neuron ESB and in our current scenario,We need to process batch transactions comprising of ~1000 records and send them to Neuron ESB for further processing. I would like to understand what is the maximum size of payload that can be transferred using REST interface to Neuron ESB.See More
Jul 22
Profile IconRobert E Dunie and Sayantini Basak joined Neuron ESB User Network
Apr 28
Profile IconDayanand, Frederic C, Steffen Greve-Oksfeldt and 1 more joined Neuron ESB User Network
Mar 16
Profile IconCam Vong and Mitja Luznar joined Neuron ESB User Network
Jan 27
Profile IconWill Hitzges, Chad Parsons, michael larsen and 4 more joined Neuron ESB User Network
Jun 11, 2021
Anupama Nair posted a discussion

ODBC stored proc polling with temporary tables

We have set up an ODBC adapter to poll a stored proc.We found that if the stored proc has a temporary table defined the rows returned are always 0.Any idea why this would be and what we can do to get around it?See More
Dec 14, 2020
Prasanth Kharade is now a member of Neuron ESB User Network
Dec 30, 2019
Suman vadde is now a member of Neuron ESB User Network
Dec 16, 2019

Badge

Loading…

© 2022   Created by Neuron Admin.   Powered by

Badges  |  Report an Issue  |  Terms of Service