Week 9 Write up – BEA SYTEMS

Week 9 Write up – BEA SYTEMS


BEA Systems, Inc. is one of the major companies on the second tier developing enterprise infrastructure software. Founded in 1995, BEA has specializes in the enterprise infrastructure software market. The company's name is an acronym based on the first names of the company's three founders: Bill Coleman, Ed Scott and Alfred Chuang. Alfred Chuang is still with the company, acting as the chairman and CEO. All are former employees of Sun Microsystems. They launched the business in 1995 by acquiring Information Management and Independence Technologies. These firms were the largest resellers of Tuxedo, a distributed transaction management system sold by Novell.

BEA has three major product lines,
1. The Tuxedo Transaction Oriented Middleware platform
2. The WebLogic J2EE Enterprise Infrastructure platform and
3. The AquaLogic Service Oriented Architecture (SOA) platform.
Please go to http://en.wikipedia.org/wiki/AquaLogic for a full list of all of the products in this suite.

The “Aqua” prefix and the company’s campaign to “think liquid” refer to the integration of enterprise data via Web services; specifically, the data is no longer frozen in various applications. AquaLogic provides the plumbing for Web services and other forms of interapplication networking. It supports multiple transports; although not RMI (Remote Method Invocation), IIOP (Internet Inter-ORB Protocol), or CORBA. It can also interface with various true messaging middleware products. (It offers reliable messaging but doesn’t interface directly with message-queuing middleware.) XLST (XSL Transformation) transforms can be applied to EDI transactions for enterprises that still rely on that technology.AquaLogic also provides the traditional enterprise features, such as data transformations specified via XML configuration files, rules- and content-based routing, and on-the-fly encryption.
The ALSR (AquaLogic Service Registry), is based on technology OEM’d from Systinet, complements this bus. ALSR provides an enterprise-wide UDDI 3.0 directory for facilitating location and access to corporate Web services. This registry stores data such as services, schemas, transformations, and policies. It can import items directly from the company’s WebLogic Workshop environment, which is used for development of Web services.
One final embedded item is peculiar: AquaLogic embeds a full implementation of WebLogic server. This design is required to support many of AquaLogic’s clustering and high-availability features, as well as its security resources. Oddly, the WebLogic server can be used as a full-fledged application server. BEA places no restrictions on this use, although it points out that this dual usage of the WebLogic will slow performance both for AquaLogic and the applications. However, if the needs of AquaLogic or the application are light, this might make for a comparatively economical configuration.
BEA AquaLogic drives unparalleled Business and IT alignment through a unified, cross-platform software suite that bridges the gaps between people, processes, applications, and information — for an SOA that knows its business.
BEA AquaLogic reduces the dependency on IT and the need to write code, and introduces new software that promotes the direct collaboration of business and IT participants to meet strategic, high-impact challenges and drive innovation. BEA AquaLogic provides a unified, agile platform for creating and managing business processes, portals, collaborative communities, and composite applications. It increases IT efficiency and speeds time to market by making it easy to develop, discover, deliver, and reuse services across the enterprise. And it provides bullet-proof governance over the composition of new services, business processes, and composite applications.
Overall, AquaLogic has a good management interface and prospects to grow into a serious ESB. However, it has not quite reached the levels of its direct competitors in this first release.

http://www.itworldcanada.com/product/2/62736.html

Research Paper...........continued

Web Based vs. Local Server Based ERP Solutions
While doing research for my project I looked at all of the different systems that my company had to choose from before it performed this major integration project. They ended up picking a web based ERP over a local server based ERP.

So I decided to look at the differences between Web Based and Local Server Based ERP Solutions to see if it really made difference which approach you choose.
From talking to people at the company the clear advantage to the web is that remote users like executives and sales reps can access the company system with any browser, which is much more convenient than going through a laptop configured for Citrix or Terminal Services.
Also web based allows for more flexibility and customizations. For example if your ERP was written on ASP. ASP usually requires the customer to take the system as is. In other words, there may be major limitations around the customer's ability to modify code, add on third party products, and even to customize user screens. Also time to implement should be shorter given that you do not need to upgrade your network for Windows/Exchange Server and SQL Server database. Security concerns that companies had in the past seem to have subsided as the technology has improved.

