C#Windows系统数据交换到在ubuntu linux上运行的Java系统 [英] C# windows system data exchange to Java system running on ubuntu linux

问题描述

请提供建议！

我需要将我们的软件系统(带有SQL Server后端的Win32 C#表单应用程序-具有完整的源代码控制)集成到在不同地理位置(使用Java编写)和在ubuntu linux上运行的postgress数据库运行的外部软件系统上.

外部软件专家已准备好提供某种界面供我们集成，并对此有所关注

1.什么是最好的整合方法?我以前从未在Windows和ubuntu系统之间进行过集成，也不想出错.

2.性能，两个系统之间的带宽不是很稳定并且很好.我已经与服务提供商进行了交谈，他们说他们无法将服务水平提高到目前的水平.

请给我建议，任何帮助将不胜感激

更新1

让我更具体一点，

我们在总部的订单管理系统上使用的是c#& SQL Server 2005

Similalry，我们的仓库中有一个仓库系统，该仓库系统距总部约25英里，并且该仓库系统基于Java，Postress和UBUNTU linux.

两种系统都有其自己的结构，到目前为止，我们将以excel格式在总部(c#)系统中创建的订单发送到仓库，以便仓库人员进入其基于Java的系统，并将交货单发送给我们.总部将再次扫描到c#系统中.

我们将通过保持两个数据库完整(我们将不会共享同一数据库)来自动化此过程(这就是我所说的集成)，总部系统将使用SQL Server，仓库系统将在ubuntu上使用postgress，显然两者数据库具有自己的结构.


外部公司已提供基于ubuntu的系统，并愿意与我们合作，并提供某种接口(webservices?)供我们使用，以便两个系统之间的数据交换可以自动化-无需手动输入数据. >

我不确定最佳的前进方式，但是我想知道Web服务，并要求仓库软件提供商使用Java创建一些Web服务并为我们发布，以便可以在我们的C#系统中使用它...我不是确定这是否是最佳做法，并且不想出错


特别是总部和仓库之间的连接不是很稳定，并且不想以订单未完全同步化以及性能问题而告终.

我需要某种建议/任何建议/方向.

Needs an advice please!

I have a requirement to integrate our software system (win32 c# forms application with SQL server backend - have full source code control) to an external software system running in a different geographical location written using Java, postgress database running on ubuntu linux.

The external software guys are ready to proivde some sort of interface for us to integrate and am concerned on

1.What would be the best method to integrate ? I have never done an integration between windows and ubuntu system before and do not want to go wrong

2.Performance, the bandwidth is not very stable and good between both systems. I have spoken to the service provider and they say they can not improve the service beyond the current level.

Please advice me and any little help will be highly appreciated

UPDATE 1

Let me more specific,

We have an order management system in the head office on c# & SQL server 2005

Similalry, we have a warehouse system in our warehouse which is about 25 miles away from the head office and the warehouse system is on Java ,Postress and UBUNTU linux.

Both systems have their own structure and so far we are sending the orders created in the head office (c#) system in an excel format to the warehouse for the warehouse guys to enter into their Java based system and send us back the delivery notes to the head office to be again scanned into the c# system.

We are going to automate this process ( this is what i meant as integration) by keeping both databases intact ( we will not sharing the same database, the head office system will use SQL server and the warehouse system will use postgress on ubuntu and obviously both databases have their own structures.


An external company has provided the ubuntu based system and willing to work with us and provide some sort of an interface (webservices ?) for us to utilise so that the data exchange between both system can be automated - no manual data entry.


I am not sure about the best way forward but have web services in my mind and to ask the warehouse software provider to create some web services in Java and publish for us so that it can be consumed in our c# system...I am not sure whether this is the best practice and do not want to go wrong


Specially the connectivity between the head office and warehouse is not very stable and do not want to end up with orders not being fully synchonised and also performance issues.

I want some sort of advice / any suggestions / direction please

推荐答案

集成"是什么意思?使用同一个数据库?作为同一系统的一部分在本地运行?能够共享数据吗?

您是否有能力修改Java系统，或在接口中指定需要的内容?如果您能够向另一端添加挂钩，则创建Web服务/RPC端点或TCP协议以交换消息和数据将变得更加容易.相反，如果您无法控制，有时您就不得不诉诸黑客，例如读取日志文件和伪造键盘/鼠标输入.但这听起来像是您正在与其他开发人员一起使双方的集成工作正常进行，这很好.

只要您没有在数据库代码中使用任何SQL Server特定的功能，移动到其他后端数据库就很简单了(只需使用不同的DataAdapter类).如果有(我认为有些存储过程的内容会包含在其中)，那么您必须先翻译它，然后才能使用其他数据库，如果PostGre没有可比的扩展名，那么这将很棘手.

只要您不使用P/Invoke，就可以在Linux上使用Mono运行C#/.Net应用程序(如果有，则需要查找Linux本机等效项并根据构建情况在它们之间进行切换).

编辑更新

好的，所以您不希望这样的集成"，而希望合作"，即两个系统能够相互交互.通常，这很简单–在一端公开一个Web服务(如果它不是时间紧迫的，如果您现在要手动执行的话，那不是必须的)，然后与另一端调用，主动发布新订单并进行轮询以请求交货时的更新进展.

这里唯一的问题是网络故障可能引起的通信问题.如果您担心重复的请求，因为服务调用已完成但响应丢失，则需要在最初放置请求之前先在客户端为其分配一个UID，并将该ID包含在初始请求中发送到仓库.如果Java系统收到重复的ID，则应该拒绝它(自然而然地使用明智的返回码/异常).同样，送货单应该具有ID或绑定到所引用订单的ID，然后在客户端(我的意思是Web Service客户端，即总部系统)轮询新更新和Web Service之后发送有关新内容的信息，客户端应发送确认，其中包括成功检索更新的ID.这意味着，如果网络中断，总部将两次看到相同的更新的"交货单，但这总比没有好.

进行更新同步的另一种方法是为每个更新提供一个顺序ID，客户端可以根据它看到的最后一个更新ID发出请求.这将责任放在客户代码(即您的总部代码)中，意味着减少了一个服务呼叫；但是，这意味着服务器必须维护所有更新，因为直到请求到达时，服务器才知道要发送的更新.

根据现在的操作方式，这可能需要在数据库的一端或两端添加几个新表或字段，以跟踪双方认为已发送给另一方的内容以及正在等待作为新对象收集的内容更新.

What do they mean by ''integrate''? Use the same database? Run locally as part of the same system? Be able to share data?

Do you have the ability to modify the Java system, or specify things that need to be in the interface? Creating either a web service/RPC endpoint or a TCP protocol for exchanging messages and data is much easier if you have the ability to add hooks to the other end. At the opposite end of that scale, if you have no control whatsoever, you sometimes have to resort to hackery like reading log files and faking keyboard/mouse input. But it sounds like you are working with the other developers to make integration work from both sides, which is good.

As long as you haven''t used any SQL server specific features in the database code, moving to a different back end database should be trivial (just use different DataAdapter classes). If you have (I think some stored procedure stuff would come under this) then you would have to translate it before you could use a different database, and that can be tricky if PostGre doesn''t have comparable extensions.

It is possible to run a C#/.Net application on Linux using Mono, as long as you haven''t use P/Invoke (if you have you will need to find Linux native equivalents and switch between them depending on the build).

EDIT FOR UPDATE

Okay, so you don''t want ''integration'' as such but ''cooperation'', i.e. the two systems able to interact with each other. Generally this is straight forward – expose a web service (if it''s not time critical which it can''t be if you are doing it manually now) at one end and call it with the other, actively to post new orders and polling to request updates on delivery progress.

The only problem here is the possible communication issues with a bad network. If you''re concerned about duplicate requests, because a service call completed but the response was lost, you need to assign a request a UID on the client side before initially placing it, and include that ID in the initial request that''s sent to the warehouse. If the Java system receives a duplicate ID it should reject it (with a sensible return code/exception, naturally). Similarly, delivery notes should either have an ID or be tied to the ID of the order they refer to, and after a client (by which I mean the web service client, i.e. the head office system) polls for new updates and the web service sends information about what is new, the client should send an acknowledgement including the IDs that it successfully retrieved an update for. That means that if the network goes down head office will see the same ''updated'' delivery notes twice, but that''s better than no times.

Another way to do the update synchronisation is to give each update a sequential ID and the client can make requests based on what the last update ID it saw was. This puts the responsibility in the client code (i.e. your head office code) and means one less service call; however it means that the server has to maintain all the updates because it doesn''t know until a request comes in which ones it will need to send.

Depending on how it''s done now this might require a couple of new tables or fields in the database at one or both ends, to keep track of what each side thinks it has sent to the other and what is awaiting collection as a new update.

因此，您有部分连接的方案，并且需要在Windows和Linux上都可以运行的方案. WebSphere MQ [

So you have a partially connected scenario, and needs something that runs on both Windows and Linux. WebSphere MQ[^] solves this problem in a robust manner.

Best regards
Espen Harlinn

这篇关于C#Windows系统数据交换到在ubuntu linux上运行的Java系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！