Saturday, June 30, 2007

Week 4 (Write up) - Enterprise Integration Patterns

Chapter 9: Composed Messaging Examples

I REALLY enjoyed reading this chapter. The process to obtain a loan quote is a something that we are all familiar with, but it was good to now look at the process from another aspect. This article spoke in detail of the process and how it uses patterns and queues to complete the task. This process has to be very efficient because at a bank you have multiple clients wanting to use the service concurrently. As long as each broker picks the correct implantations this should not be a problem.

The Complete Loan Broker Design figure was vary good; then even remembered to take into account the fact that each bank may use a slightly different message format for the loan request and response. To get past this they use a translator to send the message out and a normalizer to bring the request back in. I couldn’t find much on the details of how this works but basically it is an adapter that converts the interface of a component into a another interface so it can be used in a different context.

Under the section Synchronous vs. Asynchronous it describes the pros and cons of each one. One the major benefits of using asynchronous invocation over synchronous over a message queue is the ability to create more than one instance of a service. “For example, if it turns out that the credit bureau is a bottleneck, we could decide to run two instances of the credit bureau component. Because the loan broker sends the request message to a queue instead of directly to the credit bureau component it does not matter which component instance processes the message as long as the response is put back onto the response channel.” That part was a bit confusing to me…..if you send a request to the queue and then later send another request to the queue…how can you expect the second request to return first? Isn’t the whole point of queue to form a line?
Under the addressing section it talks about the fixed vs. distribution vs. action. The auction will work the best as long as you put some type of restrictions on it such as filter or an aggregator. The reason being you do not want to wait all day for a response from a bank. There must be a cut off time.

Sunday, June 17, 2007

Week 3 - Follow up on research

After doing to research the main issue I have found is Integration simplicity. “When integrating an application into an enterprise, developers should strive to minimize changing the application and minimize the amount of integration code needed.” I am finding that this did not happen. It was not easy to bring everything over. There where some changes to the code that had to me made. There were also some things that the developers just could not figure out how to bring the data over. In the end the employees had to come in on a Saturday and manually move the information over; meaning re-key in the data in the new system.

There is also a lot of customization being done. That is because there is a place on the intranet where you can enter in feature request. The analyst would still like to see some of the old functionality of the old system. “Changes and new code will usually be necessary to provide good integration functionality.”

In the Enterprise Integration Patterns the author talks about application coupling and that “applications should minimize their dependencies on each other so that each can evolve without causing problems for the others because when the applications change and break those assumptions, the integration breaks.” Ideally we would each application to communicate with each other, he does have a point. What id one system goes down or one system becomes legacy and has to be migrated over? I’m finding that when each branch of the company had its own system for some reason things seemed to go smoother. Now we have to worry about one system not being synced up with another or another system not being updated so it can feed the system and just so many more things of that nature.

Sunday, June 10, 2007

Week 1 - Research topic

The topic I am going to write my paper on is Inter-organization systems integration. Recently the support department migrated all of their systems over to one system that allows for more functionality. Some of the support departments were using Clientele, Pivital, or other systems. Now all departments are using Right Now Technologies (RNT.) With RightNow there is one central knowledge base to manage all information, whether by phone, email, or web and chat from a single point of entry. This is a highly effective, easy to use 24/7 information resource for our customers. Using this system will cause a major reduction in phone and email workloads; resulting significant cost savings and allowing the support staff to focus on issues that truly warrant their personal attention.
Another good thing about RNT is that it feeds from another system we have called Sales Force. Sales force is used by the sales department to track software sales, license seats, maintenance and support agreements and more. Since this system links to RNT it is easy for the support analyst to be able to tell if they should give the customer support or not based on if their maintenance and support agreements has expired.
I will detail the process of how RNT was picked out of all the possible software’s by evaluating both the business and technology needs of the company. I will also talk about the actual process of moving the data over from Clientele, Pivotal, and the other systems that Deltek was using.

Week 2 write up - Component vs. Service software

Component-based is a software intensive systems developed from reusable parts or components. Because these parts are reusable as long as they are developed and maintained it is easy to make improvements to a system by means of component replacement and customization. Now of course component-based development depends on the viability of an established science and technology foundation for achieving predictable quality in component-based systems. And from what Dr. Wan posted I am pretty sure SAP may use component based system as well. I think as long as there is predictability component-based software is the way to go.
A service-based software system is one that is a composition of a collection of interacting services. Each service provides mechanism to access its functionality via well-defined interfaces. Therefore we can say characteristics of SBA include loose coupling, emphasized stateless property, service definitions, and discovery mechanisms.
I do think that service based software systems are needed because they are very flexible which helps to meet the evolving business requirements. Basically Service-based software systems are used for systems offering functions that are services which may be interrelated or may mutually depend on each other.
Historically, service-based systems engineering has proven useful in the development of telecommunication systems, helping to modularize complex system functionality with high degree of interaction among system components.
And in present day we are increasingly, seeing the notion of service also enjoys popularity as a means for structuring other kinds of complex distributed systems. “Web services” are just one example of this increase in popularity; others occur in the context of spontaneous networks, ubiquitous computing, and safety-critical systems (such as in the automotive or avionics domain).
The only problem here is that the development of service-based software was not well designed for a security-critical systems. You see there will be services that can easily interact with each other in a variety of unknown ways which may cause consequences to the security properties.