Below are just a few of the reasons why my company decided to use a web based ERP.

1. A web hosted solution removes your headache from the Investment made towards Time and Cost in the maintenance of the server & other hardware.

2. A web-hosted solution also removes your worry about the new functions and features (service packs and fixes).

3. When you go in for a web-hosted solution, you can start using it from day one (avoids the worry towards implementation time, which has been cited as one major reason for ERP failure).

4. Optimized performance & Support

5. Access through hand-held devices made easy.

Case Study - ITIL Best Practice (week 8)

The Information Technology Infrastructure Library (ITIL) is a framework of best practice approaches intended to facilitate the delivery of high quality IT services. ITIL is published in a series of books, each of which covers a core area within IT Management. This book outlines an extensive set of management procedures that are intended to support businesses in achieving both high financial quality and value in IT operations.

Case Study - ITIL Best Practice

Problem
To reduce the number of incidents occurring as well as decreasing the mean time to repair (MTTR), the bank needed to gain better visibility of likely impacts and better understanding of the underlying problems. According to the ITIL best practice framework the bank needed to define what they had and how to describe each element, as well as defining which critical applications, processes and functions to prioritize.
Solution
The bank implemented Tideway Foundation to serve as a configuration management database (CMDB) for the IT infrastructure. Foundation's low-impact agent-free indexing keeps the CMDB current and accurate, allowing high quality reports to be generated on demand with minimal resource requirements.
The visibility provided into the configuration of the environment serves as the basis for efficient Change Management, Incident Management and Configuration Management
Benefits
•Automating the initial creation and population of the CMDB reduced the time previously taken to build a manual snapshot by 60-70%
•Time taken to update and maintain the CMDB was reduced to 1% of the previous manual effort
•The CMDB data is now accurate, timely, complete and consistent, and therefore trusted and actionable
•Change impacts can be accurately predicted reducing the effects of errant change
•Root causes of incidents can be found significantly faster, reducing downtime.

To find out more about this you can go to http://www.tideway.com/Customers/ITIL_Best_Practice
Tideway is the market leading provider of Application Dependency Mapping Solutions.
Tideway was founded to provide the tools today’s enterprises need to allow IT to run like a business by providing the complete and authoritative source of operational IT intelligence such as, automated processes, up-to-date and reliable management data and more
http://www.tideway.com/

Emerging Technologies for IOS (week 6)

Inter-organizational systems (IOS) have traditionally been characterized as EDI-based
‘hub and spoke’ models such as those connecting grocery retailers or large manufacturers with their suppliers. Such systems were seen to positively affect inter-organizational transactions by reducing costs and improving efficiency.

In sectors such as telecommunications, news media, and financial services, increasing environmental complexity and technological innovation have led some organizational networks to explore more dynamic IOS models such as those using XML(Extensible Markup Language.) Traditional EDI-based systems implement linkages between purchasing and sales in independent organizations. More recent IOS focus on a broader range of value chain activities such as R&D, marketing etc.

Emerging technologies are seen as changing the nature of inter-organizational systems. In particular, the international data format standard, XML, is seen as having huge potential in facilitating the exchange of information in inter-organizational environments. XML has already changes the way we view technology in at least three key areas; EDI, Enterprise Application Integration (EAI) and content management. XML requires organizations to develop specific vocabularies in order to exchange information. Such vocabularies tend to be industry specific, and their development must deal with complex inter-organizational dynamics. Sometimes complexities can arise when activities cross organizational boundaries such as: changes in business competencies and priorities, an increased need for co-operative effort for establishing targets, the synchronization of differing accounting systems, and the establishment of trust.

Emergent technology such as XML presents a potential solution to the dynamic communication and collaboration needs of more complex business webs. However, the use of XML to support new inter-organizational business models has received little empirical attention. For example in 2002 Nelson did a study on influencing coadoption; however, the development and use of emerging XML-based IOS has not been extensively studied.

