包 javax.xml.registry.infomodel.* 它的用途是什么？忘记还是执行？
浏览 Java EE6 API 我发现了有趣的包 javax.xml.registry.infomodel，包含诸如
- PostalAddress（具有城市、街道、邮政编码...）
- 组织（具有用户、子结构、联系人、电话号码）
- 人名（名字/姓氏/中间名）
- 电子邮件地址
- 电话号码（国家/地区代码、类型、分机号等）等接口）
- 用户（人名、网页、地址等）
- ...
正如 API 中所述，
这个包描述了 JAXR API
的信息模型
，日期为 2002 年 4 月反过来，在它的摘要中说：
目前有很多 重叠规格 商业登记处。例子包括 ISO 11179、OASIS、eCo 框架、ebXML 和UDDI。 JAXR 提供了统一和 用于访问此类的标准 API Java 平台内的注册表。
大多数 Java 开发人员每天都在与这些实体打交道，并以自己的方式实现它们。
这意味着这个顶层、信息模型、具有众所周知实体的包的级别，我们什么时候应该考虑实现它们？潜在的谷歌规模的项目？与 ERP 系统接口？或者我们的世界正在走向标准化，并且遵循这些标准正在成为一种良好的举止甚至要求的问题？有没有可能几年后客户会打电话给我说“我现在就希望一切都符合 ebXML 标准！”我会说“我已经是了！” ？
JAXR 是一个正在成长且有前途的东西吗？
Looking through Java EE6 API I've found interesting package javax.xml.registry.infomodel, containing such interfaces as
- PostalAddress (having city, street, zip ...)
- Organization (having users, child structures, contacts, phone numbers)
- PersonName (first/last/middle name)
- EmailAddress
- TelephoneNumber (country/ area codes, type, extension, etc)
- User (person name, web page, address, etc)
- ....
As it's stated in API,
This package describes the
information model for JAXR API
which is dated April 2002 and, in turn, in it's abstract says:
Currently there are numerous
overlapping specifications for
business registries. Examples include
ISO 11179, OASIS, eCo Framework, ebXML
and UDDI. JAXR provides a uniform and
standard API for accessing such
registries within the Java platform.
Most of Java developers are dealing with these entities every day, implementing them in their own way.
Meaning this top, infomodel, level of the package with widely known entities, when should we consider implement them? Potentially google-sized projects? Interfacing with ERP systems? Or is it that our world is moving towards standardization and it's becoming a matter of good manners, or even requirements, to follow these standards? Can it be that in a couple of years customer will call to me and say 'I want everything to be ebXML compliant, now!' and I'd say 'I am already!' ?
Is JAXR something growing and promising?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
JAXR 不是您用于 HelloWorld 应用程序的东西，是否使用它取决于您（或您的客户）。如果您发现项目的增长需要访问 XML 注册表，那么只需实现它们即可。
它是正在成长和有前途的东西吗？肯定是的，目前 JMX 为您提供了一组 API 来访问各种 XML 注册表，包括 UDDI 和 ebXML 注册表。您无需担心每个注册表信息模型的具体细节！尝试想象一下它可以节省多少时间。
JMX 抽象与一次编写，随处运行的 Java 哲学是一致的。它提供的增值功能超出了底层注册表的功能。
例如，非 JAXR UDDI 客户端无法执行分类法浏览和分类法感知智能查询，而这些功能可用于 UDDI 的 JAXR 客户端。
如果您想了解更多有关使用 JAXR 注册和发现 Web 服务的未来计划，请直接询问 Farrukh Najmi（JAXR 规范负责人）或 David J. Etelson（Java 战略和产品营销），祝您好运，他们会回答您； ）
JAXR is not something you use for HelloWorld application, it is upon you (or you client) to use it or not. If you have found that growing of the project will require access to XML registry, just implement them.
Is it something growing and promising? Definitely YES, for now JMX provides you with a single set of APIs to access a variety of XML registries, including UDDI and the ebXML Registry. You don't need to worry about the nitty-gritty details of each registry's information model! Try to imagine how much time it saves.
JMX abstraction is consistent with the Java philosophy of Write once, Run Anywhere. It enables value-added capabilities beyond what the underlying registries can do.
As an example, a non-JAXR UDDI client can't do taxonomy browsing and taxonomy-aware smart queries -- which are available to a JAXR client for UDDI.
If you want to know more about future plans of registration and discovery of web services using JAXR ask directly Farrukh Najmi (JAXR Specification Lead) or David J. Etelson (Java Strategy and Product Marketing), may you have a luck and they answer you ;)
以我的拙见，如果您的客户没有指定任何类型的商业登记处，我就不会实施它。基本上是因为你不能向他收取他不需要的东西的费用。
再见。
In my humble opinion, if your customer doesnt specify any kind of business registry I wouldn't implement it. Basically because you cannot charge him for something he didn't needs.
Bye.