I am confused now....

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,
I was just asigned a project and was doing some research and am now confused
with Enterprise Service, Remoting and Web Services. Now I am not sure which
will be benificial to my project. I need to create and expose a component to
process credit card payment and log the details to a database. The component
will be used by an asp.net app locally and then our sister company need to
send payment to the same component. My idea is to create the component on
enterprise services and then use remoting for local access and web service
for external access (by sister company). Can some of you offer your 2 cents
here? What is Enterprise Service used for and when, if needed, would remoting
come into play? So much infor these days.............I need to SCREAM....

Thanks
 
I will add my $.02 here, maybe someone will fly by and disagree with me.

Since you have multiple requirements here (both internal and external) I
would (potentially) work it this way.

Keep any external facing things as web services. This keeps you open to
external partners and do not tie them into Windows. Webservices use open XML
based data so Java, and non-windows platforms can use them. This also allows
you to keep the external face of the service available to your partners
within a decent security model. You can host it in a web type DMZ area for
example.

Keep all internal facing interfaces as remoting objects. Gives you the same
type of benefits as web services but adds the ability to use binary instead
of XML based data (faster transport on the wire) and since you have control
over the internal environment you can guarantee that binary data will work
in remoting.

Since both the exposed services will need to perform the same function, you
could use a common enterprise services based module as the backend to both
services. Design the engine to run in enterprise services and call that
engine from both interface facades to expose the service to a standard set
of consumers.
 
Just a thought...

Why you have to create two interfaces? You can just go with webservices
and have access for both internal/external users. For the internal
users (if it is through a LAN) there will be no significant performance
overhead if you use webservices, thus the performance argument does not
stand well.

Keep in mind that remoting in general is not even recommended by
Microsoft in the WS Era...

If you want to use the component locally then just initialize it the
normal way ... new Component()

Tasos ...
 
And of course, from your ASP.NET app you can directly call Enterprise
Serviced Components ...
 
Back
Top