Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API
XML and SOAP have opened the gates for e-business communication in the purest sense by allowing applications to truly interoperate. But they have proved insufficient in enabling a global electronic marketplace and making available information about the following key elements of a global e-business infrastructure:
A global e-business infrastructure today is composed of a complex web of transactions and information exchanges among several diverse organizations. Each organization interacts in a unique way with another organization, introducing severe complexity for enabling this information exchange in an efficient and secure manner.
The two key standards that strive to overcome this challenge are Universal Discovery, Description, and Integration (UDDI) and Electronic Business using Extensible Markup Language (ebXML), both managed by the Organization for the Advancement of Structured Information Standards (OASIS). Both paradigms support the notion of the discovery of a business service provider, its Web services, and the available technical interfaces. However, while UDDI focuses more on the discovery of business service providers and their services, ebXML focuses on both the discovery and the collaboration of business service providers, as well as the discovery of their respective services.
This article concentrates on the ebXML implementation foundation, which is made up of four components: messaging, collaboration profiles, business process, and metadata registry.
The ebXML Collaboration Protocol Profile and Agreement (CPPA) standard plays a key role in an ebXML registry by providing a mechanism for specifying the details of how to support B2B integrations. It includes the details for transport, messaging, and security constraints and also specifies the bindings to a business-process specification document, which defines the business interactions between two partners. This bottom-up approach of including the business stakeholder in an integration right from the start enables any business entity to build a scalable and flexible system, ensuring information exchange occurs seamlessly. According to the specification:
"the objective of this specification is to ensure interoperability between two Parties even though they MAY procure application software and runtime support software from different vendors. The CPP [Collaboration Protocol Profile] defines a Party's Message-exchange capabilities and the Business Collaborations that it supports. The CPA [Collaboration Protocol Agreement] defines the way two Parties will interact in performing the chosen Business Collaborations. Both Parties SHALL use identical copies of the CPA to configure their run-time systems. This assures that they are compatibly configured to exchange Messages whether or not they have obtained their run-time systems from the same vendor. The configuration process MAY be automated by means of a suitable tool that reads the CPA and performs the configuration process."
This article will also showcase the advantage of using a flexible and high-performance native XML database management system along with XQuery to enable rapid and evolving loosely-coupled collaborations among trading partners within and across enterprises.
The OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee is the author of the OASIS ebXML CPPA specification, one of the technical specifications of the OASIS ebXML suite of standards, a standardization effort lead by UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) and OASIS.
In December 2002, ebXML CPPA Version 2.0 was ratified and approved as an OASIS open standard. There is also an Editor's Draft dated April 2005 for maintenance purposes.
Though ebXML is an extremely powerful approach, it has been relatively slow to attract wide industry adoption. In our opinion, organizations are still waiting for others to take the risk of trying emerging technologies. The project's strongest support comes from Sun Microsystems. While it is an important member of the OASIS standards body, IBM has been somewhat noncommittal; and Microsoft does not even support the ebXML initiative.
Collaboration Protocol Profile (CPP) defines the technical information about the interfaces, business capabilities, security constraints, messaging, and transport protocols the trading partner uses to do e-business. All trading partners register their CPP documents in an ebXML registry or similar repository so that other trading partners can discover them and understand the supported process. A trading partner can be represented by multiple CPP documents.
In a CPP, the ProcessSpecification, DeliveryChannel, DocExchange, and Transport elements define how a trading partner's business unit can be processed. The ProcessSpecification element specifies the trading partners who can send requests to each other and the order of the requests. As shown in Figure
1, the DeliveryChannel element specifies a trading partner's messaging capabilities. A trading partner can define any number of messaging characteristics
supported in the CPP. The DocExchange element defines how a business document is processed, which includes encryption, digital signature, and reliable messaging.
The Transport element defines the transport protocols to be used while sending business documents, the endpoint addresses, and other properties
relating to the transport protocol used.
These pieces of information take into account, for example, the correct HTTPS port to access a company's ERP (enterprise resource planning) system, the document standard used to exchange business information, and the sequence in which the business documents should be exchanged.
Figure 1. The XML elements in a Collaboration Protocol Profile. Click on thumbnail to view full-sized image.
In this article, we provide only a brief overview of the CPP's key elements, as shown in Table 1.
Table 1: Key elements
<CollaborationProtocolProfile>
|
The root element of the CPP XML document. |
<PartyInfo>
|
Defines all the details about the trading partner. |
<PartyId>
|
Defines a logical identifier for the organization, such as D-U-N-S code or any industry-specific identifier. |
<PartyRef> |
Defines a URL that provides additional information about the organization, which may point to a UDDI or ebXML registry. |
<CollaborationRole>
|
Defines a specific role for the trading partner in an e-business process, which is derived from a BPSS (Business Process Specification Schema) XML document. |
<Certificate>
|
Defines the digital certificate such as an X.509 certificate used by e-business trading partners to authenticate the user
who sends the message. More than one Certificate element can be used for various security functions in the CPP.
|
<SecurityDetails>
|
Defines a TrustAnchors element, which contains the AnchorCertificateRef element that refers to the Certificate element. Security elements can be used for various security functions in the CPP.
|
<DeliveryChannel>
|
Defines the transport and message protocols supported by the trading partner. |
<Transport>
|
Defines details of the messaging transport protocol such as type version and endpoint. |
<DocExchange>
|
Defines the signature or encryption protocol that trading partners must agree on for exchange of business documents. |
<OverrideMshActionBinding>
|
|
<SimplePart>
|
|
<Packaging>
|
Defines how the message header and payload data are packaged for transmission, taking care of document-level security constraints. |
<Signature> |
Defines the Signature element, which is used for signing the CPP, conforming to the XML Digital Signature specification (XMLDSIG).
|
| <Comment> | Defines a textual note from the CPP author. |
The Collaboration Protocol Agreement (CPA) defines the system-level agreement for data interchange between trading partners. It narrows down a subset from what both trading partners can support to what both trading partners will actually support in the exchange. The CPA acts as a service-level agreement that, once agreed upon by both parties, can be then enforced by the ebXML system on both ends of the communication bridge.
As shown in Figure 2, the Status, Start, End, ConversationConstraints, PartyInfo, and Signature elements are the key elements that define the capabilities that two trading partners need to agree upon so they can engage
in electronic business for the purposes of the particular CPA. The Status element records the state of the composition/negotiation process that creates the CPA. The Start element specifies the starting date and time of the CPA. The End element specifies the CPA's ending date and time. The ConversationConstraints element places limits on the number of conversations under the CPA. The PartyInfo element specifies the parties' selected terms for engaging in the business collaborations defined by the process specification
documents referenced by the CPA. The Signature element, if present, is made up of one to three Signature elements.
| Subject | Replies |
Last post
|
|
By Anonymous |
0 |
10/05/06 08:37 AM
by Anonymous |
|
By JavaWorld
|
0 |
08/11/06 12:55 AM
by JavaWorld |
Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq
![]()
Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq