Initial Thoughts III-2 III-2 III-2 III-2 III-2 III-2

Size: px

Start display at page:

Download "Initial Thoughts III-2 III-2 III-2 III-2 III-2 III-2"

Joel Gallagher
5 years ago
Views:

1 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page 215 III-2 III-2 III-2 III-2 III-2 III-2 Initial Thoughts Now that Bongo had the green light to continue work with the Joe-to-Go (JTG) project, there was an enormous amount to do and, as usual, very little time to do it. The team needed to put together a prototype of the new system as well as a high-level technical design in a little under two weeks. Of course, delivering on these sorts of tight timelines is what has made Bongo a success. From Robert s perspective, in order to ensure the success of the project, the real goal of this phase was to uncover as many potential gotchas as possible without getting bogged down in too much detail. In order to kick things off, he sent out an to his development team.

2 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page III THE B2B AUCTION/EXCHANGE ~ It s a go for Joe-to-Go! Date: April 2 From: Robert Flemming To: Bongo Dev ( ) Subject: It s a go for Joe-to-Go! Team, By now I m sure a lot of you have heard the good news from Jeff and Allison, but I wanted to make sure everyone was in the loop. We had an extremely successful meeting last week at Joe-to-Go headquarters, and in fact we have the go-ahead from Joe himself to continue with the next phase of the project. JTG is one of the fastest-growing companies in the country, so this is a huge opportunity for Bongo. Congratulations and thanks to everyone who helped make this a success. We re into what I consider the most critical phase of the project: prototyping and technical design. We ve got a little less than two weeks to prepare for a meeting at JTG headquarters. Allison, I d like you to lead the team working on the prototype. You can fill them in on the requirements we heard from JTG. The most important thing is to convey the basic look and feel along with the application flow. Screen shots and flowcharts will be great. If we can get an early edition to Joe over the next week, that would be even better. Jeff, I d like you to head up the technical design track. On a related note, before we left for JTG I had a meeting with our Macromedia representative who was telling me about their new ColdFusion MX product. We didn t have time to get into a lot of details, but it sounded like it might fit this project quite well. Please go through your normal technology choice process; I just wanted to put a new possibility on the list. Keep up the good work, team. Robert

3 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page INITIAL THOUGHTS 217 Robert knew that Allison and Jeff had been through this process before, so he felt quite comfortable with their leading the prototype and technical design tracks, respectively. He particularly enjoyed this phase of a project, because so many different options were still available. It was like drawing the blueprints for the new application.the fun, but difficult, work was about to begin! Prototype > After receiving Robert s , Allison gathered her team to brainstorm about the design of the prototype. After looking through their notes from the meeting with Joe-to-Go, they decided to spend a few hours researching other B2B auctions and exchanges on the Internet. They wanted to get a feel for the common user interface and navigation paradigms used elsewhere. Afterwards, they regrouped to define the common artifacts they uncovered in the requirements from JTG. These are the items they felt belonged on most, if not all, pages. They produced the following list on the whiteboard: Site Header. This area of the site should include some Joe-to-Go branding, including their corporate logo. There should also be some basic site navigation via a small menu. The content of the menu will be driven from the site map. Category Navigation. Most auction or commerce sites organize their products by category. This concept should apply to JTG product requirements as well. Typically, the categories are hierarchical, that is, categories can contain other categories. Search. At the very least, a user should be able to launch a basic search without having to go to another page first. Content Area. This is where the main content of the site will be displayed. Several types of content exist, such as Auction Browsing and Details. The types of content will be defined in the site map.

