DICOM:开源DICOM服务框架DCM4CHE构建的准备

背景:

最近抽空想了解一下DCM4CHEE开源DICOM框架,怎奈配置了许久也没有成功(Σ( ° △ °|||)︴)。可能多半原因是因为首次接触Java开发环境,毕竟跟C系列(C/C++/C#)不同,但这次失败经历,让我愈发感受到自己对大型项目的快速熟悉和把握能力的欠缺,其实这也正是我学习各种开源项目的出发点。加上之前曾有CSDN博友询问关于ClearCanvas配置问题,所以决定趁着周末详细整理一下配置、学习、使用,甚至扩展开源项目的流程,算是对此次配置DCM4CHEE经验的一次总结和延伸。

Compile/Link/Build:

Compile&Link:

作为软件开发人员,无论前台、后台,对于代码如何转换成可执行应用应该了然于心,主要包括编译、链接两个过程。编译,即compile,就是将人类读得懂的语言转换成二进制以便计算机读取,常见的说法是“从源语言编写的源程序产生目标程序的过程”,这一转换过程主要包括词法分析、语法分析、语义分析、代码优化、目标代码生成五大过程,就像我们阅读文章时的思维过程。链接,link,将编译生成的各个目标文件进行组合连接,使其成为可独立运行的统一整体。

编译和链接是相辅相成,缺一不可的,或者说两者的功能有所对接或者融合。通常一种操作或处理流程的出现,例如先编译后链接,不是由某位先人凭空设计出来的,而是在实际应用过程中为了提高效率尽最大可能满足人类”懒“的天性而逐渐形成的。就拿编译和链接来说,如果我的目标很简单,简单到用汇编语言只有一条指令:HLT,让处理器进入休息状态。对于这种状态下就没有必要先编译后链接(当然这里是理想状态,因为即使是一条汇编指令也需要其他相关库的支持,需要彼此之间进行链接),编译直接生成二进制指令给CPU即可。随着科技的进步,人们的需求越来越复杂,发展到今天一个项目有效代码数应多大几万、甚至几十万行,项目目录结果复杂,代码文件众多,如果还是逐个文件编译,到最后链接,想必这个过程比整个工程的代码编写还困难。随之而来的就是各种自动编译和连接工具,诸如make、cmake、ant、maven,以及各种IDE集成可视化开发软件,如VS、Eclipse。由于工具彼此出现的年代不同,后期的工具往往是对前者的优化和升级,比如从shell批处理到make的升级、make到cmake的升级;ant到maven的升级、maven到Eclipse的升级;Nant到CCNet的升级,这里有关于各种工具的分析。

引用:“一般而言.一个比较正规的项目都不会基于IDE 进行构建..一般会用ant, maven, gradle ,为什么不用ide 呢?首先,是ide的选择,有人喜欢,用vim,eclipse,intellijidea,收费的,免费的.特别是公开的项目,你用什么IDE 相当于为这个IDE 打广告了..所以,一般而言都是用构建工具,而不是IDE .实际上各种IDE 也是基于各种构建系统,也正是不同的IDE,它们的构建方式不同,所以要让不同的IDE间能一起开发,于是需要一个统一的构建工具,只是你平时不关注而已..扯到构建工具, 一般c/c++ 项目用make,或者 premake. 而java 一般是ant,ivy,gradle,maven,还有直接的shell”

Build:

上面简单分析了各种自动化工具将源代码转换成可执行程序,是不是到此我们的工作就结束了呢?不要着急,九九八十一难还有一难——部署或发布。对于这两者的区别,本文忽略不讨论,这里统一看做将产品投放到目标用户手中,完成最初满足特定实际应用的目的。编译和连接都有各种自动化工具,构建同样如此,上文提到的ant、maven就是Java环境中的自动构建工具,我也正是在配置DCM4CHEE开源框架时首次接触,后续讲解DCM4CHEE完整且成功配置时再对ant和maven进行详细介绍。

引用:许多人都将构建(build)与编译混在一起,认为两者没有大的区别。实际上构建的内涵和外延远远大于编译。构建是指从源码到最终投产或上线的整个生命周期,而编译只是从源码到中间代码或可执行代码的过程。编译只是中间的黄色部分,从技术上看是从源码向机器码翻译的过程。而构建特别是基础构建能力则应该包括:流程管理、多平台支持、构建流程/执行/结果的集中统一控制、以及与其他工具的无缝集成,这些都是处理当前开发环境中的硬件资源、工具、语言及脚本不可或缺的核心构建能力。

OpenSource:如何学习和使用开源项目

开源安装包与源码:

开源项目中常常会提到下载二进制安装包(例如windows系统中的exe)和下载源码,源码顾名思义就是代码源文件,可以看到整个项目的具体实现过程和细节。通常如果仅仅是为了使用开源项目提供的服务,下载二进制安装包即可。下载完成后或双击运行(对于提供了exe等可执行二进制文件的),或手动添加库引用路径(部分开源库提供的服务不能独立运行,需要嵌入到用户自己程序中,该类开源项目通常会给出lib、dll或so等库文件),如是就可以使用开源库的服务了 。开源社区由于其旺盛的生命力,已越来越受到追捧,当然很多开发人员或中小企业喜欢开源项目的原因是节省开发成本,可借助开源项目快速实现基本功能,待时机成熟后还可进行升级和扩展。因此我们在享用项目的服务的同时,更希望详细了解开源项目的具体设计,所以需要下载源代码。对于DCM4CHEE项目同样如此,如果只是希望使用DCM4CHEE开源DICOM服务框架,官网的使用说明是Installation,如果希望使用DCM4CHEE进行开发,官网的说明是Building dcm4chee from source code注:下一篇博文中会详细介绍DCM4CHEE Building

参考实例DCMTK:

上面对于compile、link、build等概念进行了分析,单单比较概念很枯燥。下面我从实际应用角度出发来简单的阐述一下“下载一个开源项目,到利用开源项目完成自己的开发,到发布给用户使用”的过程。对于DCM4CHEE的使用我也是刚接触这里就不以此为例了,以免搬起石头砸自己的脚。还是以专栏里的dcmtk和fo-dicom来举例。

比如说dcmtk,我们知道这是一个用C++编写的实现了DICOM标准的开源库。我们用它的目的是什么呢?其实就是避免自己动手实现DICOM协议,“站在巨人的肩膀上才能看的远”

第一步源码下载。DCMTK官网中没有给出编译好的二进制下载链接,作为开源项目,由用户下载源码然后在本机环境下编译生成才能确保顺利运行。

上图就是DCMTK开源项目的目录结构,简单的看几个文件夹,比如dcmdata,从命名上可以猜测出这个文件夹下存放的应该是实现DICOM协议中关于数据格式的部分(即3、4、5等部分);dcmdata作为DCMTK项目其中的一个模块,其自身也是一个小小的项目,内部也包含多级目录结构。例如目录libsrc存放的就是dcmdata的具体实现代码,包括最基本的DcmItem、DcmElement、DcmTag等类,这些都是DICOM协议中规定的最基本的数据元。除了源代码以外,为了使得开源项目使用方便和更易推广,往往还会包含其他目录,常见的有 docs,该目录存放开发者会对代码说明,常见的有html、txt等格式; apps,开发者自己实现的部分工具,为其他人员提供便利;tests,在开发过程中源代码开发者自己编写的测试用例,往往是用于测试apps中的某个工具的,除此之外可能还会有 etc、Resources等文件夹。

第二步本地构建,Compile->Link->Build。下载完源码后,接下来自然就是编译和连接了(官方说明和柳北风儿)。猛然获得这么多的代码,我们该怎么开始工作呢?各个源文件之间的编译先后顺序和依赖关系是什么?如果需要我们自己来手动编译,这一环节足以打消多数人使用开源项目的积极性,果真如此的话该开源项目就不会有生命力。那么有没有自动化的工具呢?当然有啦,这不就是前文刚刚提到的make和cmake吗,在DCMTK源码包的各级目录下都存在CMakeLists.txt文件。下载CMake工具后,按照(官方说明和柳北风儿)说明操作即可,值得庆幸的是DCMTK的本地构建工作比较容易,经过简单的配置都可以顺利完成,这一点比DCM4CHEE容易多了^_^。

第三步开发扩展,打包和部署。经过第二步本地构建后DCMTK库中相关工具包和服务库都被安装到了指定的目录(在CMake主界面的“Where to build the binares”自定义)下。后面我们可以将服务库路径添加到自己的工程中进行二次扩展开发, DICOM专栏博文 中有大量关于二次开发的介绍,有兴趣的可以阅读,这里就不详细介绍了。

DCM4CHEE构建概述:

所谓“磨刀不误砍柴工”,通过上面的知识普及,大致梳理了开源项目的应用流程。在下一篇博文开始正式介绍DCM4CHEE构建过程之前,先对DCM4CHEE进行一个简单的概述。

dcm4che VS dcm4chee:

进入dcm4che官网,会看到dcm4chee Archive和dcm4che2 Toolkit。对于dcm4che和dcm4chee很容易引起混淆,自己看一下官方的介绍:

翻译:

dcm4che,是医疗健康行业中一套开源应用程序和工具的,采用Java语言开发,支持JDK1.4及以上版本。dcm4che项目的核心之一是一个DICOM标准的健壮实现,该实现分为dcm4che-1.x和dcm4che-2.x两个版本,dcm4che-2.x是对dcm4che-1.x的重构,提高了应用的性能和灵活性;dcm4che项目另一部分是dcm4chee(额外的e表示Enterprise)。dcm4chee运行在JBoss环境下,是一个图像管理器和图像归档器,实现了DICOM服务和HL7接口,提供图像存储、查询和流程管理等功能,主要服务如下图。

由此我们可以看出dcm4che是整个项目的统称,其官网域名就是www.dcm4chee.org,包含一个类似于DCMTK的DICOM协议包,即dcm4che1.x和dcm4che2.x,和一个服务框架dcm4chee。从SourceForge的发布目录也可以看出整个dcm4che开源项目的结构。

PS:本文作为DCM4CHE开源环境构建的前传,简要介绍了开源项目的学习方法,并通过DCMTK开源项目给出了一个基本的示范,后续博文会给出DCM4CHE的实际构建过程,敬请期待!(昨天女生节,今天妇女节,祝我认识的所有女性朋友天天开心^_^)

作者:[email protected]

时间:2015-03-08

时间: 2025-01-06 15:56:16

DICOM:开源DICOM服务框架DCM4CHE构建的准备的相关文章

DICOM:开源DICOM服务框架DCM4CHE 构建

背景: 前一篇博文DICOM:开源DICOM服务框架DCM4CHE 安装中介绍了一款开源DICOM服务框架DCM4CHE,对于开源项目学习的流程是先下载二进制可执行包安装,然后使用测试.在熟悉了大致的功能服务后,从官网下载源代码进行本地构建(Build),进而从根本上了解开源项目的底层框架设计,为后续修复.扩展做准备.本博文是继DCM4CHE安装后的续篇,讲解如何在本地构建DCM4CHE开源项目,文中尽量做到全面,但是由于刚开始接触J2EE领域,且多半都是自学,因此博文中还留有部分未解问题,如有

DICOM:开源DICOM服务框架DCM4CHE 安装

背景: dcm4chee是dcm4che开源项目中的一部分,是一款符合IHE规定的影像管理/归档应用.dcm4chee遵循DICOM.HL7标准,实现了图像存储.图像提取.及健康领域的工作流程管理.dcm4chee作为一款应用程序需要预打包,然后部署到JBoss应用服务器中.借助于JBoss应用服务器的服务特性,诸如JMS.EJB.Servlet引擎.远程控制.安全性.事务管理.持久性.消息传递.资源库.并发控制.命名和目录服务以及部署等等,dcm4chee提供了多种鲁棒性强且可扩展服务,主要包

Idea搭建Apache Dubbo开源分布式服务框架

[一.定义]1.读音:Dubbo [?d?b??]音似double2.Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和Spring框架无缝集成.[二.核心]3.Dubbo提供了三大核心能力:A)面向接口的远程方法调用:Remoting(网络通信框架,实现了 sync-over-async 和 request-response 消息机制.)B)智能容错和负载均衡:RPC(一个远程过程调用的抽象)C)以及服务自动注册和发现:Re

