Codename DexNEXT - Part 1
Codename DexNEXT - Part 1 of 2
You have probably been hearing the term kicked around the circles for almost a year now, but codename DexNEXT represents a major milestone in the evolution of the Microsoft Dexterity development platform and the Microsoft Dynamics GP application - Microsoft Dexterity is Microsoft Dynamics GP's native development platform.
DexNEXT is fundamented on the vision that Microsoft Dynamics GP needs to consume as well as expose services to become a solid cloud offering. After all, when referencing "cloud", in reality we are referring to the various services that live in the cloud. It is generally accepted that the Microsoft Dynamics GP 2013 web client is the first step in that direction.
As such, starting with Microsoft Dynamics GP 2015, and to a certain extent, Microsoft Dynamics GP 2013 R2 the Microsoft Dexterity and Microsoft Dynamics GP development teams are evolving the core architecture to support services as a native component. The key requirements driving this evolution are:
- Elasticity and scalability
- Support for various form factors
- Functionality exposed via an integration layer
- Support for various localization models (international markets)
- Systems interconnectivity and interoperability with other service-based applications
- Support for platform tools
- Continuous support for the current investment (time, money, and code base).
The immediate objectives of this strategy are to:
- Develop a long term strategy centered around services
- Expose sanScript logic as a service call
- Enhance Dexterity's .NET capabilities
- Better alignment with Windows Azure
The current service architecture has been mainly focused around the use of eConnect and Web Services at the integration layer. Recently, we have seen additional work carried out around the delivery of Windows Store companion apps, with Business Analyzer being the first application of this kind. Then there's the web client, exposed via a Windows Communication Foundation (WCF) service and consumed via a browser.
The new service-based architecture aims to change this a bit by delivering native services, derived from existing Microsoft Dynamics GP business logic.
In the above schematics, the GP Services replace the traditional eConnect and Web Services integration components, while being tightly coupled to the Microsoft Dynamics GP dictionary resources - integration are not done through database calls, but rather a unified set of RESTful service calls.
We can always speculate about the long term vision of this architecture. It is not inconceivable to believe elements such as the user interface and core application functions - the entire application - can be seen as services that can be consumed by other applications such as Windows Store companion apps and even application offered through the Windows Azure marketplace. This will also facilitate integration to other non-Windows platforms and applications.
In my next article, I will talk about some of the underlying changes Microsoft Dexterity will be undergoing in order to accommodate to expose and consume services.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
You have probably been hearing the term kicked around the circles for almost a year now, but codename DexNEXT represents a major milestone in the evolution of the Microsoft Dexterity development platform and the Microsoft Dynamics GP application - Microsoft Dexterity is Microsoft Dynamics GP's native development platform.
DexNEXT is fundamented on the vision that Microsoft Dynamics GP needs to consume as well as expose services to become a solid cloud offering. After all, when referencing "cloud", in reality we are referring to the various services that live in the cloud. It is generally accepted that the Microsoft Dynamics GP 2013 web client is the first step in that direction.
As such, starting with Microsoft Dynamics GP 2015, and to a certain extent, Microsoft Dynamics GP 2013 R2 the Microsoft Dexterity and Microsoft Dynamics GP development teams are evolving the core architecture to support services as a native component. The key requirements driving this evolution are:
- Elasticity and scalability
- Support for various form factors
- Functionality exposed via an integration layer
- Support for various localization models (international markets)
- Systems interconnectivity and interoperability with other service-based applications
- Support for platform tools
- Continuous support for the current investment (time, money, and code base).
The immediate objectives of this strategy are to:
- Develop a long term strategy centered around services
- Expose sanScript logic as a service call
- Enhance Dexterity's .NET capabilities
- Better alignment with Windows Azure
The current service architecture has been mainly focused around the use of eConnect and Web Services at the integration layer. Recently, we have seen additional work carried out around the delivery of Windows Store companion apps, with Business Analyzer being the first application of this kind. Then there's the web client, exposed via a Windows Communication Foundation (WCF) service and consumed via a browser.
 |
| Current Service Architecture |
The new service-based architecture aims to change this a bit by delivering native services, derived from existing Microsoft Dynamics GP business logic.
 |
| DexNext Service Architecture |
In my next article, I will talk about some of the underlying changes Microsoft Dexterity will be undergoing in order to accommodate to expose and consume services.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Comments