In conclusion XML-based IOS operating would be best used in a dynamic environment where things are always changing. This is a much more cooperative approach to IOS implementation than was evident with earlier IOS thus allowing more complex systems to be adopted.
As the years go on you will soon see that IOS is not longer a competitive weapon, but instead it will be a competitive necessity.

The New and Emerging Atom ( Week 6)

For this week’s topic I choose to write about Atom Syndication Format. I chose this topic because while doing research for past week’s topics I have seen the subject of “Atom” come up but I had no idea what is was. So I thought this would be the best way to learn.
The name Atom is actually referring to a pair of related standards. The Atom Syndication Format is an XML language used for web feeds. So in short, it’s a simple HTTP-based protocol for creating and updating Web resources. A web feed is basically a data format used for allowing users to see frequently updated content. A web feed can be syndicated thus allowing users to subscribe to it. Making a collection of web feeds accessible in one spot is known as aggregation. A perfect example where I users would want updated information is the website Dig. If you use a web feed this allows you to only get updated with the information that you want to need instead of all the other articles.

Before the creation of the Atom the primary method of web content syndication was the RSS family of formats. The Atom has not been around for very long; it first drew interest in June of 2003 by Sam Ruby. Sam set up a set up a wiki to discuss what makes "a well-formed log entry". This initial posting acted as a rallying point as people quickly started using the wiki to discuss a new syndication format to address the shortcomings of RSS. The main problem with RSS is that there are multiple incompatibilities with the different widely adopted versions of RSS. The intention of the Atom was to ease the difficulty of developing applications with web syndication feeds. In December 2003 Atom 0.3 was released and soon adopted by Google. Google uses Atom for such technologies as Blogger, Gmail and Google News.
The technology behind Atom 1.0 is in an XML namespace and may contain elements or attributes from other XML namespaces. There are specific guidelines on how to interpret extension elements. Additionally, there will be an IANA managed directory of values. Finally, Atom 1.0 provides recommended extension points and guidance on how to interpret simple extensions.


The Atom specifies use of the XML's built-in xml:base attribute for allowing the use of relative references. Atom feeds can also be accessed via standard HTTP client libraries. Standard caching techniques work well and are encouraged to be used with Atom. In continuation with the patterns we have been talking about template-driven creation of both formats (RSS and Atom) is quite practical. Rules for applying standard XML Encryption and XML Digital Signature on entries are included in Atom 1.0. Alternatively, the feed can be encrypted or signed, like RSS 2.0, as a bag of bits. Atom 1.0 provides and elements at both the feed and entry level. These elements must contain a name, and also have optional email and URI sub-elements. Atom categories have three, with the addition of optional human-readable title. Atom includes a (non-normative) ISO-Standard RelaxNG schema, to support those who want to check the validity of data advertised as Atom 1.0. Other schema formats can be generated from the RelaxNG schema.
I feel that Atom will become a very large part of web delivery in the near future. Before this class I had not heard of Atom but I did hear about RSS. So currently the Atom syndication format has not had strong penetration into the mainstream syndication community, but that could all change in the very near future. With the RSS 2.0 Standard locked (due to copyrights), with any new development to be done under a different name, Atom could very well take RSS place as the leading web syndication format. I believe that Atom could be a major part of the future of messaging. It's that big. As we all know, spam has ruined email, and it doesn't appear that anything will fix the problem and the government is not doing anything about it. Instant messaging is doing fairly well for both social and business on-line messaging, and Internet telephony (better known by the cute-sounding name of VoIP) is rapidly maturing. However, neither works as a sensible off-line messaging mechanism like email.
Enter Atom and syndication. Atom is a format for entries that contain a chunk of content which is usually HTML, and some information about the content such as when it was written, who the author is, and so on. A "feed" is a file that contains a bunch of RSS entries. There are already dozens of RSS readers available.

Week 5 -Traditional Integration - EDI

