.Net / PHP / iPhone 中的 JNDI
让我向您解释一下我目前遇到的完整情况。
我们正在 GWT 和 Hibernate 中开发非常复杂的应用程序，由于客户的要求，我们正在尝试将客户端和服务器代码托管在不同的服务器上。现在，我可以使用 JNDI 来实现这一点。
棘手的部分来了，客户端也需要在不同的平台上拥有该应用程序，数据库将相同，方法也将相同，比如说我们应用程序的 iPhone / .Net 版本。我们不想再次生成服务器代码，因为它对于所有人来说都是相同的。
我曾尝试在服务器代码顶部使用 WebServices 包装器，但由于体系结构和类依赖关系的复杂性，我无法这样做。例如，让我们考虑下面的代码。
class Document {
List<User>;
List<AccessLevels>;
}
文档类有用户列表、访问级别列表和更多其他类列表，并且其他类有更多列表。一些重要的服务器方法将类（文档或任何其他）作为输入并在输出中返回一些其他类。而且我们不应该在 WebServices 中使用复杂的架构。
所以，我需要坚持使用 JNDI。现在，我不知道如何访问对任何其他应用程序的 JNDI 调用？？？
请提出克服这种情况的方法。我对技术变革持开放态度，这意味着 JNDI / WebServices 或任何其他可以很好地为我服务的技术。
谢谢您，
问候，
Let me exaplain you the complete situation currently I am stuck with in.
We are developing very much complex application in GWT and Hibernate, we are trying to host client and server code on different servers because of client's requirement. Now, I am able to achieve so using JNDI.
Here comes the tricky part, client need to have that application on different Platform also, database would be same and methods would be the same, lets say iPhone / .Net version of our application. we don't want to generate Server code again because it's gonna be the same for all.
I have tried for WebServices wrapper on the top of my server code but because of complexity of architecture and Classes dependencies I am not able to do so. For example, Lets consider below code.
class Document {
List<User>;
List<AccessLevels>;
}
Document class have list of users, list of accesslevels and lot more list of other classes and that other classes have more lists. Some important server methods takes Class (Document or any other) as input and return some other class in output. And we shouldn't use complex architecture in WebServices.
So, I need to stick with JNDI. Now, I don't know how can I access JNDI call to any other application ???
Please suggest ways to overcome this situation. I am open for technology changes that means JNDI / WebServices or any other technology that servers me well.
Thanking You,
Regards,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我从未见过 JNDI 用作请求/响应进程间通信的机制。我不相信这会是一条富有成效的攻击路线。
您认为当有效负载复杂时，Web 服务不合适。我不同意，我见过许多成功的项目使用相当大的有效负载，并且有许多嵌套类。简单的示例：客户的订单、订单行、产品、...等等。
显然希望保持较小的有效负载大小，存在序列化和网络成本，大对象会更昂贵。但到目前为止，提出一个大要求比提出很多小要求要好得多。 “繁忙”的接口在网络中的性能不佳。
我怀疑您可能遇到的一个问题是某些服务器端类不是纯数据，它们指的是仅在服务器上有意义的类，您不希望在客户端中使用这些类。
在这种情况下，您需要构建一个“适配器”层。这是一项枯燥的工作，但无论您使用哪种进程间通信技术，您都需要这样做。您需要我所说的数据传输对象 (DTO) - 这些表示客户端可以理解的有效负载，仅使用对客户端合理的类，并且服务器可以使用和创建这些类。
假设您使用技术 XXX（JNDI、Web 服务、直接套接字调用、JMS）
，反之亦然。我的主张是，无论选择什么 XXX，您都会遇到相同的问题，您需要客户端使用不透露服务器实现细节的“精简”对象。
适配器负责创建和理解 DTO。
我发现，一旦拥有一组 DTO，使用 JAX/RS 来处理 RESTful Web 服务就非常容易，创建 Web 服务只需要几分钟的时间。
I have never seen JNDI used as a mechanism for request/response inter-process communication. I don't believe that this will be a productive line of attack.
You believe that Web Services are inappropriate when the payloads are complex. I disagree, I have seen many successful projects using quite large payloads, with many nested classes. Trivial example: Customers with Orders with Order Lines with Products with ... and so on.
It is clearly desirable to keep payload sizes small, there are serialization and network costs, big objects will be more expensive. But it's by far preferable to have one big request than lot's of little one. A "busy" interface will not perform well across a network.
I suspect that the one problem you may have is that certain of the server-side classes are not pure data, they refer to classes that only make sense on the server, you don't want those classes in you client.
I this case you need to build an "adapter" layer. This is dull work, but no matter what Inter-process communication technique you use you will need to do it. You need what I refer to as Data Transfer Objects (DTOs) - these represent payloads that are understood in client, using only classes reasonable for the client, and which the server can consume and create.
Lets suppose that you use technology XXX (JNDI, Web Service, direct socket call, JMS)
and similarly in reverse. My claim is that no matter what XXX is chosen you have the same problem, you need the client to work with "cut-down" objects that reveal none of the server's implementation details.
The adapter has responsibility for creating and understanding DTOs.
I find that working with RESTful Web Services using JAX/RS is very easy once you have a set of DTOs it's the work of minutes to create Web Services.