.Net BC Custom App, Part II
Well now that we talked a little bit about theroy / design behind the custom ASP.Net Application, lets talk about more on the design. In my thoughts, you always want to be absrtact. Meaning the layers that seperate and operate should be as much independant as they can.
Some rules of thumb here for me:
(1) All business logic lives in X++. This is Very important. Doing this keeps the AOS as the central point for performing all Business Logic on Dynamics AX related data and objects.
(2) All use of .Net BC code should be contained within a Web Service or Web Services. This is a very important layer of abstraction. This moves your solution into the JBOWS / SOA arena, where it needs to be anyway. This allows for multiple interfaces, into the same access logic. Meaning, though we are developing and custom ASP.Net application front end, we could easily create a Mobile Windows, regular windows, Java, etc. etc. number of front end or middleware interfaces into this same Web Service(s).
Now there can be other obvious and not so obvious rules of thumb that would apply, depending on the nature and design of the application. Like user size for example. Maybe your custom app will be used by a lot of concurrent users? So possible considerations for pooling, Session variables, connection pooling, as well as designing your application to work well in a web farm. Where multiple servers make up a single virtual server. All of these things must be considered in the design of your appliocation. For now though can be after thoughts that you decide when prompted for such needs.
So here we have our base design: (a) All business logic lives in X++, (b) All access to the business logic will be contained with web services.
This means you needs at least 1 instance of Dynamics AX, 1 AOS, and 1 IIS box. Preferred these be different boxes of course, but in development / test can be the same.
Alright well check back tomorrow as we continue our dive into our custom ASP.Net application!
Find a job at: www.DynamicsAXJobs.com
Some rules of thumb here for me:
(1) All business logic lives in X++. This is Very important. Doing this keeps the AOS as the central point for performing all Business Logic on Dynamics AX related data and objects.
(2) All use of .Net BC code should be contained within a Web Service or Web Services. This is a very important layer of abstraction. This moves your solution into the JBOWS / SOA arena, where it needs to be anyway. This allows for multiple interfaces, into the same access logic. Meaning, though we are developing and custom ASP.Net application front end, we could easily create a Mobile Windows, regular windows, Java, etc. etc. number of front end or middleware interfaces into this same Web Service(s).
Now there can be other obvious and not so obvious rules of thumb that would apply, depending on the nature and design of the application. Like user size for example. Maybe your custom app will be used by a lot of concurrent users? So possible considerations for pooling, Session variables, connection pooling, as well as designing your application to work well in a web farm. Where multiple servers make up a single virtual server. All of these things must be considered in the design of your appliocation. For now though can be after thoughts that you decide when prompted for such needs.
So here we have our base design: (a) All business logic lives in X++, (b) All access to the business logic will be contained with web services.
This means you needs at least 1 instance of Dynamics AX, 1 AOS, and 1 IIS box. Preferred these be different boxes of course, but in development / test can be the same.
Alright well check back tomorrow as we continue our dive into our custom ASP.Net application!
Find a job at: www.DynamicsAXJobs.com
Labels: .Net, ASP.Net, Business Connector, Custom, Dynamics AX, JBOWS, SOA, Web Services
posted by brandon | 8:01 AM
|
3 comments
