Book Image

Service Oriented Java Business Integration

Book Image

Service Oriented Java Business Integration

Overview of this book

Table of Contents (23 chapters)
Service Oriented Java Business Integration
Credits
About the Author
Acknowledgement
About the Reviewers
Preface

Integration


Knowingly or unknowingly, applications and systems have been built over decades in silos, and it is the need of the day for these applications and systems to interchange data. At various levels depending upon the level of control, the data can be interchanged at multiple layers, protocols, and formats. There seems to be a general trend of "Technology of the day" solutions and systems in many organizations. Neither this trend is going to end, nor do we need to turn back at them. Instead, we need to manage the ever changing heterogeneity between systems.

Note

Application and system portfolio entropy increases with technology innovation.

I don't know if there is a global movement to bring standardization to innovation in technology. This is because the moment we introduce rules and regulations to innovation, it is no longer an innovation. This statement is made, even after acknowledging various world wide standard bodies' aim and effort to reduce system and application entropy. A few years back, Common Object Request Broker Protocol's (CORBA) promise was to standardize binary protocol interface so that any systems could interoperate. If we look at CORBA at this point, we can see that CORBA has not attained its promise, that doesn't mean that we need to throw away all those systems introduced during the 90's because we cannot integrate.

Enterprise Application Integration

David S. Linthicum defined EAI as:

The unrestricted sharing of data and business processes among any connected applications and data sources in the enterprise.

This is a simple, straightforward definition. In my entire career, I have been fortunate enough to participate in much new generation IT system development for domains such as Airline, Healthcare, and Communications. Most of the time, I've been writing either adapters between systems, or negotiating and formalizing data formats between desperate systems. I know this is not because the former system's architects haven't put a long term vision to their systems in the angle of interoperability, but because systems have to evolve and interoperate in many new ways which were not foreseen earlier. This pushes integration providers to define new software pipes across applications. When we start this activity it might be elegant and straight forward, but sooner than later we realize that our integration pipes have no central control, administration, or management provisions.