From the Backlog<\/h2>\n\n\n\n
When we announced the release of Harmony Core at the conference, we discussed the backlog of tasks we wanted to complete. In the months since we shared the following slide, many of these items have been delivered.<\/p>\n\n\n\n Later in this blog post, we\u2019ll discuss some of the enhancements that have been implemented, but we\u2019d like to start by mentioning one of the more important changes we\u2019ve made for optimization: implementing sparse Select<\/strong>. Without this, Harmony Core could never realize its performance potential because of the extra data sent over xf<\/em>Server connections. Fortunately, the implementation turned out to be fairly straightforward. Harmony Core simply detects whether a channel is remote by using %ISINFO. If the channel is remote, Harmony Core builds a sparse Select object by processing the supplied EF Core LINQ expression and searching for field and object references that are required to create the result. If the channel is local, Harmony Core won\u2019t build a sparse Select object because the setup required for the object would incur a small performance cost.<\/p>\n\n\n\n At the conference, we talked with many of you about how we could improve and extend Harmony Core. These conversations were invaluable in helping us prioritize items in the backlog, and they got us thinking about how we could better take advantage of open standards. One thing we started thinking about was our custom protocol for Traditional Bridge,<\/strong> which is the Harmony Core component that exposes traditional Synergy logic. This custom protocol was well documented and made use of JSON, so it wasn\u2019t difficult to understand. However, it certainly seemed odd to have something custom like this, given our focus on open standards.<\/strong> We wanted to find an open solution, and as we looked around, JSON-RPC 2.0 caught our attention due to its use as the base for Microsoft\u2019s Language Server Protocol. Microsoft uses this protocol for remote procedure calls across standard in\/out, which is very similar to our use case. And on further investigation, we found that there was an open-source project that implemented JSON-RPC 2.0 in .NET Core. It\u2019s written by Andrew Arnott, a long time Microsoft employee with whom we\u2019ve interacted extensively, making this an even more enticing choice.<\/p>\n\n\n\n Having a top-quality high-performance library available sealed the deal, and we set out to switch the protocol. After some limited changes to Harmony Core server code (written in traditional Synergy) we had a working JSON-RPC 2.0 server and were able to communicate with it using vs-streamjsonrpc. Using someone else\u2019s client to talk to our traditional Synergy server gave us a great deal of confidence<\/strong> in our adherence to the standard and ensured that we won\u2019t have any weird behavior if you want your server to interface with some other non-Synergy system using the same mechanism. This is just one of the many steps we\u2019ve taken to make Harmony Core open and accessible for all of you.<\/p>\n\n\n\n Early on, a lot of our decision-making for Harmony Core was based on our experience developing and supporting xf<\/em>ServerPlus, xf<\/em>ODBC, and Symphony Harmony. Since the conference, we\u2019ve been able to get Harmony Core into the hands of some early adopters, which has enabled us to make more targeted decisions based on real-world situations. We\u2019ve learned a lot so far, and we\u2019re looking forward to tackling any new scenarios that arise in the future. For now, we\u2019ve got a solid list of improvements that should make the implementation process even smoother for future adopters.<\/p>\n\n\n\n With our first early adopter, we exposed preexisting Synergy code as a web service.<\/strong> We had expected this to be a use case, but hadn\u2019t yet worked through all the implications for the project layout and how to bring together all the CodeGen templates. We ended up making quite a few changes to the project template layout and tweaks to the CodeGen batch file included with the project template.<\/p>\n\n\n\n Initially, we weren\u2019t sure whether we wanted to use .NET Framework or .NET Core for this project. Did we need .NET Framework AppDomains for code isolation? Or could we get away with the much more performant AssemblyLoadContext available with .NET Core? After extensive discussions, we determined that we needed only global\/common\/static isolation, so .NET Core proved to be a perfect fit.<\/strong> Since we were wrapping preexisting code that wouldn\u2019t normally compile on .NET Core, we needed to make a .NET Standard version of the customer\u2019s core libraries. This went pretty smoothly once we sprinkled a few .IFDEFs around to remove code related to WinForms and Windows services.<\/p>\n\n\n\n Once everything was running, we were greeted by a debugger that was behaving strangely. We looked at our isolated objects in the debugger, but the debugger wouldn\u2019t display any values, and we weren\u2019t able to expand any children. It turned out there was a bug in the .NET Core debugger that prevented evaluation of objects that existed in multiple AssemblyLoadContexts. This issue was reported to Microsoft and was fixed (in Visual Studio 2019). This marked our first of many successful Harmony Core implementations.<\/strong><\/p>\n\n\n\n After tackling all the bugs and features for our first adopter, we started to consider how best to expose search functionality. To implement things like search, we generally recommend using the Harmony Core EF Provider, which eliminates the need for programmer intervention. In this case, however, we couldn\u2019t use the Harmony Core EF Provider due to the nature of the project\u2019s file\/data layout. A comprehensive search function was already built into the application, but we wouldn\u2019t really be implementing OData if we just exposed custom methods that didn\u2019t offer any OData query options.<\/strong> Thus, the idea for adapters was born!<\/strong><\/p>\n\n\n\n The existing search had a particular set of operations, numeric ranges, field matches, \u201cor field matches\u201d, and arbitrary parameters. These sorts of operations can be expressed in a single flat data structure, so we created the dispatch machinery to convert OData queries into a single class instance and call the requested Synergy method, passing that instance to it. To maintain high performance when dispatching, we generated the dispatcher using low-level LINQ expressions to take advantage of their precompilation features. This means that Harmony Core does the complicated task of generating code to map an OData query to a Synergy data structure the first time the request is made.<\/strong> After that, it just runs the compiled code at full speed. This was a bit of a challenge to implement, but we think it will make web services much more performant.<\/p>\n\n\n\n After the conference, we picked up a few more early adopters, including several with repositories that hadn\u2019t been used for xf<\/em>ODBC so they didn\u2019t have any relations defined. As we worked with these repositories, we came to realize that Harmony Core could not describe a two-way relationship when a tag field was involved.<\/strong> A tag field is a literal that indicates record type when multiple record types are stored in a single ISAM file. Only foreign keys can specify tag literals, but repositories can\u2019t have foreign-to-foreign key relations, which would allow for two-way relationships. (Repositories can have only access-to-access key relations and foreign-to-access key relations.) After some back and forth on this, we came up with an answer: enhance CodeGen. CodeGen now looks across relations defined for structures and glues both foreign keys together in a foreign-to-access\/access-to-foreign key relationship. To do this, CodeGen uses either the foreign key naming convention or description fields for the foreign keys.<\/p>\n\n\n\n In addition to fun with foreign keys, we ran into some interesting EF Core limitations when describing the fields in a join. Synergy allows keys to be comprised of up to eight segments that can total up to 256 bytes. EF Core has a loosely similar concept, composite keys.<\/strong> When using composite keys to describe a relationship, however, the parts of a composite key must have matching types.<\/strong> This is not a restriction in Synergy, so we had to figure a way around this limitation. The solution we came up with was to add another type of field metadata: composite fields<\/strong>. These fields in the generated DataObjectMetadataBase class allow us to keep track of the size, position, and type of each supplied key segment, while exposing only a single dummy field to the EF Core Navigation property.<\/p>\n\n\n\n The work we did to create composite fields in metadata opened up an additional opportunity. When we introduced Harmony Core at the conference, it was possible to create calculated fields simply by defining a property with a getter that returned the data in question along with a setter that either threw an exception or wrote to the actual underlying field, depending on your use case. But Harmony Core<\/strong> didn\u2019t yet understand which fields were required when selecting a calculated field while using sparse Select with xf<\/em>Server<\/strong> for remote data access. Thanks to composite fields, this is now implemented. To take advantage of this enhancement, you\u2019ll need to create a property in your DataObject\u2019s partial class and implement a partial class for its corresponding DataObjectMetadataBase with a private void method called InitializeCustomFields. InitializeCustomFields just needs to call AddFieldInfo (which creates a composite field with the same name as the calculated field), passing references to the field metadata for each of the fields required to calculate the field.<\/p>\n\n\n\n Over the past few months, we\u2019ve been polishing our templates, building out our documentation, and fixing bugs reported by our early adopters. With all these enhancements, Harmony Core should be a Synergy developer\u2019s best bet for adding Synergy web services. Still not sure if this is the right choice for your applications? We\u2019re working on so much more.<\/p>\n\n\n\n Because Harmony Core is an open-source project, we want to share not only our technical roadmap, but also our goals for the project. We also want to set expectations up front so you can help keep us accountable and on track.<\/p>\n\n\n\n Technical Direction<\/p>\n\n\n\n There are so many things we can do to extend the Harmony Core framework, but we\u2019ve chosen a few large items and a smattering of smaller ones to focus on over the next 12 months. We\u2019ll continue to post blog updates as features are delivered and the direction evolves.<\/p>\n\n\n\n Webhooks are user-defined HTTP callbacks that are usually triggered by some event, such as a status update for an order, or when the quantity of something drops below a certain level. Webhooks are very useful when you have to glue two complex systems together.<\/strong> Imagine your company has grown by acquisition and you find yourself needing to merge the underlying data and business functions of two different IT systems. If you\u2019re trying to build a unified RESTful view of both systems, your view is going to need to be notified when important events occur in the underlying system. Webhooks are the best way to do this. We think this sort of functionality will be crucial in many scenarios. If you have thoughts about how you would like to use this technology, please post on https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/61<\/a>. We aren\u2019t certain what shape this support will take, but we will be actively pursuing this. Large (1-3 months)<\/p>\n\n\n\n While we\u2019ve already implemented adapters, there is so much more we can do to extend their uses. Currently, adaptors apply only to filters, but we can further blur the line between operations provided by EF Core and custom code. This would entail implementing additional attributes to indicate that a particular field or collection needs to be expanded. In general, our design philosophy is to flatten OData queries into the sort of data structures that customers currently use to implement custom solutions. Supporting custom Synergy code is a very important part of Harmony Core<\/strong>; many of you have decades of very important business logic that you want to expose to the world. We would be doing you a disservice if the full OData query experience were not applicable to your important business logic. Adaptor enhancements will enable you to take full advantage of uniform OData query syntax<\/strong>, whether you\u2019ve implemented an endpoint with custom code or are using the Harmony Core EF Provider. See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/85<\/a>. Large (1-2 months)<\/p>\n\n\n\n Not all customer data is laid out the way we developers would like it to be. Sometimes this is for historical reasons, or it might be the result of business requirements. Whatever the reason, we want to make sure it\u2019s possible to fully expose your data via OData and EF Core. This means we need to add at least some support for nested subqueries.<\/strong> The main use case we\u2019re thinking of is when data for different branch locations is stored in separate files. In order to join across all branches, we will have to split the query into several parts, storing some intermediate results in a hash lookup table. While this doesn\u2019t amount to support for completely arbitrary subqueries, we think it will solve most customer needs. See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/83<\/a>. Large (1-3 months)<\/p>\n\n\n\n Prior to the conference, we added support for reading xf<\/em>ServerPlus method catalogs. We also added initial support for generating the required wrappers and glue to allow existing xf<\/em>ServerPlus methods to be called using the JSON-RPC 2.0 protocol and the Traditional Bridge portion of Harmony Core. This needs to be extended to support all the data types and coercion that exist in the wild.<\/strong> See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/84<\/a>. Large (1-3 months)<\/p>\n\n\n\n At the conference we rhetorically asked, \u201cIs this ACID?\u201d Spoiler alert: we\u2019re pretty close but not quite all the way there. The missing piece of the puzzle is a durable transaction log,<\/strong> which is really just a fancy name for an on-disk data structure used as part of a two-phase commit. As transactions are being committed to the underlying ISAM files, Harmony Core would write a log of the operations that it\u2019s performing with information on the state they are in should there be a hardware or software fault that interrupts ISAM operations. In addition to its verification duties, the transaction log would also enable us to undo any changes that were only partially committed. When combined with innovations at the operating system level (such as Storage Spaces Direct in Windows Server 2019) and ISAM resiliency in Synergy\/DE 11, we think the transaction log will provide the foundation for highly available, fault-tolerant Synergy applications and web services. See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/82<\/a>. Large (2-4 months)<\/p>\n\n\n\n CodeGen integration with MSBuild<\/strong> \u2013 We\u2019ve wanted to improve the process of building projects that use CodeGen templates. The degree to which we rely on CodeGen templates for Harmony Core projects is staggering. Keeping generated code up to date should be a build system operation rather than something for humans to manage (i.e., forget). Small (1-2 weeks)<\/p>\n\n\n\n CodeGen integration with NuGet<\/strong> \u2013 Delivering updates to CodeGen templates is tricky and manual. Those are a pair of attributes that should never be associated with tasks that must be performed frequently. Our answer to this problem is to ship template (.tpl) files using NuGet packages. This way, your build system can reference a specific version number for the templates you\u2019re using. If updates are available, all you have to do is bump the requested version, and CodeGen will go download the requested package of templates. Small (1-2 weeks)<\/p>\n\n\n\n .NET CLI scaffolding tool<\/strong> \u2013 The command line interface for .NET Core introduced a concept known as scaffolding. Rather than shipping complex logic in wizards, project templates, or item templates, the dotnet tool allows you to offer a scaffolding generator. Conceptually, it\u2019s very similar to a wizard in Visual Studio, but it\u2019s much easier to work with and can be used without Visual Studio. Because Harmony Core relies heavily on CodeGen templates and source conventions, it\u2019s currently more difficult than it should be to add new functionality to an existing project. Once we have a scaffolding tool, it will be much easier to add new endpoints, new structures, custom code in partial classes, and wrappers around existing code. Small (1-2 weeks)<\/p>\n\n\n\n Multiple xf<\/em>Server connections<\/strong> \u2013 Currently the Harmony Core EF provider uses only a single xf<\/em>Server connection. We need to build additional infrastructure into the provider to maintain a pool of worker threads that each have an open xf<\/em>Server connection. And the FileChannelManager class will need some additional smarts to deal with request queuing and to use existing threads with requested channels. See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/79<\/a>. Small (1-2 weeks)<\/p>\n\n\n\n Additional configuration options for FileChannelManager and, more generally, the pooling mechanisms<\/strong> \u2013 Currently we open file channels and never close them for the duration of a FileChannelManager object. This improves the performance of individual requests, but it\u2019s wasteful in situations where there are hundreds of files, but few that are commonly accessed. The plan for this is to implement a least-recently-used (LRU) eviction strategy. Keeping track of the total list of all files that have ever been opened and the relative frequency of file opens should allow us to auto-tune the number of channels to keep in the LRU list. See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/81<\/a>. Small (1-2 weeks)<\/p>\n\n\n\n Traditional Bridge SSH connection multiplexing<\/strong> \u2013 Currently, we open one SSH connection for each Traditional Bridge process on the remote server. For a very large number of processes, this is wasteful because connections are sitting idle most of the time. We can instead create up to 10 sessions per SSH connection (or more if the operating system is configured for it), which would enable us to have many more worker processes without the additional SSH overhead. This would be configurable for cases where SSH connection scaling isn\u2019t the bottleneck. See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/80<\/a>. Small (less than 1 week)<\/p>\n\n\n\n Diagnosing issues in production is one of the most challenging tasks for a developer. We\u2019re considering two features to make this less daunting: per-request logging levels and per-request Traditional Bridge debugging.<\/p>\n\n\n\n Per-request logging levels<\/strong> \u2013 Harmony Core offers extensive logging along with a logging framework that works well with Synergy data types. This is great in development, but in production it can destroy performance or collect sensitive data that shouldn\u2019t be logged. By providing a custom HTTP header with a request, the logging level could be set specifically for that request. This means you could get full fat logging from a production server while the enhanced logging is turned off for the rest of your requests. See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/77<\/a>. Small (less than 1 week)<\/p>\n\n\n\n Per-request Traditional Bridge debugging<\/strong> \u2013 Similar to per-request logging levels, we can use custom HTTP headers to cause the current request to launch a debuggable Traditional Bridge process. This would cause a separate .dbr and command line to be run on the remote system for this one request, enabling you to attach a debugger from Visual Studio to the running remote process, even in a production environment with thousands of normal requests being serviced concurrently. See https:\/\/github.com\/Synergex\/HarmonyCore\/issues\/78<\/a>. Small (less than 1 week)<\/p>\n\n\n\n What will determine the success of this project? Ultimately, it will be you, the customer. So we want to make sure that implementing and interacting with the web services you build with Harmony Core is as painless as possible.<\/p>\n\n\n\n For 2019, our goal is to have at least four customers that have successfully deployed Harmony Core web services or are in the final stages of developing real-world solutions that make extensive use of Harmony Core. This is not as aggressive as it sounds; we already have four customers in various stages of development, and we aren\u2019t just aiming to get four customers; we want those customers to be happy with the quality of Harmony Core and with the features it provides. To determine if these customers are happy, we\u2019ll keep track of the net promotor score for all the different parts of Harmony Core. For example, if you have a complaint about the documentation or need more help than we expected in order to implement something, that\u2019s a sign that we are missing documentation, examples, educational material, blog posts, or functionality. We\u2019ll need to hear this from you to know how to do better. Once an issue is found, we\u2019ll address it and follow up to determine if the solution actually worked. The number of adopters can\u2019t and won\u2019t be our only metric for success. Additionally, we anticipate that we\u2019ll need to interact with non-technical decision makers and non-Synergy developers who in some cases will know best if Harmony Core is actually solving their business needs.<\/p>\n\n\n\n We feel that open-source development is a two-way street; in order to be successful, we need non-Synergexian contributors to create pull requests and issues on GitHub. We\u2019re hoping for at least four non-Synergexian contributors to submit pull requests or issues by the end of 2019. The contributions can be for documentation fixes, new samples, or even new core functionality. We will tag GitHub issues that we think are a good fit for external contributors. For a non-tagged issue, we would ask that you give us a heads-up on GitHub to make sure we aren\u2019t currently working on a solution for the issue. In general, we\u2019re looking to add features and functionality that will be applicable to the majority of users, so we won\u2019t want to incorporate code that is specific to a company or line of business.<\/p>\n\n\n\n When it comes to open-source products, Synergex\u2019s stance has generally been to provide the software as-is with no guarantees. For Harmony Core, however, you can expect Synergex to provide more robust support. Although the development path for Harmony Core is different than for our proprietary products, we want companies of all sizes to feel comfortable taking such a large dependency on Harmony Core. We think this can be accomplished using GitHub issues, but we\u2019re looking to you, the Harmony Core community, to tell us what kind of service-level guarantees your management team will need.<\/p>\n\n\n\n Our Developer Support team is already training up on Harmony Core, and we plan to train them to write and understand CodeGen templates. There are quite a few new areas inside CodeGen that have been added as a result of the Harmony Core project, and you can expect the support team to have up-to-date knowledge on those enhancements. We will also begin looping Support into our ongoing development and deployment efforts with customers. We believe there is no training substitute for extensive guidance while getting your hands dirty on the inner workings of a product, and we think the team will be very well equipped to tackle and triage Harmony Core support cases in the near future.<\/p>\n\n\n\n In addition to providing help though Developer Support, we\u2019re planning on incorporating some educational events and materials to ensure that you can successfully implement and interact with Harmony Core web services. We will be hosting office hours monthly for anyone interested in a chance to hop on a GoToWebinar session and ask questions or work through implementation issues. Office hours are a common feature in open-source projects run by companies who want make sure complex, difficult-to-solve issues aren\u2019t ignored or missed or otherwise languish without solutions. You can also expect regular blog posts recapping the development progress that has taken place, and we\u2019re interested in posting project post mortems (with identifying information scrubbed, of course). We think letting the Harmony Core community see the good, the bad, and the difficult in project implementation will give developers and management confidence that they will also be successful.<\/p>\n\n\n\n Open-source products are usually documented by their creators, and this will be true of Harmony Core. Our tech writing team will be involved (organizing, editing, and helping direct the documentation), but all documentation and samples will come from developers working on Harmony Core. This is a departure from how documentation has traditionally been developed at Synergex, but we think this will be the best way to document this project.<\/p>\n\n\n\n Jeff joined Synergex in 2006 and he brought his passion for open source and standards-based technologies with him.<\/p>\n\n\n\n His first contribution to our product suite was Synergy DBL Integration for Visual Studio, for which he architected and implemented items involving Intellisense, debugging, and migration tools. He championed the importance of running Synergy on .NET Core and was the lead developer of that project.<\/p>\n\n\n\n Jeff has been instrumental in Synergex\u2019s embrace of Service Oriented Architecture (SOA) and standards-based technologies. When the need for a unified solution to creating web services for all Synergy\/DE applications arose, Jeff and Steve Ives created the Harmony Core Framework with an emphasis on using standardized technologies such as OData, Swagger, Asp.NET Core, .NET Core and Entity Framework Core.<\/p>\n\n\n\n Jeff has worked with various departments within Microsoft over the years, and has made significant contributions to the open source Microsoft CoreRT project.<\/p>\n\n\n\n Following an initial background in operating systems, networking and systems administration early in his career, Steve realized that his real passion and talent was in the field of software development.<\/p>\n\n\n\n Having worked for one of the largest Synergy\/DE developers in the United Kingdom, Synergex frequently contracted Steve to present on Synergex locally in Europe. These engagements consisted of presenting on the company and products during meetings, delivering training seminars on the use of the products, and consulting with other customers about how to address specific technology requirements.<\/p>\n\n\n\n Steve formally joined the Synergex Professional Services group in 1997. Having held the position of Senior Consultant for over 20 years, Steve has assisted many Synergy developers to architect, design and implement a wide variety of software projects. Each of these projects involves Synergy\/DE in some way, and many involve a wide range of other development languages and technologies.<\/p>\n\n\n\n In recent years, Steve has been a major contributor to several Synergy-related open source development projects, including:<\/p>\n\n\n\n Steve is passionate about assisting software developers to continue to leverage the investment that they have made in their Synergy code base over the years, and to continue to see a return on their ongoing investments in their code.<\/p>\n\n\n\n Johnson joined Synergex in 2014 as a QA engineer. He got his start by testing Synergy releases and the Synergex Resource Center Community, as well as verifying trackers and automating the testing of those trackers. You can read about his testing techniques<\/a> and automated testing<\/a> at Synergex.<\/p>\n\n\n\n In addition, after moving into a software development role, Johnson made many contributions to our Synergy DBL Integration for Visual Studio (SDI) product including migrating from Windows Forms to the WPF property pages and the product installers from InstallShield to a newer technology. He has since developed all of our Synergy product installers with the open-source language, WiX. He worked closely with Fire Giant, the custodian of WiX, to ensure the Synergy installers are using their most up-to-date technology.<\/p>\n\n\n\n Prior to joining Synergex, Johnson was an active member of the Association for Computing Machinery (ACM) at his alma mater. Along with his team, he even won their biannual International Collegiate Programming Contest. His background in test along with experience in Visual Studio development and solid foundational knowledge of algorithm design make Johnson the perfect addition to round out the Harmony Core team.<\/p>\n","protected":false},"excerpt":{"rendered":" If you attended the 2018 Synergy DevPartner Conference in New Orleans, you probably remember hearing about Harmony Core. Harmony Core is Synergex\u2019s open-source solution for allowing access to [\u2026]<\/span><\/p>\n","protected":false},"author":21,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[150],"tags":[],"post_folder":[151],"class_list":["post-12576","post","type-post","status-publish","format-standard","hentry","category-harmony-core"],"yoast_head":"\n![\"What's](\"https:\/\/synergex.github.io\/HarmonyCore\/assets\/2019-03-22\/image1.png\")
<\/figure>\n\n\n\nConference Conversations<\/h2>\n\n\n\n
Real-World Findings<\/h2>\n\n\n\n
Exposing Synergy Code as a Web Service<\/h3>\n\n\n\n
Querying with OData<\/h3>\n\n\n\n
Repository<\/h3>\n\n\n\n
Our Plan Going Forward<\/h1>\n\n\n\n
Webhooks<\/h3>\n\n\n\n
Adapters<\/h3>\n\n\n\n
Joins<\/h3>\n\n\n\n
A Migration Path for xf<\/em>ServerPlus<\/h3>\n\n\n\n
Durable Transaction Log<\/h3>\n\n\n\n
Tooling Improvements<\/h3>\n\n\n\n
Concurrency Improvements<\/h3>\n\n\n\n
Better Debugging<\/h3>\n\n\n\n
Harmony Core Goals<\/h2>\n\n\n\n
Open-Source Technology: The New Frontier<\/h3>\n\n\n\n
What You Can Expect from Synergex<\/h2>\n\n\n\n
Support<\/h3>\n\n\n\n
Documentation<\/h3>\n\n\n\n
Meet the Harmony Core Team<\/h2>\n\n\n\n
Jeff Greene, Harmony Core Product Manager<\/h3>\n\n\n
![\"\"](\"https:\/\/www.synergex.com\/wp-content\/uploads\/2023\/01\/speaker-img-jeffgreene.png\")
<\/figure><\/div>\n\n\n <\/h3>\n\n\n\n
<\/h3>\n\n\n\n
Steve Ives, Harmony Core Co-Architect<\/h3>\n\n\n
![\"\"](\"https:\/\/www.synergex.com\/wp-content\/uploads\/2023\/01\/speaker-img-steveives.png\")
<\/figure><\/div>\n\n\n\n
Johnson Luong, Harmony Core developer<\/h3>\n\n\n
![\"Johnson](\"https:\/\/synergex.github.io\/HarmonyCore\/assets\/2019-03-22\/image4.png\")
<\/figure><\/div>\n\n\n