Electronic Data Interchange (EDI) is the exchange of businesses, organizations, government entities and other group’s transactions/information from one company to another using a computer network to transfer the data.
EDI can be traced back all the way to 1948 in Berlin Airlift, where the task of coordinating air freighted consignments of food and consumables was addressed by devising a standard manifest. It then became electronic and standard in the1960s, with the rail and road transport industries. Finally in 1968 the United States Transportation Data Coordinating Committee (TDCC) was formed, to coordinate the development of translation rules among four existing sets of industry-specific standards. At about the same time, the U.K. Department of Customs and Excise was developing its own standards for documents used in international trade, called Tradacoms. These were later extended by the United Nations Economic Commission for Europe (UNECE). Problems created by the trans-Atlantic use of two different (and largely incompatible) sets of standardized documents have been addressed by the formation of a United Nations Joint European and North American working party (UN-JEDI), which began the development of the Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) document translation standards.
Many different types of data are sent over the network such as invoices, orders, confirmations and other business documents. There is a big misconception that EDI consists of the entire electronic data interchange paradigm, including the transmission, message flow, document format, and software used to interpret the documents. But in reality EDI is just the set of standards for structuring information to be electronically exchanged internally or externally. The American National Standards Institute (ANSI) has approved a set of EDI standards known as the X12 standards.
EDI is very important because it effects cost savings and improves efficiency because it minimizes the errors that can occur if the same information has to be typed into computers more than once. Another advantage is that EDI provides an easily accessible mechanism for companies to buy, sell, and trade information. Many corporate giants are now demanding that their suppliers convert their sales and purchasing operations into EDI systems as well. In the retail market, the use of EDI systems allows the retailer to implement quick response strategies that can reduce the time they must hold merchandise in inventory, which can result in substantial cost savings for the retailer.
Different networks can be used such as VANs and the Internet. The rise of the internet gave EDI quite a boost. . As more and more companies get connected to the Internet, EDI is becoming increasingly important as an easy mechanism for companies to buy, sell, and trade information. Although interactive access may be a part of it, EDI implies direct computer-to-computer transactions into vendors' databases and ordering systems. That was done using privately owned networks and the traditional EDI data formats (X12, EDIFACT and TRADACOMS). These days many business transactions are formatted in XML and transported over the Internet using the HTTP Web protocol.

As for the future of EDI I feel it will continue to grow. One reason it is expected to grow is that business-to-business e-commerce overall has been growing rapidly since the early 2000s. In 2000 alone, business-to-business sales were estimated to be $5.2 trillion by 2004, according to Corporate EFT Report. Also the use of EDI also is expected to grow right along with international trade agreements like the North American Free Trade Agreement (NAFTA).

Even though EDI is growing there is a chance that something else will come along and take it’s place. New technology is being introduced such as internet channels—including hybrid EDI/Internet electronic trading networks, Internet e-marketplaces, extranets, Internet company-to-company links, and private emarkets. Companies are relying on a variety of channels to conduct business with suppliers, depending on the nature of their business goals. SoVANs have not gone away completly, but the demands of businesses and their trading partners have changed dramatically. Internet-based transport, broader and more robust sets of information and real-time connectivity are just a few of the items that have been appended to the connectivity wish lists of most companies. It seems as though the basic language of data movement has suddenly become XML, despite the presence of decades-old EDI standards. XML, while incredibly exciting as an application and data-neutralizing standard, is still in its infancy. Therefore EDI isn't going away any time soon.
One example is a software company that launched a new patient billing management solution to streamline billing and collections back in October of 2006. The system works by capturing billing, claim and payment information and delivers it in a unified view to speed up the billing cycle. In other words the users is looking at a virtual view of a patient's complete financial history, helping accounting staff accelerate collections, improve billing efficiency and reduce billing costs. This system is great for any hospital that which faces an increasing economic, competitive and regulatory demands, as well as pressure to bill sooner, generate claims faster and increase overall operational efficiencies within the business office. The system can also automate the claims payment posting process through support for automated work flow and ANSI EDI 835 formatted befits explanations. It integrates with existing claims systems, provides role-based access to ensure security and compliance, organizes and charts a view of all patient information including claims, benefits explanations, secondary claims and correspondence.

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.

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.

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.