4 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page III THE B2B AUCTION/EXCHANGE With the above artifacts defined, the team talked for a while about the look of a typical site page. Their goal was to come up with a single page template so that each different area of the site would only change in the content area. After a few iterations, they came up with the template shown in Figure III-2.1. Corporate Logo Menu {Figure III-2.1 The development team came up with this template for the application s exchange site page. Category Navigation Main Content Area Search With a rough sketch of the template page completed, the team moved on to defining the site map. Again, they went back to the requirements from JTG to see what was needed. Most of the requirements were fairly vague when it came to the user interface, so the team had to get creative about what types of pages would be needed. It was also a bit tricky because so many pages were accessible at any time through the various global navigation elements available from the template. After a bit of research and discussion, however, they sketched out the site map on the whiteboard, shown in Figure III-2.1.

5 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page INITIAL THOUGHTS 219 Log-in Browse Category My Exchange Auction Details Log-in Confirm Bid Log-in Search Results My Prefs LEGEND Global Nav. Accessible Page { Figure III-2.2 The Joe-to-Go Exchange site map. Log-out Normal Page Normal Link

6 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page III THE B2B AUCTION/EXCHANGE At this point, the team decided to adopt a divide-and-conquer approach to their prototyping. While the rest of the team began to put together actual HTML mock-ups of the basic page template and content areas, Allison would get Joe s approval for the site map. She captured the site map from the whiteboard and included it with the following memo she sent to Joe: ~ Site map for JTG Exchange MEMO Date: April 4 To: Joe Kavendish, Robert Flemming From: Allison Mayweather Re: Site map for JTG Exchange Hi Joe, The team here has been working on a prototype of the JTG Exchange site. After our meeting last week we had quite a few functionality and technical requirements, but we didn t spend a lot of time discussing the actual user interface. What we ve done is to take a first pass at a site map that we think will meet your requirements as well as capture some common features in B2B exchange sites. The attached diagram shows the various ways a user can move throughout the system, and the following is a short description of each page: Log-in Page. All users must be authenticated before they can access the site. This page requests their user name and password. Browse Page. This is the main page for users browsing auctions. It displays a list of auctions along with their key attributes such as current price and end time. Search Results. After performing a basic search, this page displays a list of matching auctions.

7 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page INITIAL THOUGHTS 221 Site map for JTG Exchange Memo (continued) My Exchange. This is a common theme in B2B exchanges. It gives users a snapshot of their current and recently closed auctions. Auctions only appear on this page if users have listed the item (JTG employees only) or if they have placed a bid on the item. It provides users a quick view of how their auctions are going as well as tracking their completed auctions. Auction Details. Clicking on an auction from the Search, Browse, or My Exchange screens brings up the Auction Details page. This shows all the information about the auction, including current bids. New bids can also be placed from this screen. Additionally, JTG employees will be able to terminate auctions from here. Bid Confirmation. Requires the user to confirm a bid entry before entering it into the system. My Preferences. Allows the user to edit contact and log-in information, such as address. They can also configure their notification options from this screen. Please let me know your thoughts on this approach. And if you have any questions please call. Thanks, Allison In the meantime, the rest of the team had completed their mock-up of the main page template. They decided on showing the Browse page as the content page for the mock-up (see Figure III-2.3). Allison decided to forward it to Joe for his feedback.

RJ2EE.III-2 (215-230) 12/5/02 10:22 AM Page 222 222 III THE B2B AUCTION/EXCHANGE {Figure III-2.3 The Joe-to-Go page template mock-up.

8 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page III THE B2B AUCTION/EXCHANGE {Figure III-2.3 The Joe-to-Go page template mock-up. The team continued to work on the prototypes for the other content areas while they waited for a reply from Joe. They didn t have to wait long as it turned out. Joe wrote back the very next day. ~ JTG Exchange Prototype Date: April 5 From: Joe Kavendish To: Allison Mayweather ( ) Cc: Robert Flemming ( ) Subject: JTG Exchange Prototype Allison, Thanks for your quick work on the screen map and template page mock-up. By looking at the two of them, I can really start to see how this site is going to operate. Here is some feedback: 1. I noticed that the Search box only asks the user for their search text. Will this search all the auctions, or just open ones? I d imagine that over time there will be a lot of closed auctions that people won t want to search. Can you put some sort of option in the search to indicate all auctions or just open ones?

9 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page INITIAL THOUGHTS 223 JTG Exchange Prototype (continued) 2. I like the My Exchange concept. It s like a dashboard for the suppliers, and for us as well, I suppose. Can you make that the main page when the user first logs into the system? Overall, I think everything looks great. The colors and layout fit with our corporate design. You must have looked around our Web site for ideas! Thanks, and keep up the good work. Joe Technical Design > While It looked as if Allison s team had hit the mark with their site design and layout. She was glad that Joe-to-Go liked their design, as they didn t have any strict requirements to work with. She shared his comments with the team and they continued to work on the rest of the mock-ups for Joe s review. Allison and her team were designing the system s user interface (UI), Jeff and his team were working through the technical design. After learning the requirements for the system from their meeting with JTG, as well as keeping an eye on what Allison and crew were coming up with in the UI, Jeff knew his first task was to divide up the work of the system into several tiers. Most modern Web applications can be divided into several tiers, and this one was no exception. Most systems have three tiers: a presentation tier, a business logic tier, and a data tier. The presentation tier primarily deals with the output to the user. This typically takes the form of Web browser pages, but it can also include other devices such as cell phones or a command-line interface. The business logic tier is used to encapsulate the actions of the system, such as placing

10 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page III THE B2B AUCTION/EXCHANGE L instant message Sometimes a middle tier is itself composed of several tiers. This leads to systems with more than three tiers, often referred to as n-tier systems. a bid, creating an auction, or sending a notification. The data tier is concerned with the storage and retrieval of the data in the system, such as auctions and users. The business logic tier is often associated with the verbs of the system, such as sending notifications or placing orders, while the data tier is associated with the nouns, such as the users or orders themselves. Jeff knew that this first version of the application would only include a single presentation tier built for Web browsers, but he could certainly see it expanding out into other devices such as cell phones or personal data assistants (PDAs) in the future. By putting all of the core business logic into the business logic tier (the middle tier), new presentation layers could be built on top of it. Jeff knew he faced two broad tasks. First, he had to design the components of the system for the various tiers. Second, he had to decide on the implementation technology. Because of the tight deadlines they were facing, Jeff had to do these two in parallel. He asked Alex, another engineer, to look into implementation technologies, particularly ColdFusion MX as Robert had suggested, and come up with a recommendation. At the same time, Jeff would work with the team on the design of the database, the major component of the data tier. Database Design Most of the work involved in designing a data tier is designing the database itself. When the team looked at JTG s requirements and the early screen prototypes, it identified several of the major nouns in the system. The most obvious were auctions and bids, but there were also users and categories as well. From a database perspective, all of these things could be stored separately. But many interesting relationships exist among these pieces of data. Categories contain more than one auction as well as being hierarchical; auctions are listed by one user and have many associated bids; and each bid is placed by one user. Jeff knew that the attributes, or columns, on these tables (see Figure III-2.4) would probably change as his team went into development, but he wanted to make sure that these main tables would handle the requirements of the system. After the team tried to poke holes in the model for a while, they were satisfied that it would do the job.

RJ2EE.III-2 (215-230) 12/5/02 10:22 AM Page 225 2 INITIAL THOUGHTS 225 {Figure III-2.4 The high-level database design was the result of regular contact between the client and the developers.

11 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page INITIAL THOUGHTS 225 {Figure III-2.4 The high-level database design was the result of regular contact between the client and the developers. Implementation Technology While the rest of the technical design team was working on the database design, Alex was off scrounging the Net for information about ColdFusion MX. He had previously developed projects using J2EE technologies, but he hadn t used ColdFusion for a few years, and was interested in seeing what they had been up to recently. Some of the requirements for the Exchange involved fairly new technologies, and Alex wasn t sure if ColdFusion would support them. After doing a bit of research, he sent off the following with his findings: ~ Implementation technologies Date: April 4 From: Alex Mayner To: JTG Development Team ( ) Subject: Implementation technologies Hi everyone, As you know, I ve been looking at implementation technologies for the Exchange. Technically, this Exchange is a quite sophisticated application. It involves a number of new technologies, including Web Services and Instant Messaging. You ve all done J2EE projects before, so you know the pros and cons. In particular, J2EE provides an open framework for building robust, scalable, component-based applications. It s widely adopted, so there s a large base of knowledge and pre-built components to buy, not to mention all the free open-source components.

12 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page III THE B2B AUCTION/EXCHANGE Implementation technologies (continued) On the minus side, it does take a while to get things built. You pay a price for these advantages, and sometimes you don t need them. At Robert s suggestion, I took a look at the new ColdFusion MX... I haven t seen CF in quite a while, and let me say it sure has changed a lot. Traditionally, the strength of CF has been the ability to build and maintain pages with relative ease. That s still the case, and now they have introduced some interesting new features. For one thing, they ve introduced the idea of components into their language with ColdFusion Components (CFCs). One benefit of these CFCs is that they can be turned into Web Services by changing a single parameter. That might come in pretty handy in our application. It s worth taking a look at it. However, the biggest feature in my mind is that ColdFusion MX runs on top of a J2EE application server and provides interaction with that application server. Basically, that means we can take advantage of the best parts of both J2EE as well as ColdFusion. I can see us using CF for the presentation layer and CFCs as facades to the J2EE world where we can encapsulate our business logic. Through J2EE, we ll be able to provide capabilities that CF doesn t have, such as Instant Messaging. And CF will allow us to build our UI quickly and maintain it easily. I really think this best-ofbreed approach to technology will give exactly what we need. See you at the next design meeting. Alex

13 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page INITIAL THOUGHTS 227 Component Design With the new information from Alex regarding ColdFusion, Jeff felt they could start defining the various high-level components in the system and discuss some of the possible implementation choices. The best way to do this, in his experience, was to get the team together with lots of whiteboard space and walk through the system. Alex took the notes below from that meeting: o f DESIGN SESSION MEETING NOTES Date: April 4 Present: Jeff, Alex, Arkady The purpose of this meeting is to determine the potential components in the system, as well as identifying technologies that might be applicable. We started out by identifying the various actions, or verbs, that we would need to support in the system. We were able to group them into two main areas: auctions and notifications. Auction-related actions included the following: Creating an auction Extending an auction Terminating an auction Placing a bid Changing status of an auction Querying auctions and bids Notifications appeared to be the other major action in the system. Although the exact requirements were a little more vague (Jeff has an action item to follow up on this), notification actions appear to include: Sending an notification Sending an Instant Message notification

14 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page III THE B2B AUCTION/EXCHANGE d v While CF provides features to send , it doesn t seem to provide any Instant Messaging capabilities. In fact, neither did any of the J2EE application servers we were familiar with. Alex thought he had seen several open-source Java-based Instant Messaging libraries. If that is the case, we might be able to take advantage of them to meet our Instant Messaging requirements. Arkady will look into this further. We then discussed the various interfaces we have to this system. The primary path into the system is through the Web-browser based interface that Allison is designing. Given Alex s about ColdFusion, it seems that CF should support our browser UI requirements. A secondary route into the system is the Web Services interface. It isn t clear how much functionality this interface has to provide (another action item for Jeff) but we know it has to provide something. By encapsulating most of our functionality into components, we should be able to expose them through Web Services. Again, according to Alex, if we implement these as CFCs it might be very easy to expose them as Web Services. The possibility of using Enterprise Java Beans (EJB) was also discussed. EJBs are extremely robust, scalable J2EE components that are also accessible to any other J2EE platform. Our actual approach may even blend these two technologies, using CFCs as a wrapper around EJBs. In addition to the above two interfaces, Jeff also has discovered that the receiving department at JTG is using a message-based architecture for their tracking system. Since we need to integrate with their system, we re lucky that their message bus provides a JMS (Java Message Service) interface. Alex didn t think there was a direct way to integrate CF with JMS. However, there are several ways the J2EE can integrate with JMS, including the use of special EJBs known as Message-Driven Beans. These EJBs are assigned to a particular message queue and listen for incoming messages. They are extremely scalable and very easy to write. Since CF is tightly integrated with J2EE, this might be an approach we can take. Arkady has an action item to look into this further.

15 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page INITIAL THOUGHTS 229 d v Security was also briefly discussed. The basic security requirements were fairly clear from the original meeting with JTG. However, we need to make sure that the additional interfaces to the system are also secure. The Web Services interface in particular, as it will be exposed to the outside world. The JMS interface is internal to JTG so while it still needs to be secure, it s not as critical as the Web-browser and Web Service interfaces. Figure III-2.5 shows the diagram of the major system components and their interactions which was drawn on the whiteboard during the meeting. Web UI CFC/EJB Components Notification Manager & IM Web Services Auction Manager Receiving Manager Database Receiving System { Figure III-2.5 The design team drew this diagram to show how the components of the new system would interact. Message Bus

16 RJ2EE.III-2 ( ) 12/5/02 10:22 AM Page III THE B2B AUCTION/EXCHANGE o f ACTION ITEMS Jeff: Determine specific requirements for notifications Jeff: Determine specific requirements for Web Services Arkady: Look for open-source Java-based Instant Messaging packages Arkady: Investigate strategies for integrating JMS and CF Deliverables Now that the large components of the system had been defined, the team was beginning to get a better idea of all the work that needed to be done. They also knew the areas where more investigation was needed, and through the action items assigned to Jeff and Alex, they hoped to get some answers. With Allison and her team completing the HTML mock-ups and Jeff and his group putting the finishing touches on the high-level technical design, Robert felt ready to meet with JTG again to discuss their progress. As he prepared for this meeting, the team continued to produce a detailed technical design for each component describing its exact behavior and implementation. With these technical specifications in hand, development could begin.

Up and Running Software The Development Process

Up and Running Software The Development Process Success Determination, Adaptative Processes, and a Baseline Approach About This Document: Thank you for requesting more information about Up and Running