GSA
Headquarters
18th
& F Streets, N.W, Room 5141
Washington
DC 20405
Please send comments
or corrections to these minutes to Glenn Little at glittle@lmi.org.
Mr. Owen Ambur
opened the meeting by introducing himself and briefly explaining the day’s
focus. He, Mr. Marion Royal (co-chair), and Mr. Mark Crawford made several
announcements to the group.
Mr. Ambur:
NIST is planning a
workshop for July 26 concerning XML Namespace Management. [Editor’s Note: The contact is Judith Newton, at (301)
975-3256 or jnewton@nist.gov]
Mr. Royal:
Update on the UBL Library Content committee’s work.
The first UN/CEFACT XML paper is out for comment.
Mr. Crawford:
The next version of UBL’s Core Components is due out by the end of this month.
Update on the UBL New Design Rules. At their recent meeting, the UBL Design Rules Committee and the ANSI X12 Design Rules Committee held joint discussions. ANSI X12 is considering setting aside their rules and adopting UBL’s Design Rules. The rules are similar to those adopted by the EPA and the Department of the Navy, as well as the draft federal rules.
Relationship of ANSI X12 ‘s work to the XML Work Group’s work
EbXML Core Component Technical Specification work is starting. The Group meets at LMI during the week of 15 July.
OASIS is establishing a listserve for formation of an Education Technical Committee for education-based XML ontologies.
OASIS is forming a committee aimed at studying the Controlled Trade Markup Language (CTML). The first meeting is 21 June.
Mr. Royal: Bob Haycock was detailed to OMB to provide guidance for eGov initiatives, and more than that, to identify solutions for government-wide architecture. Bob’s with us today to give us a picture of his work. Bob?
Solution Architects Working Group “Overview
of Mission and Objectives”
Mr. Haycock: Good morning.
Slide 2: [Presentation Areas] I’d like to talk about three things:
1) The
Federal Enterprise Architecture Program Management Office (FEA-PMO)
effort
2) The Solution Architect Working Group’s (SAWG’s) charter
3) Component-Based Architecture (CBA).
Slide 3: [FEA-PMO - Discussion Topics] Marion mentioned my background. I’m with the Department of the Interior in Denver. I was given the opportunity to work with Quicksilver, and it was an eye-opening experience. The FEA-PMO was established in February of this year. Its objective is to establish the Federal Enterprise Architecture, and as you can imagine, it’s a daunting task.
In the two days I’ve been here, getting my mind around it has been interesting. It is starting to happen. In my 20 years in IT, it’s been the Holy Grail.
Slide 4: [FEA-PMO - Background] Our approach is to establish the Enterprise Architecture from the business model perspective, and we’re specifically aiming at the 24 Presidential Priority eGov initiatives. We created a Federal Business Reference Model. The initial iteration was in March of this year. We got lots of comments on it and revised it. That revision has been completed. We briefed Mark Foreman yesterday, we’ll be briefing OMB next week, Resources Management in two weeks, and the CFO Council in mid-July. OMB will use that reference model to see how investments line up with business functions.
We will also be developing models based on Business Performance and Application Capability. That work is going to start this weekend. The data gathering will start within a week. Finally, we’ll do Technology Reference modeling, and look at the agency information that’s out there.
Another big issue is the establishment of a Federal Enterprise Architecture Management System (FEAMS) to manage and provide information on architecture layers for OMB agencies to tie to their searches. That system is in place right now, but it’s not available for reading information. The objective is to get it out toward the middle of July (Web site for systems and downloading models for capital planning).
Unidentified member: Is this a variation of EAMS?
Mr. Haycock: Yes, it’s a roll-up at the federal level. The issue is, “How far down do you go at the federal level?” One big key objective is to advance that effort.
Secondly, we need to provide support for the 24 presidential eGov initiatives—help them figure out how they fit together across business lines—and get it done. The big issue last summer was to select initiatives that could be implemented in 18-24 months. Some came close, others not so close. The SAWG effort is to help those and implement in a way that they can leverage technologies and use components across the initiatives. The SAWG needs help in those areas. We need solution architects to help.
The two key initiatives are the SAWG and CBA. The last is to identify additional initiatives based on business model and [OMB Form] 300s. OMB has given us information on those and they’ve been linked through the business model.
Slide 5: [FEA-PMO - Accomplishments] Skipped.
1) Business Performance
2) Application/Capabilities
3) Technology and Standards.
Let’s move to the SAWG now.
Mr. Ambur: It’s already available on the xml.gov site, via a link in the agenda for this meeting. [Editor’s Note: SAWG’s charter is available at http://xml.gov/documents/completed/SAWG_Charter_v1.pdf]
Slide 8: [Leadership Team] This is the concept. It’s been in place for a month or two. It’s a work in progress. Norman Lorenz is the Chief Technology Officer for the Federal Government. This is the key element that is needed to advance the Enterprise Architecture.
There’s a Senior Solution Architect job that’s going to be filled. It’ll be a federal position.
Mr. Jim Benson (also of the FEA-PMO): We’ve put a lot of calls out with position descriptions.
Mr. Haycock: Solution architects are key. Marion is one, as are Tice DeYoung and Stuart Rabinowitz.
Mr. Benson: We had our first Work Group meeting a few weeks ago.
Mr. Haycock: It’ll require a bit more logistical work to figure it all out. We’ll meet about every two weeks. I have to identify a solution architect or two to get involved with at least three of the 24 eGov initiatives right now—Business One Stop and two others.
They’re broken out into five areas, with the idea that for each area we’ll have an architect that’s responsible for that specific area. As time goes on, we’ll bring in others with specific expertise. The idea is also to spread that out as widely as possible and bring in other groups to play specific operational roles in the design of the architectures.
Mr. Benson: We need to give special thanks to GSA for their help in all this.
Unidentified member: Is anyone responsible for the Registry?
Mr. Benson: Our thinking was that it would be Marion. We’ve had several conversations on the initiative, and how we leverage that. So far, it’s set up with Roopangi Kadakia across FirstGov, etc.. Then we have the skills, Marion for XML, and then security.
Mr. Royal: I want to reiterate that Bob is serious when he says they need help.
Mr. Haycock: Yes. Pass the word.
Slide 9: [SAWG Purpose] Again, the SAWG was created to assist the 24 initiatives. It was also created to figure out how you apply the architecture in a real world sense. The 24 initiatives need help. We want to avoid duplication of efforts—try to focus the technical expertise to act in concert—share, leverage, and reuse technology. It was also created to provide linkages to federal councils and work groups, federal, private, state entities, vendors…I’m learning how many of them are out there that need guidance, leadership, and oversight.
We’re also looking at development of testing practices. We talked about the possibility of setting up a test lab or “war room” to bring people together and test things, and to ensure that they follow good business practices.
Then we want to be a vehicle to bring in intellectual capital. A specific objective of the SAWG and the website is to bring in and host a place for intellectual capital.
Slide 10: [Objectives and Goals] I mentioned onsite visits. I can’t say enough how we need help.
Mr. Royal: For example, we had one initiative that rolled out too early. It had a lot of problems and they were already online. We learned from that not to put out deadlines that cause embarrassing situations. One of our SAWG people—Roopangi—came up with a system (a checklist) they should use before rolling out. It wasn’t hers—it was from FirstGov. So it’s a lesson.
Mr. Benson: This went from proof-of-concept to production in four days, with no testing. It went up at 8:00 AM and down at 10:00 AM. It showed us how many people hit on it (24,000), and it was a good lesson.
Ms. Lynn Hadden: What about state and local architecture? Most federal parks don’t have things like games listed. State and local parks have them. We need to consider those things.
Mr. Haycock: Yes, I’ve seen with CIOs that we need to link our efforts at that level, especially with regard to Homeland Defense. We won’t link architectures, but I think it’s like homeland security.
Ms. Hadden: Namespace management, information domains—we need to collaborate there.
Unidentified member: Is there an interoperability element or namespace design that’s going to come into play here?
Mr. Haycock: We specifically need to address that in information exchange and Web Services. You need to lay out the business and architectural model and tie that in.
Mr. Ambur: Regarding Lynn’s question, NIST is planning a namespace management workshop in July.
Mr. Royal: Lisa sent a message to the listserve.
Slide 11: (Mr. Benson): [Objectives and goals, continued] We need teams like NIST, that are focused on infrastructure, to help us with questions like, “What are they using? Should they be using ebXML?” We want to see this to get a handle on how people can get on the same sheet of music
Mr. Haycock: This is collaborative. We don’t see OMB taking it over. The issue is linking it all together. It’s a key issue. I mentioned the State-CIO connection. I’m meeting with Lee Holcomb regarding architectural issues with the Federal Architecture Work Group. We’re working together. Today’s meeting is to see how we accomplish that.
Slide 12: [Objectives and Goals, continued] This is a specific objective of the Architecture Work Group. The big issue is component-based architecture specifications, and a Component and Services Directory.
Slide 13: [Goals and Objectives, continued] Lastly, our objective is to provide training to the right people. For architects and architectural managers, this stuff has been there for a long time. The issue is using it effectively, getting it to decision makers, and communicating it to the right people with outreach.
Slide 14: [Component-Based Architectures] The third item I want to mention is that we’ve issued a white paper on component-based architecture. Jim will talk about specifics.
Mr. Benson: Thanks Bob. On the component-based architecture, I’ll stay at a high level. This is a thinking in progress, from a federal standpoint—how we leverage components better—and the technologies we have to do that. What is a component? You can go to a source, look at something in Java, download a workflow component, etc.. It brings together the data process and technology. At the federal level, we can better see how components satisfy business needs.
Slide 15: [Component-Based Architecture, continued] We’re looking at the attributes of architectures, so we don’t put out inappropriate guidance. The thinking was around reusability and interoperability when needed. We’re looking at industry-proven and emerging standards, like J2EE, .NET, XML, XML Web Services, and COTS tools and applications. XML and Web Services are the glue, the driving force behind this. How do we leverage it with COTS tools?
Slide 16: [Component-Based Architecture, continued] We’re looking at reusing technology. How can we reuse a Knowledge Management component—maybe an entire system or the discovery process and the algorithm behind the distribution of knowledge? We’re looking at reducing costs with legacy integration, program management services, and improving the quality of services.
Slide 17: [Business and Cross-Agency Solutions] There is a variety of different components, maybe a search engine…How do agencies make better usage of that?…User profiles…What are standards for e-authentication, accreditation, etc.? That’s true from a citizen standpoint, but in government services, it’s relatively easy. Are there ways we can assemble cross-agency to do that? How do we use it more effectively?
Slide 18: [Component Architectures Require the Use and Implementation of Technologies that are:]
◆ Cross platform and operating system independent
◆ Mature (not antiquated) and proven across the market
◆ Infrastructure independent
◆ Standards based (i.e., w3.org)
◆ Non-proprietary and extensible
◆ Easier to deploy and integrate
◆ Decoupled and loosely integrated
◆ Interoperable (when needed)
◆ Best practice enabled.
We tried to look at the technology, and create criteria. How and when do we leverage Web services, etc.?
Slide 19: [Foundations to Support Recommendations] We considered three main areas here. As you see here, Bob’s and Deborah’s team looked at the platform, data format, and messaging and protocols.
Slide 20: [Technologies Providing the Basis for Recommendations] We did a high-level analysis on a number of criteria. We realize there are others, so don’t take this in a vacuum. It’s just focused on the technology itself. Each has advantages, disadvantages, and risks.
Slide 21: [Advantages and Disadvantages Must be Weighed] In deploying these platforms, these all need to be weighed against each other. Web Services are not yet prime time, and Security Services aren’t where they need to be, but they can do some things, so as they mature we hope to get better values to be able to work with the agencies and use them effectively.
Unidentified member: Is that the 18 -24 month time frame, or will these things be matured during the time frame of an Enterprise Architecture plan longer term?
Mr. Benson: Especially from an EA standpoint, yes the thinking should be there.
Mr. Haycock: We’re looking at milestones, and that’s the idea of the architecture:—How does the technology help us get there?
Mr. Benson: For example, the U.S. Customs Border Patrol wants to validate driver licenses at the border, and understand how much, say, a truck full of bananas should weigh. We should be able to enable those services, rather than thinking of integrating systems through, say, EDI. Web Services could maybe help that.
Unidentified member: Microsoft versus J2EE grades on the slide—why did Microsoft get an A and J2EE get a D in complexity on your assessment?
Mr. Benson: This wasn’t cookie cutter. It just means that maybe you need to tailor your plans to the solution. Nothing is completely right or wrong.
Slides 22-25: [Logical Architecture: J2EE, Web Services] These are examples of implementations for single architectures. There will be multiples down the road. Susie, if we can do these better, let us know.
Slide 26: [Tiered Solutions for Reuse of Components] When we develop applications or initiatives, how should we think about it? A system of tiers and layers. We move to the end tier architecture to exchange business logic—we move away from, say, HTML to XML or XSL without affecting underlying layers. There are applications that take all four or five layers and move to a single script, so it’s a process.
Slide 27: [Next Steps] This is a framework. It should and will evolve. Please contact us for questions and input.
Mr. Haycock: As we continue with the next steps, we’d like to accelerate linkages. Maybe the SAWG and Federal Enterprise Architecture Office can help. We may expand the capabilities of the SAWG. We’d like to be able to assign a solution architect to each of the 24 initiatives. We need to look at ways to get the intellectual capital out there to the appropriate businesses, and we need to further study the Component-Based Architectures.
Questions?
Mr. Ambur: One concern I’ve had regarding the Registry is the process for reviewing and adding value to that which is registered. DoD and DISA started with the notion of Namespace Managers and found it didn’t work. The Project Managers had the money and imperatives and deadlines, and they didn’t want to take the time or trouble to bow down to the Namespace Managers and wait months for a decision. For our pilot of the Registry, we’re going to do a cursory review to make sure submissions are not pornographic or illegal, but that’s all. At this point, we don’t have the resources to conduct any significant coordination or oversight. Perhaps the 24 Solutions Architects might be candidates to use the Registry to look for coordination opportunities.
Mr. Benson: There is synergy with the Federal Registry, XML.gov and their registry, and the Federal Enterprise Architecture. It would be nice to understand how the vocabularies’ schemas are supporting the business. It could get to the point where we could tie linkages from capabilities through the business line.
Mr. Ambur: Regarding your knowledge repository, I wonder a little about the SAWG’s references to FTP and email as bases on which to compare J2EE and .NET as the recommended platforms for the eGov projects. We’re all being overwhelmed with spam and porno. We can’t associate metadata with email and manage it effectively as records. We receive redundant copies of huge attachments, such as of PowerPoint files, which fill up our storage allocations and force us to dump messages we may wish to keep. So I’m not sure that email is a good foundation on which to build eGov applications. In addition, with respect to FTP, I contacted Jim Whitehead, the Father of Webdav, to ask whether anyone has compared its features to those of FTP. He plans to draft a white paper and, as soon as it is available, I will share it with the group.
Mr. Benson: The initial thinking was to send it over FTP. It takes collective leadership. It’s just there as a framework. If we can get a common understanding of how Web Services can support a business, we can get the most effective use of it.
Unidentified member: Some agencies move to clock and data. I didn’t think TCP/IP was ready.
Mr. Haycock: You’ll see growing focus on simplifying and unifying. OMB is intending to encourage movement this way through the budget process, so the synergy is going the way we want it to. It also takes some encouragement.
End presentation
Mr.
Terry Bjornsen
Booz
Allen Hamilton, “Business Case for the XML.gov Registry”
Mr. Bjornsen: Owen, perhaps you can give a minute or two “level-set” to the group about how we were brought in to the Registry work?
Mr. Ambur: Certainly. GSA realized that this isn’t just a small application we’re going to put up and play around with. It has business-critical implications for government agencies nationwide, and we need to have a clear understanding of the requirements and implications. So GSA conducted a solicitation and selected Booz Allen to put together the business case. We recognize that the real target is the decision-making process, the A11 process, as documented in Exhibit 300, the capital asset plan and budget justification.
Mr. Bjornsen: First I’d like to introduce Misty Jordan, John McGady, and Mark Miller. The four of us are charged with the strategy and business case for the XML Registry/Repository. What we do, which is the way we handle all such projects, is that we look at the business case from a return-on-investment perspective. We look at the benefits and who manages it, etc., before we can cost something out.
I have a brief presentation, and I encourage questions. Our purpose is not to be prescriptive. We’re not here to say, “Here’s the Registry solution and here are the costs.” Our aim is more to be sensing and synthesizing your input—NIST, Enterprise Architecture, etc., and cost it from a strategic standpoint, so your involvement is critical.
Slide 1: [Agenda] First, I’ll go over the task. It’s a high-level outline, to see what we’re here to produce, and a snapshot of our preliminary findings, the discovery process…we go through a few iterations of a synthesis, then reflect back to say, “This is what we’re hearing.” Often when you first do this, you get surprises, which is all good. It helps us create a more holistic solution. Then we’ll do a bit on next steps.
Slide 2: [Project Staff] We do have significant background in this area. I have a background in the commercial sector. I ran a supply chain analysis for Tier 1 automotive companies, and I have a lot of time in messaging standards.
Michele Quadt isn’t here right now. As we coalesce the scoping, we’ll involve our quantitative analysis people. We typically backload this into the process when we have the information. I got this presentation to Owen late, but it will be on the GSA website.
Slide 3: [Project Objective] We’re learning about a lot of things that are outside the realm of our work. As we get coherent information, we’ll work with Owen to get on the XML.gov website, so as we go, you’ll be able to see our progress. It’s important for you to see, to see if we’ve left your initiatives out. On the Registry requirements and use cases, we’ve had some preliminary conversations, and seen a few use cases at the ebXML level with their registry work. That’s the level where we’d plug in, and probably produce use cases for how data or objects within a schema can be used. We think that mirrors the ebXML site. The idea is a business case, and the design would happen as a result of that.
Once the requirements are put together (by the way, we did 14 of the 24 Quicksilver use cases, so we have lots of experience with those initiatives), the standard format is to identify different strategies or alternatives, keeping in mind the target, and suggest several alternatives. Then we do a financial analysis and strategy. Those would support the OMB 300.
Slide 4: [Activities Thus Far] We did a kick-off in May. We’ve contacted Ray Morgan and Dan Allen from NIST, Lisa Carnahan, Owen, and Marion. They’ve been the initiators. We’ve done a fair amount of background research. We’ve contacted over 20 people, and we’re through with conversations with eight or nine. If you’ve been contacted, please respond. If you’d like to participate, contact us through the XML.gov website. We hold status meetings every Thursday. We’re also doing research with standards committees. I’ve spoken with Bob about the SAWG. After today, we need to talk more often about the fit with some of his efforts. We’re also contacting OASIS and ebXML, for example.
Slide 5: [Business Case Outline] This is a strawman outline. Part of it’s data driven, so as we learn more, it may change. I’ve added some things specific to Registry/Repository. Outside of the SAWG and XML Work Group, the knowledge level of XML potential and registry and value propositions isn’t that great. It looks like any other technology.
We need some more background to be educated in the way we can help people understand what they’re seeing. Then a bit about the role of the Registry/Repository. There’s not just a single view of what it will be. We need to determine who the customers are, and who will get value out of it. For some, the focus is developers; for others it’s third-party application providers, or records-management people. There’s value in looking at each type of customer.
We’ll need to come out with something on the governance model. Who runs it, decides what’s a valid schema, etc.. Owen said “maybe solution architects” in some realms. There’s a cost associated with it. That must be part of the business case.
How do we accommodate evolving technical standards? We don’t know what it looks like, but it’s clear that there are different initiatives. We need to say, “Here’s how the Registry will come out,” and ensure that it’s not eclipsed. If you hear that there’s a group doing the XML Repository work, it’s OMB Form 300 that says what we’re doing. If you think there are other aspects that need inclusion or scope changes, let us know.
Mr. Bruce Peat: How about risk?
Mr. Bjornsen: Risk is within the Strategic Alternatives, on the strategy side around evolving standards. We look at risk as part of the cost/ benefit analysis. We consider risk in terms of, “Should I take an alternative?”
One alternative is, “Don’t do this.” It’s a stock alternative. We can also put in, “What are the risks of not doing it?” It’s typically the way OMB is used to seeing risks.
Mr. Steve Vineski: You indicated you’re doing a requirements piece. Are you looking at the fit from that perspective, in terms of what it will do?
Mr. Bjornsen: Yes, we look at, “Where do you draw that boundary?” You must bound it to a degree before you can do an economic analysis.
Mr. Vineski: “Role” seems broad. If it’s gauged in terms of requirements, it would help.
Mr. Crawford: Would you share your interview list? Because we may have some feedback. We’ve done it with requirements for the EPA and the Navy.
Mr. Vineski: EPA has a State/EPA work group working to develop requirements for a registry/repository. The time frame is the end of summer. Larry Fitzwater pushed to get it done earlier.
Mr. Bjornsen: Yes, we’d be very interested in discussing that.
Mr. Crawford: DoD just finished a data call on requirements from Services to enhance the DoD Registry.
Mr. Ambur: You already know about the Global Justice Network?
Ms. Pat Smith: What is the time frame?
Answer: The end of September.
Ms. Smith: Who hired you?
Mr. Ambur: I think we should leave any discussion of the contractual arrangements to GSA. [Mr. Bjornsen concurs.]
Slide 6: [Snapshot of Key Data Points and Issues] These are snapshots, not baked conclusions. It’s a work in progress—information from some people we’ve talked to. We still need to synthesize the information. The first bullet talks about the necessity for the human element. The second bullet discusses how point-to-point business services offer higher value than just an XML specification.
I expect to hear reaction, and I hope you do. Let’s get different opinions into this. So far, it’s been clear that having a single Federal XML Registry is a question. Many folks think, “Is this feasible?” Drop down a level, and people think that interoperability between registries is critical, then we get to definitions about registries. Moving forward with one is not where a lot of people are thinking.
Mr. Crawford: I suggest that the ebXML concept for a registry of registries is the best way to sum all that up. It fits well with component-based architectures.
Mr. Walt Houser: The alternative would be peer-to-peer.
Mr. Mark Miller: We’re hearing a lot of people say they would like the benefits of a centralized registry, yet they also recognize that a distributed registry is going to evolve. We’ve even spoken with the Navy, which is saying they’re considering building their own. It’s hard to say what it will look like. Will they all be ebXML-compliant, and if not, will they be able to interoperate? Those are all things we’re looking at.
Mr. Bjornsen: The last bullet point is one we need to address. “We haven’t given a lot of thought” is what we’re hearing from people.
Slide 7: [Snapshot of Key Data Points and Issues, continued] We have to define what the role of the Registry is and isn’t. Some people think it’s too early to bet around ebXML, because Web Services will be the driver. If so, UDDI and WSDL are more important, so there’s obviously conversation about the realm—and in order to make the business case, we need to make a demarcation. Our early guidance is to stay around the ebXML schema.
Is there a process for standard element descriptions, or do people just register? And then, how are they publicized and shared? So far, people believe a top-down process is not a feasible approach.
Mr. Crawford: To what extent do you give credence to the GAO Report, which says the opposite?
Mr. Bjornsen: It does say the opposite. We’re collecting data. We need to study what we think the realistic approach is. The good thing is that people tell us what they think is feasible, rather than describing a utopian ideal.
Mr. Miller: Some members see it as evolutionary; over time, there would be collaboration and standardization as to which element is the official descriptor. At least they know they exist, rather than not knowing.
The next point is about conversations about ebXML and its ability to be leveraged. It’s still forming. Also—a few people mentioned something around the security model. The heavy-weight security model could be a deterrent. Clearly, though, ebXML could represent a starting point for us.
Slide 8: [Purpose of an XML Registry/Repository] These reasons are all going to go to areas in a business case that we associate benefits with.
Mr. Michael Jacobs: What is the classification scheme? Namespace?
Mr. Miller: Yes
Mr. Bjornsen: We also see it as storing metadata and data definitions, and there’s also the possibility that agencies could actually store public information, such as things like quarterly reports, as actual XML files in the Registry.
Side 9: [Purpose of an XML Registry/Repository, continued] OK the first bullet—this is something we have to understand from the role and scope perspective. Is this necessary for a repository or not? We have to find this out.
Slide 10: [Value Proposition of an XML Registry/Repository] Where does value exist in doing this at all? We can start to derive our different benefit areas. For the second bullet point [Stronger descriptions and classifications of functional lines and definitions in the federal government improve overall government efficiency], we need to coordinate with the SAWG.
For the third bullet [Creation of policies and procedures allowing registries to interoperate enable distributed, collaborative registries that support agencies working together with more agility and flexibility rather than reinventing the wheel each time data is exchanged], when you have a registry, you have to have governance in place—and by so doing, it’ll increase interoperability opportunities.
By talking with the SAWG, we see better opportunities to synthesize and bring together cross-government XML initiatives.
Slide 11: [Next Steps] Again, if we have contacted you, please do get back to us, and if you have some information that you think we need to know, let us know. This is just a snapshot. We need to synthesize the appropriate information, vet out the themes that we think apply, and determine what the proper scope is for this. What we plan to do is to come up with a first document saying, “Here’s what the Repository is, here are the key properties,” and start to have comment on that.
On the third bullet—We need to work with the SAWG, and get closer to Patrick Gannon than email, and start the writing so we can commence the iterative process. We want to complete the information-gathering by the end of this month, and then spend time in July to synthesize and reflect on what we’ve heard. This isn’t something like Quicksilver. In this case, there’s much more variation on the target, role, benefits, etc.. We anticipate iteration to reflect what everyone thinks, and to support initiatives.
Mr. Benson: You say that the Registry/Repository is interchangeable. Mark says it’s a registry of registries. To you, is the Registry the scope, or is the Registry/Repository the scope?
Mr. Bjornsen: We could spend ages on this issue alone. It’s a key issue. The early thinking was an XML Registry. Now we’re looking at a registry of registries. Then there’s the Registry/Repository going on, which ebXML is working on. Right now, the target is fluid. That’s part of this scoping. We need to decide, “What do we need to produce?” It’s the combination of the two, in some form that works for everyone. It’s a key issue we’ve found early in the process. There’s not one mind as to what the target is.
Mr. Houser: I have concerns about the hierarchical model of a registry of registries. I highly recommend that we look at peer-to-peer. I think Booz Allen has some type of tool for collaboration. Is that available?
Mr. Bjornsen: Initially it was on the table as something we could use. Subsequently we found that we’re converting from Webworks to Live Link. We’re in the middle of a blackout where they’re not adding users to either. Owen and I discussed using XML.gov to publish drafts and then use the mail list for comment. If someone else has a vehicle you want us to use, then great.
Mr. Houser: Then the email list would be a good tool. I want to make sure that the peer-to- peer is recognized. It has desirable features, and I recommend it be considered. I also recommend you talk to Brand Niemann.
Mr. Bjornsen: We have him on our list. We haven’t yet connected, but we’re hopeful that we’ll be able to talk to him soon.
Mr. Ambur: OK, are there any other questions or comments? … Do you have good contacts for BizTalk and the UK’s GovTalk program?
Mr. Miller: We’ve established contacts, and we’re having a meeting soon. We’re open to meeting with you or Marion, if you’re interested.
Mr. Ambur: Sure.
Mr. Crawford: I’m not sure Patrick can give you the OASIS stuff. The OASIS Registry Technical Committee has several local members who may be able to give you some good information.
Mr. Bjornsen: We also talked to Lisa Carnahan.
Mr. Crawford: And David Webber, and Joe Chiusano.
Mr. Bjornsen: We’ve spoken with David, but we haven’t yet connected with Joe. We still hope to do so.
Mr. Bruce Bargmeyer: It’s good to harmonize between ebXML and other registries, for deeper semantic discussions.
Mr. Crawford: Some of what Bruce is talking about is in EPA’s registry report.
End presentation.
Mr. Ambur: Other questions? We’re right on time then. Thank you, Terry. Our next presentation is by Martin Smith of the International Trade Commission. Martin is a co-founder of this Work Group. When I made a couple suggestions on how the government might take advantage of the potentials of XML, Martin suggested I approach the CIO Council with them. I did so and this group was chartered as a result.
To provide a little background while we’re waiting for Martin’s presentation to be set up, last month we received a presentation concerning Web Services interoperability standards. We had hoped to hear from Martin them, but due to a scheduling conflict, we scheduled him for this month instead. He and his associate will brief us on the Web Service pilot they have developed for the Harmonized Tariff Schedule (HTS).
Mr. Martin Smith: One of the jobs of the Architecture and Infrastructure Committee (AIC) is to pick out the next big thing and position government to make effective use of it. I think you’ve done a really good job, in spite of GAO’s comments, in the XML space. It seems to me that Web Services is going to happen, therefore the AIC should have an initiative in that area. I brought it up in March at the meeting, and the response was. “Tell me more.”
In response, I volunteered to try to develop a demonstration application and a general presentation on the subject, bring it to a working level first, practice it, then take it to the full committee and do it again, to see if the committee would be interested in taking an action to have an initiative. We ended up doing the executive level first (last week), then we’re coming to technical folks this week.
The key question is, first of all, “Are we saying anything that’s wrong?” Secondly, is it worthwhile, such that the AIC needs to form an initiative in this area? Third—if so, does it make sense to make it part of this group, since the technology is closely bound to XML?
[While waiting for the presentation to boot, Mr. Ambur mentioned that Mr. Smith had headed the government-wide directory group, including the White Pages effort.]
Mr. Smith: The White Pages [site] is down right now. First of all, it doesn’t have money, so it’s in maintenance mode. The important thing is that it’s a possible path to the e-authentication concept. We’re trying to see if there are lessons to be learned there. Though the directory work started as messaging, the focus is moving from email to other areas. How that’s built into your architecture is important, and I’m struggling with who to engage in the conversation in the agencies.
Presentation
Madhu
Siddalingaiah
XML Working Group: Web Services Initiative
Mr. Siddalingaiah: In talking about how this should be managed, when I think of XML I think of data; when I think of Web Services, I think of the people involved.
Slide 2: [Goal: Understand Web Services’ Potential] Martin went through the specifics—as opposed to previous presentations, today’s involves details for implementers. Some of the information, like what we did for HTS, will also be presented.
Slide 3: [About the Presenter] A little background on me—I’m a consultant. I primarily focus on Java and XML. I was in government for many years. I’ve been in the private sector now for about seven to eight years. I got into Java in ‘95.
Slide 4: [What are Web Services?] In this time of distributed computing, it’s similar to CORBA and others. You can have an application server, and you can use any language. You could have an application server, such as with J2EE or .NET, with some business logic that presents Web applications that send HTML to a user (Business- or government-to-consumer). We could repurpose it to XML for computer-to-computer, and some business-to-consumer. We could aggregate it for an end user.
Slide 5: [Advantages of Web Services] It’s cross-platform, cross-language, based on independent standards, and has multi-vendor support. The biggest part is that it’s relatively simple. It’s text-based rather than binary, loosely coupled, doesn’t require a persistent network connection, and over a WAN it works better than a system requiring persistent connections. It’s a zero-latency enterprise. Theoretically, you could look up a service in a directory and interact, without any prior relationship. That’s for the future. Right now, we can at least perform the communications. It’s loosely coupled. You only need port 80 or an email port to make it work.
Slide 6: [Challenges to Web Services Implementation] The specifications are not yet 100 % complete. They’re still evolving. There are some things being done in ebXML that people would like in SOAP and Web Services. Security aspects are being worked out. There’s a lack of schemas. There aren’t as many as we’d like. Ideally, if there was one for trade data we would have used it in our demonstration. There are educational problems, like “What’s in it for me, what are its capabilities?” There are problems with standardization, political problems, etc. Some standards may not be adopted.
Slide 7: [Web Services Protocols] It’s all based on XML. SOAP is the mechanism of transporting the data. WSDL is a way of describing the services. It’s an interface document, similar to CORBA. It’s XML, though, so it’s easier to transport and parse. It is hard to read though.
You can go to UDDI.org to find out about it. The big issue still to be resolved is to establish trust between the different players.
Slide 8: [SOAP] So what is SOAP? There’s “DOC” style or “RPC” style. There are two lines of thought about the way it should be done. People may do one or the other. We’ve done an intermediary. There are also questions about data types, and how it’s actually transported—HTTP, SMTP, etc.. HTTP seems to be predominant. It’s just like a Web browser, but the client is another machine rather than a Web browser.
Slide 9: [WSDL] This is much like a Web browser, as described in the first bullet. It’s typically used on the client side. Someone who generates a service will generate it and provide it to a client. In the future, maybe be in a registry, that’s where UDDI comes in. You can write it, but it’s kind of painful. There are tools that can do it. Java has a tool that will generate it. It can also go the other way as well. Given WSDL, it can generate the code.
Slide 10: [UDDI] This is sort of like a Yellow Pages. This is the least mature of all of it. Where it’s going to go is up in the air. The other two parts—SOAP and WSDL—are what’s in use today.
Slide 11: [Getting Started With Web Services] You might want to go with an internal project you already have—maybe read-only information you already have. Another possibility is to find a partner that can use it. You’ll find they maybe want different information from what you’ve done. Candidates might include entities with security issues.
The first two items are there because of immaturity of the protocol. Once you get a billing method attached to it…in the future these limitations probably won’t exist.
Slide 12: [Harmonized Tariff Schedule] A little about what the Trade Commission does. There’s a huge list (20,000 items, 2000 pages) used by brokers, like Walmart, and other large concerns. It’s currently in hardcopy—PDF (authoritative) and browser (non-authoritative). This is what we use to model our service after. It’s free, can be used by many, and builds on what we have.
Slide 13: [Current vs. Web Service Workflow] It appears that now it’s hardcopy and rekeyed. That’s time-consuming and creates room for inaccuracies. It’s sent to importers, or brokers, maybe in data tapes or proprietary methods. The Web Services model shows that we can send the XML information without a prior relationship. We can send to Customs or brokers, and they can set up their own service if they want.
Slide 14: [Prototype Architecture] The J2EE server is available at the link on the screen. We’ve exposed only two of the methods. We showed that the process hooks into the tariff database, formats it, and sends it out on XML. It’s similar to an ASP application that does the same thing and generates HTML. Why not use HTML? It doesn’t conform to schema, we could lose style information, etc..
Mr. Smith: Another thing is that it gets humans out of the loop—creates application-to-application interoperability.
Mr. Miller: Would this be motivation for another application server?
Mr. Siddalingaiah: We had to install .NET.
Mr. Benson: When you publish the UDDI directory, what would be published? The two descriptions of what these methods do?
Mr. Siddalingaiah: Yes, I have a slide on it.
Slide 14: [Development Process] How it was developed—it started with a Java interface with the two exposed methods. There were two things: the interface and some configuration details. It generates lots of code and WSDL. The code develops stubs and skeletons (just plumbing code), and translates XML to Java or Java to XML. From the point of view of the implementer, it’s just Java code. There’s no SOAP or Web-specific stuff in there. The process is to write an implementation that will work with ebXML or Web Services. We include a SOAP library. All this is combined and put on our server.
Slide 15: [WSDL for HTS] This is an example of the code. It’s a reduced version. This is the interface—the XML that a client uses to generate his code.
Slide 16: [XML Schema for HTS Detail Response] This is more code for the document that comes back if someone requests information for a particular product.
Mr. Smith: We took an existing Web page ,with an ugly SQL statement. Madhu wrapped it into his language and that was it. We should develop a more comprehensive schema, but for the first effort, this was it.
Unidentified member: Have you looked at Apache?
Mr. Siddalingaiah: Yes. We have no particular reason not to use it.
Slide 17: [References] There are also a lot of primers and case studies on these websites. IBM and Microsoft want to promote their products. Sun also has some material. Xmethods.com is also a good site that shows good uses of it.
Mr. Royal: I want to point out that when I did introductories of Web Services, when I took my boss to the Xmethods website it finally clicked on how good it really was. I had him pick one. He picked “validate address.” I purposely gave him the wrong address, and it came back as wrong. When I gave it to him right, it came back validated.
Mr. Benson: Is the description of what it does part of the XML strategy? The ability for the first responder to get out there and understand some of these imports, whether it’s rolled into UDDI or another form of registry?
Mr. Royal: I see it as separate. The Registry/Repository we’re doing is ebXML, which is slightly different from the Web Services the way it’s evolving.
Ms. Hadden: I spoke with Peter Aiken from the Institute of Data Research regarding whether we do an ebXML or UDDI repository. He thought they could be done together.
Mr. Crawford: You have to look at the time frame. There is some overlap, but not a lot. They’re different functionalities. As ebXML Phase I wound down and UDDI came out, the UDDI looked at the possibility of leveraging the ebXML. There is a white paper on how to leverage them. There has been synergy. With UDDI, they did participate with ebXML to an extent, but it’s fallen off recently. Regardless of what we come up with in the business case for an ebXML registry, the comprehensive architecture you’re looking at needs to look at it from both perspectives, but I see them as two different efforts.
Mr. Royal: How doe we put this WSDL into the ebXML Registry? On the other hand, the UDDI is for discovery on storage. Maybe we need both, but this business analysis is not for both.
Mr. Smith: You can go a long ways down implementing a Web Service with knowledgeable clients without confronting the registry issue. This is looking forward to the time when you can do it without prearrangement.
Mr. Crawford: It’s not a bad path. Another issue is the closed nature of the ebXML effort. Hopefully over time they’ll harmonize with W3C and OASIS.
Mr. Ambur: So what do we do with this? We talked at the last AIC meeting about what organizational structure we should use. I think it’s not the structure that’s so important, but who steps forward to take leadership. I would be more than pleased to have them under this working group or, if they’d like, they could also report directly to the AIC.
Mr. Smith: It goes back to the core issue of their natural interest.
Mr. Ambur: Comments or suggestions?
Mr. Benson: Maybe it’s something that the SAWG should champion from the perspective of leveraging business and rolling it into the architecture.
Mr. Vineski: The EPA and States have a node protocol developed specifically for services, including UDDI. It goes across the board and out west with stuff that States can use. I can talk to them.
Mr. Crawford: The DON has a huge Web Services effort under way with their Task Force Web.
Mr. Royal: Internal or external?
Mr. Jacobs: Internal, with the thought of the final architecture being external.
Mr. Crawford: They’re well on their way.
Mr. Smith: Would someone collect input on who’s interested?
Mr. Ambur: I’d suggest that someone post a message on the listserv and see who wants to participate.
Mr. Crawford: Glenn will take an action item to post a message on the listserv for people to contact Glenn if they’re interested. The type of data you’re exchanging—there should be a relationship with the OASIS Controlled Trade Markup Language Technical Committee.
Mr. Smith: We did a quick world tour, and sent messages to the ebXML people and to UBL. They all said “Go away.” That’s why we did our own.
Mr. Crawford: This is a new committee. Their first meeting is next week. There should be cross-pollenization, also with the World Customs folks.
Mr. Ambur: Although I haven’t pinned down the speaker yet, next month we’ll have a presentation on the OpenOffice.org. The August meeting date is open. I’m thinking of taking up the brainstorming ideas generated in follow-up to the GAO XML report. Also, our current charter lapses in at the end of this fiscal year, so we’ll need to consider it at our meeting in September. If you have other agenda suggestions, let me know.
I also want to mention that we’ve been contacted by Lew Oleinick of OMB, who’s on detail to the Department of Education. He asked about our interest in cosponsoring an event with the Information Technology Association of America (ITAA). In addition, Tony Byrne, who is providing consulting services to GSA’s FirstGov concerning content management, suggested we cosponsor a forum to hear from early adopters of XML content management solutions. He’s agreed to try to put together such a program. Finally, we have a tentative agreement with the IdeaAlliance for a July 18 forum on PRISM, ICE, and RSS.
Our next meeting us July 17 and the forum is on the 18th.
Action Items:
Mark Crawford is to place the address for the new OASIS Education Technical Committee listserv onto the XMLWG listserv.
Glenn Little is to send a message to the XMLWG listserv soliciting volunteers to participate on a prospective new committee aimed at investigating the appropriate niche for Web Services.
Attendees:
|
Last Name |
First Name |
Organization |
|
Abel |
Elizabeth |
OFHEO |
|
Adams |
Susie |
Microsoft |
|
Ambur |
Owen |
FWS |
|
Bargmeyer |
Bruce |
|
|
Benson |
Jim |
OMB-FEA.PMO |
|
Billups |
Prince |
DISA |
|
Bjornsen |
Terry |
Booz Allen |
|
Callahan |
John |
Sphere |
|
Church |
Allen C. |
ERA-NARA |
|
Crawford |
Mark |
LMI |
|
Dodd |
John |
CSC |
|
Hadden |
Lynn |
Fairfax County |
|
Haycock |
Bob |
OMB-FEA/PMO |
|
Houser |
Walter |
Veterans Administration |
|
Jacobs |
Michael |
DON CIO |
|
Johnson |
Denise |
ORC-Macro |
|
Jordan |
Misty |
Booz Allen |
|
Lewis |
Mercedes |
Treasury FMS |
|
Marshall |
Jack |
Census |
|
McKeever |
David |
Computech |
|
Miller |
Mark |
Booz Allen |
|
Morgan |
Roy |
NIST |
|
Peat |
Bruce |
eProcess Solutions |
|
Pittman |
Ken |
BAE Systems |
|
Royal |
Marion |
GSA |
|
Siddalingaiah |
Madhu |
Aquarius |
|
Sirmons |
Chandler |
DFAS |
|
Smith |
Pat |
Treasury FMS |
|
Smith |
Jonathan |
|
|
Smith |
Martin |
USITC |
|
Swizzingen |
Sandra |
|
|
Turnbull |
Susan |
GSA |
|
Vineski |
Steve |
US EPA |
|
Weber |
Lisa |
NARA |
|
Weiland |
John |
|