By itself, XML is a simple syntax for exchanging data and text-oriented documents, but successful business communication involves more than just a lingua franca. Electronic commerce requires shared models of the underlying domain semantics, business processes and policies. These models are the very essence of business-to-business (B2B) integration. A model may be embedded in the code of an application program that processes the XML documents, or made explicit in the definition of the model's concepts, relationships and constraints.
This is the first in a series of articles in which I'll cover three aspects of modeling e-business applications:
(1) Processes and communication policies. B2B interactions are not limited to sending a single message, but require a coordinated sequence of the business partners' activities and expectations.
(2)Business vocabularies. Each message contains information that may be concise or convoluted. Such content documents are defined by a vocabulary that is shared by the parties engaged in the communication.
(3) Web service components. The techniques for applying component-based design to Web services are still emerging, but I'll share some early thoughts about their impact on future development.
XML documents are increasingly used to represent and exchange both process and content information when deploying these applications. Process information includes the messaging infrastructure and workflow control that guide the process execution. Many B2B processes are asynchronous and long running, so the XML-based message header information identifies the parties, process and purpose of the message. Business vocabularies define the heart of the message: its content. For our purposes, I'll use a product catalog as an example content vocabulary. The catalog data is exchanged in messages between business partners when aggregating catalogs from multiple suppliers, or when responding to queries for product specification data. The same catalog content is also transformed into HTML for presentation in customer portals.
But an XML application is much more than structured data—it's part of a broader system that includes both architectural and process requirements. Most e-business applications include requirements from both business and technical stakeholders that are distributed across an inter-enterprise system. Developers of these systems benefit from visual models and a process that encourages active communication. Let's face it—the business world revolves around graphical presentations, so any XML specification diagram is a great help.
In these articles, I'll attempt to walk the middle ground shared by three diverse groups of developers. The first consists of companies that have embraced the Unified Modeling Language (UML) and the Rational Unified Process (RUP) as a foundation for software development, including XML applications. The second comprises those developers seeking lightweight processes—such as agile modeling or extreme programming—but still interested in using UML for well-defined goals. The third group consists of XML application developers who are skeptical about the value provided by any graphical modeling tool or technique, including UML.
I'll gravitate toward an agile modeling process that can be included within a more structured methodology, like RUP, or applied independently for quick results when designing an XML schema or set of Web service messages and workflow processes.
更多軟考資料請訪問：考試吧軟件水平考試欄目
希望與更多網友交流，請進入考試吧軟件水平考試論壇