当当网开源Dubbox,扩展Dubbo服务框架支持REST风格远程调用

当当网近日开源了Dubbox项目,可为Dubbo服务框架提供多项扩展功能,包括REST风格远程调用.Kryo/FST序列化等等. 当当网架构部和技术委员会架构师沈理向InfoQ中文站介绍了Dubbox项目,开发背景和主要特点描述如下: Dubbo是一个被国内很多互联网公司广泛使用的开源分布式服务框架,即使从国际视野来看应该也是一个非常全面的SOA基础框架.作为一个重要的技术研究课题,在当当网我们根据自身的需求,为Dubbo实现了一些新的功能,并将其命名为Dubbox(即Dubbo eXtensi

一篇文章带你深入了解Dubbo分布式服务框架

一.产生的背景 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进.下面我们用一个图来具体说明架构和开发框架的演进过程.单一应用架构当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本.此时,用于简化增删改查工作量的数据访问框架(ORM)是关键. 垂直应用架构当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率.此时,用于加速前端

分布式服务框架Dubbo使用小结

介绍: Dubbo是一个被国内很多互联网公司广泛使用的开源分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA 服务治理方案,每天为2,000+个服务提供3,000,000,000+次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点. 其核心部分包含: 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及"请求-响应"模式的信息交换方式. 集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,

Dubbo分布式服务框架

Dubbo (开源分布式服务框架) 编辑 本词条缺少信息栏,补充相关内容使词条更完整,还能快速升级,赶紧来编辑吧! Dubbo是 [1]  阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 [2]  Spring框架无缝集成. Dubbo是一款高性能.轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现. 目录 1 主要核心部件 2 工作原理 3 特性 主要核心部件

DICOM:DICOM Print服务中PresentationContext协商之 MetaSOPClass与SOPClass对比分析

背景: 最近项目中遇到的实际问题较多,且大多是较隐蔽的.不易被发现的错误.究其根源来看,还是对DICOM3.0协议中的细节掌握不够仔细,因而导致在实际编码过程中,常常想当然.前一篇中剖析了由于DicomClient中的AddRequest与Send函数调用逻辑错误导致的System.ObjectDisposedException异常,接下来要讲的是关于DICOM胶片打印的问题,由于在Association Negotiation中PresentationContext协商失误导致DICOM Pr

DICOM:DICOM三大开源库对比分析之“数据加载”

背景: 上一篇博文DICOM:DICOM万能编辑工具之Sante DICOM Editor介绍了DICOM万能编辑工具,在日常使用过程中发现,"只要Sante DICOM Editor打不开的数据,基本可以判定此DICOM文件格式错误(准确率达99.9999%^_^)".在感叹Sante DICOM Editor神器牛掰的同时,想了解一下其底层是如何实现的.通过日常使用以及阅读软件帮助手册推断其底层依赖库很可能是dcmtk,就如同本人使用dcmtk.fo-dicom.dcm4che3等