Part One: The value of many of the facets of SDO
Service Data Objects (SDOs) simplify and unify Service Oriented Architecture (SOA) data access and code.
SDO complements the strength that SCA (Service Component Architecture) offers for simplifying development of SOA-based solutions. SCA handles the composition of service networks and SDO focuses on simplifying data handling. These technologies are getting significant support in the industry. The development of the SDO and SCA specifications is in the hands of the Open Service Oriented Architecture collaboration (www.osoa.org) and open source implementations of these specifications are being developed in the Apache Tuscany incubator project (http://incubator.apache.org/tuscany).
In this two-part article we use a scenario to demonstrate the value of many of the facets of SDO.
Some History
The first SDO specification was published in November 2004 as a result of collaborative between IBM and BEA. The Eclipse Foundation developed an open source implementation of this SDO 1 specification. SDO primarily addressed the lack of general applicability of the existing technologies such as JAXB and JDO. Around that time Microsoft entered this space with ADO.NET, offering a slightly different technical perspective. The SDO 2.0.1 specification appeared late in 2005 and is continuing to evolve, with wider industry involvement; at the time of writing revision 2.1 is imminent and revision 3.0 is in the pipeline.
SDO provides flexible data structures that allow data to be organized as graphs of objects (called data objects) that are composed of properties. Properties can be single or many valued and can have other data objects as their values. A data object can maintain a change summary of the alterations made to it, providing efficient communication of changes and a convenient way to update an original data source. SDO naturally permits disconnected data access patterns with an optimistic concurrency control model.
SDO offers a convenient way to work with XML documents. SDO implementations provide helpers to populate a data graph from both XML documents and relational databases and to read SDO metadata from an XML Schema Definition (XSD). Data objects can be serialized to XML and the metadata can be serialized to an XSD file (see Figure 1).
Data Objects can be introspected using the SDO metadata API to get information about types, relationships, and constraints.
SDO delivers unified and consistent access to data from heterogeneous sources. This provides both a simple programming model for the application programmer and lets tools and frameworks work consistently across those heterogeneous data sources.
SDO offers a single model for data across the enterprise.
The diagram below shows a WebUI client accessing data from a variety of sources, mediated by SDO. Web applications typically operate in a semi-connected fashion and rely on optimistic-concurrency. SDO is well suited to this environment, where data can be manipulated remotely and then a summary of the changes can be delivered back to the data sources (see Figure 2).
The following sections will introduce SDO in more detail.
A Scenario
This example is based on an imaginary project inspired by some real-world scenarios. A hypothetical group of universities, hospitals, and companies have embarked on a long-term collaboration to study some family of diseases that has both a genetic and environmental component. They will need to exchange the medical histories of the people they're treating and studying, and also exchange the medical histories of relatives. The data will likely come from disparate sources; basic patient data will probably be in a relational database; data from medical investigations conducted as part of this research project will be in XML documents; other medical data may come from less well known formats or custom sources. The amount of data about any given person will vary greatly. A long-standing patient may come with an extensive medical history. A relative might have little beyond name and relationship. This data has to be assembled into a coherent manageable whole, and SDO is an attractive option for representing a complicated mix of data about each person and potentially maintain a graph of such entities. For this example, we can't even assert that the graph is a (family) tree because with adoption, re-marriage, fertility treatment, and so on, one person's associations with others can be quite intricate.
The various institutions involved may not want to give unrestricted access to their data sources, although they've agreed to supply pieces of it as needed. A hospital may be willing to provide the medical data associated with one patient as part of an investigation, but they won't permit open access to their entire patient record database. Similarly, a company will want to limit access to commercially sensitive material. SDO provides a convenient way for the owner of the data to deliver to outsiders a subset of that data of their own choosing.
We'll now show some of the key values of SDO through this scenario.
To illustrate where an SDO feature helps, consider a scenario where a hospital refers a patient to a university for further investigation. Relevant data will have to flow from the hospital to the university, and it may well come from a variety of different sources. Assume that name, age, records of visits, and so forth comes from an SQL database, while specific medical data (the results of tests) are in XML documents. Using standard SDO features it's straightforward for the hospital to combine these various sources into a data object and send that, letting users of the data access it via SDO's unified API.
The university does whatever it does with the patient, and then updates the SDO and sends it back. The change history in the SDO lets the hospital apply the updates to its various data repositories without the university ever needing to know the detail of those repositories.
It's unlikely that these updates will clash with other updates made independently by the hospital, but if they do, the use of an SDO change summary ensures that this is detected and sorted out (probably manually in this case). The software component responsible for moving data between the data source (for example, a relational database in this case) and SDO is called a Data Access Service (DAS). A DAS can typically also handle conflicting updates.1
Using SDO as the data exchange format makes the system tolerant of the considerable variation to be expected in such a loosely coupled system. It's inevitable that, sooner or later, the versions of the applications that are sending and receiving data will get out-of-step. In fact, this may be usual. However, the fact that an SDO can arrive with its own metadata means that an older application can always retrieve what it wants from a newer (and presumably richer) input SDO - ignoring anything that it doesn't recognise. In the reverse case, a newer application can similarly recognise that the information it has received is from an older version and compensate accordingly.
In the previous scenarios, we've concentrated mostly on XML and SQL data sources. Now, let's suppose that in one hospital the results from the biochemistry lab are delivered in HL7 message format. This message format is widely used in the healthcare industry but is virtually unknown outside it, and so there's no off-the-shelf way to read such messages into an SDO. At this point there are several choices. We could use some broker-style product to reformat the HL7 into XML and then read it into an SDO or we could pay someone to write a new DAS that would populate an SDO directly from HL7. Since our collaborators are using an open source implementation of SDO, however, they opt to write their own DAS and donate it to the Apache Software Foundation's Tuscany project.
Other approaches exist to linking these various organisations, such as putting some software intermediary in the middle and using that to convert the data as needed. To do so though requires knowledge of all the possible input and output formats and how to convert between them. In such a loose collaboration there simply is no such central authority.
We now turn our attention to presenting the details of SDO using some code fragments.
分享到:
相关推荐
内容概要:本文详细介绍了基于MATLAB GUI界面和卷积神经网络(CNN)的模糊车牌识别系统。该系统旨在解决现实中车牌因模糊不清导致识别困难的问题。文中阐述了整个流程的关键步骤,包括图像的模糊还原、灰度化、阈值化、边缘检测、孔洞填充、形态学操作、滤波操作、车牌定位、字符分割以及最终的字符识别。通过使用维纳滤波或最小二乘法约束滤波进行模糊还原,再利用CNN的强大特征提取能力完成字符分类。此外,还特别强调了MATLAB GUI界面的设计,使得用户能直观便捷地操作整个系统。 适合人群:对图像处理和深度学习感兴趣的科研人员、高校学生及从事相关领域的工程师。 使用场景及目标:适用于交通管理、智能停车场等领域,用于提升车牌识别的准确性和效率,特别是在面对模糊车牌时的表现。 其他说明:文中提供了部分关键代码片段作为参考,并对实验结果进行了详细的分析,展示了系统在不同环境下的表现情况及其潜在的应用前景。
嵌入式八股文面试题库资料知识宝典-计算机专业试题.zip
嵌入式八股文面试题库资料知识宝典-C and C++ normal interview_3.zip
内容概要:本文深入探讨了一款额定功率为4kW的开关磁阻电机,详细介绍了其性能参数如额定功率、转速、效率、输出转矩和脉动率等。同时,文章还展示了利用RMxprt、Maxwell 2D和3D模型对该电机进行仿真的方法和技术,通过外电路分析进一步研究其电气性能和动态响应特性。最后,文章提供了基于RMxprt模型的MATLAB仿真代码示例,帮助读者理解电机的工作原理及其性能特点。 适合人群:从事电机设计、工业自动化领域的工程师和技术人员,尤其是对开关磁阻电机感兴趣的科研工作者。 使用场景及目标:适用于希望深入了解开关磁阻电机特性和建模技术的研究人员,在新产品开发或现有产品改进时作为参考资料。 其他说明:文中提供的代码示例仅用于演示目的,实际操作时需根据所用软件的具体情况进行适当修改。
少儿编程scratch项目源代码文件案例素材-剑客冲刺.zip
少儿编程scratch项目源代码文件案例素材-几何冲刺 转瞬即逝.zip
内容概要:本文详细介绍了基于PID控制器的四象限直流电机速度驱动控制系统仿真模型及其永磁直流电机(PMDC)转速控制模型。首先阐述了PID控制器的工作原理,即通过对系统误差的比例、积分和微分运算来调整电机的驱动信号,从而实现转速的精确控制。接着讨论了如何利用PID控制器使有刷PMDC电机在四个象限中精确跟踪参考速度,并展示了仿真模型在应对快速负载扰动时的有效性和稳定性。最后,提供了Simulink仿真模型和详细的Word模型说明文档,帮助读者理解和调整PID控制器参数,以达到最佳控制效果。 适合人群:从事电力电子与电机控制领域的研究人员和技术人员,尤其是对四象限直流电机速度驱动控制系统感兴趣的读者。 使用场景及目标:适用于需要深入了解和掌握四象限直流电机速度驱动控制系统设计与实现的研究人员和技术人员。目标是在实际项目中能够运用PID控制器实现电机转速的精确控制,并提高系统的稳定性和抗干扰能力。 其他说明:文中引用了多篇相关领域的权威文献,确保了理论依据的可靠性和实用性。此外,提供的Simulink模型和Word文档有助于读者更好地理解和实践所介绍的内容。
嵌入式八股文面试题库资料知识宝典-2013年海康威视校园招聘嵌入式开发笔试题.zip
少儿编程scratch项目源代码文件案例素材-驾驶通关.zip
小区开放对周边道路通行能力影响的研究.pdf
内容概要:本文探讨了冷链物流车辆路径优化问题,特别是如何通过NSGA-2遗传算法和软硬时间窗策略来实现高效、环保和高客户满意度的路径规划。文中介绍了冷链物流的特点及其重要性,提出了软时间窗概念,允许一定的配送时间弹性,同时考虑碳排放成本,以达到绿色物流的目的。此外,还讨论了如何将客户满意度作为路径优化的重要评价标准之一。最后,通过一段简化的Python代码展示了遗传算法的应用。 适合人群:从事物流管理、冷链物流运营的专业人士,以及对遗传算法和路径优化感兴趣的科研人员和技术开发者。 使用场景及目标:适用于冷链物流企业,旨在优化配送路线,降低运营成本,减少碳排放,提升客户满意度。目标是帮助企业实现绿色、高效的物流配送系统。 其他说明:文中提供的代码仅为示意,实际应用需根据具体情况调整参数设置和模型构建。
少儿编程scratch项目源代码文件案例素材-恐怖矿井.zip
内容概要:本文详细介绍了基于STM32F030的无刷电机控制方案,重点在于高压FOC(磁场定向控制)技术和滑膜无感FOC的应用。该方案实现了过载、过欠压、堵转等多种保护机制,并提供了完整的源码、原理图和PCB设计。文中展示了关键代码片段,如滑膜观测器和电流环处理,以及保护机制的具体实现方法。此外,还提到了方案的移植要点和实际测试效果,确保系统的稳定性和高效性。 适合人群:嵌入式系统开发者、电机控制系统工程师、硬件工程师。 使用场景及目标:适用于需要高性能无刷电机控制的应用场景,如工业自动化设备、无人机、电动工具等。目标是提供一种成熟的、经过验证的无刷电机控制方案,帮助开发者快速实现并优化电机控制性能。 其他说明:提供的资料包括详细的原理图、PCB设计文件、源码及测试视频,方便开发者进行学习和应用。
基于有限体积法Godunov格式的管道泄漏检测模型研究.pdf
嵌入式八股文面试题库资料知识宝典-CC++笔试题-深圳有为(2019.2.28)1.zip
少儿编程scratch项目源代码文件案例素材-几何冲刺 V1.5.zip
Android系统开发_Linux内核配置_USB-HID设备模拟_通过root权限将Android设备转换为全功能USB键盘的项目实现_该项目需要内核支持configFS文件系统
C# WPF - LiveCharts Project
少儿编程scratch项目源代码文件案例素材-恐怖叉子 动画.zip
嵌入式八股文面试题库资料知识宝典-嵌⼊式⼯程师⾯试⾼频问题.zip