[转]AIF Services and the .Net BC - Where and When-CSDN博客

pasted from: http://dynamics-ax.blogspot.com/2010/05/aif-services-and-net-bc-where-and-when.html

One of the sessions I attended at Convergence 2010, was the AXUG Software
Architect SIG. The initial coverage post for that session, can be found at the
following link.: Coverage
of AXUG Software Architect SIG at Convergence 2010

In this, a good
bit of topics were on the minds of the people who attended. One of them was
around AIF Services and the .Net BC. What a good bit of discussion for this
surrounded, was where and when to use either?

As promised in the above
post, this is a start into digging deeper into the topics covered during that
session. So for this When and Where should AIF Services or .Net BC be
used, when connecting into a Dynamics AX instance?

This is a valid
question actually, as both offer the ability to interact with Dynamics AX. Both
offer different pro's and con's as well.

Lets look at the nature of
these two different paths for interacting with Dynamics AX from an outside
application, service or other LOB application.

First AIF
Services. AIF Services are targeted specific end points for document
exchange in and out of Dynamics AX, on a transactional, one off level. These
services are generated from an AOT Query element, and make use of Axd* Classes,
which in turn AX uses to generate the WCF Services that end up being hosted in
IIS.

These are WCF services, and so when consumed by a .Net Application,
BizTalk, or other LOB Application, will interact as such. These services
represent Dynamics AX "Documents". Which could be reading a customer, a sales
order, creating a purchase req, or any custom AIF Service you create.

From looking at past use, and desgined nature of AIF Services, these
best serve the one-off, transactional calls. Meaning, if the nature of your
integration is calling to create a Sales Order, or lookup a customer, then AIF
Services are best suited for this type of interaction. Notice the key on
"a" meaning singular interactions, with distinct returned result sets.

Moving on to the .Net BC, it offers a different type of access
than the AIF Services. With the .Net BC, you get direct access to AOT objects.
So you could in theory, access the Query object that a given AIF Service is
created from, directly. Not sure why though, other than to look up information.
:-)

With this direct access, that means you have direct access to X++
classes, tables, and business logic directly.

So the nature of the .Net
BC, is meant to expose to .Net based code / assemblies, the AOT, for working
with the AX AOT objects and business logic, directly from .Net.

AIF
Services, there is a layer of Abstraction, and therefore a layer of possible
extra validation, and context control over data, that would not actually exists
through the .Net BC.

Looking at these two options for working with
Dynamics AX, still we have the question of Where and when? Since we have a base
understanding of the nature of these two choices, lets move forward in answering
this question.

Since AIF Services are meant to act in the "a", singluar
transactional nature, consuming a AIF Service is best for when you have calls in
the nature and context of creating, reading, updating or deleting (CRUD) data,
in the form of "Document" based information. This could include creating a sales
order, a purhcase req, looking up information on a item, or a customer.

Comparing AIF Services, to the .Net BC for achieving this same need, I
have seen the AIF performs better, and is best suited for this. Also using the
AIF for these needs, you end up having that layer of abstraction that enables
control of the how data is accessed, and the shaping possibly of that data in a
uniformed control fashion.

The other benefit for using AIF Services, is
was generated, enables the creation of composite applications, that include AX
with an SOA type of architecture in mind.

Moving to the where and when
for the .Net BC, lets say you have a need for pushing in a massive amount of
data? Or you want direct access to maybe having a complex LOB application
workflow, that is deeply tied to the business logic in Dynamics AX, that might
actually live in X++, and want to expose and reuse that.

Then .Net BC is
best suited for this type of integration, and performs better. It performs best
with larger amounts of bulk data, or the need for exposing possibly complex
workflows, or deep X++ business logic, or custom X++ business logic, and having
that tie in with other LOB applications or Enterprise needs.

I hope the
above helps answer some of this, and I welcome any comments from anyone on their
own thoughts for this topic.

If we look forward with Dynamics AX, take a
look at some of my past post. AX internally even will be making use of AIF
Services for "document" level integration and data flow needs. Also AX moving
forward is turning into a true Managed Code, at the kernel ERP package. This
means tighter integration for the AOT into .Net, in a more native fashion will
exists.

That's all for now, but check back soon, and again feel free to
leave comments on this topic!