EAI Blog

It's nice to have completed another course milestone this past week.  I'm really glad that I picked my topic - Ajax.  I had heard a lot about it from people at work, but did not have a clear understanding of what it was until I did the research for my paper.  It's a pretty cool mix of technology.

BPIOAI was the focus of the readings for this week.  According to the book it's "the ability to define a common business process model that addresses the sequence, hierarchy, events, execution logic, and information movement between systems residing in the same organization and systems residing in multiple organizations."  I wonder how widespread this architecture is.  I think in theory it sounds nice; however, I think for most organizations to implement this they would need to overhaul their whole business process.

Well... I don't have a ton to blog about this week.  But I am happy to report that after much procrastination - I've submitted by midterm. 

My only other comment this week is about the XI mapping tool that we reviewed this week.  I think it's remarkable how polished these types of tools are.  Because it's a lot of coding to map data objects together by hand.  Trust me, I've done it. :)

After reading the health services reading this week, I began thinking about the SLAs associated with web services.  The article pointed out that hospital IT architectures are complex and extremely vital because their performance can translate into a matter of life and death for a patient.

The article discussed creating web services to enable the integration of disparate systems.  However, the solidness of the integration is directly dependent on the availability of the system hosting the web service.  If the consumer needs 100% uptime - a 90% uptime on the provider is not sufficient.  How should an organization handle this?  To add more complexity in the mix - what if the organization uses a broker such as SAP XI - or a similar product to broker the deal?  That broker also has a percentage of downtime and there is not guarantee that the service windows will overlap.  What is the consumer to do?  It needs the information 24-7 but is operating in an environment that might be stable, but does not meet the HA requirement.  What's the solution? 

I don't have one, but this a real type of an issue facing organizations.  How do you get data to high availability systems when they are asking for data from a non-HA system?  Can you imagine a mission critical hospital application that requests data via a web service and is denied because the source system is down for a 4 hour service window?  That is simply not acceptable, but it is a possibility that needs to be dealt with.

I think it was really interesting to learn this week that SOAP does not technically stand for anything anymore. 

So, I missed the lecture last week, but have been trying to catch up by reading the slides and book.

Today I completed Lab 1.  I have been having some issues getting Visual Basic Studio working on my laptop.  However, once I went to the SBA lab, everything went pretty smoothly.  I do have a question about our student website.  Are there other ways to upload files to it other than through a tool like Visual Studio?

Hmm... musings on XML...  well, I guess one of my thoughts is based on a quote from the book "XML provides a common data-exchange format, encapsulating both data and metadata."  I really think that's true, but another powerful offshoot of that is various projects that are able to take the XML (and XSD) and transform the data into code specific objects, such as Java objects.  (The projects I'm thinking about are tools such as Castor.)  I think that is where the power is - being able to transform the data into an object that is easily used withing a program. 

The discussion we had in class this week about screen scraping as a form of user interface level integration made me think about an integration that I knew about that was implemented at the business I work at.  Our business has legacy systems that leverage AS400 green screens.  Integrating with these legacy system can be somewhat complex, especially when one is trying to not just get data, but actually perform a task - such as updating an order.  The solution that was used was a screen scraping type solution.  However, what I remember about the screen scraping was that it was very fragile and also required quite a bit of knowledge of the legacy system - what information was required, how to navigate to the screens, what the error messages were.  So although this type of solution was "easier" then trying to hook directly into the logic that is being executed behind the scenes, it did take a lot of work in order to make the integration successful.