tion deploys a data access layer to the IIS box running Web Services, and uses ASP.NET session
state to manage logins and state information (see Figure 1-6). This service layer is then
leveraged by Windows Forms and Web applications distributed across several North American
locations. Web Service extensions are leveraged to encrypt authentication and sensitive data
on the wire.
The data access layer leverages the Data Access Application Block, which is part of a
downloadable package called Enterprise Services. This set of services ships with all the source
code, and so can be customized. The Data Access Application Block ships with support for
SQL Server, Oracle, and DB2. DB2 requires the managed provider available from IBM. There is
also a stateful business object layer used within the Windows Forms user interfaces and dur-
ing the processing of a request for an ASP.NET page. It’s good to use stateful objects within a
process boundary; you need stateless objects when services could possibly be deployed to
different machines, processes, or even app domains.
Web Services are designed as a stateless service layer. This is considered to belong to the
middle tier of a distributed application, but has a very different design than a typical stateful
type designed with the principles described by OOAD.
The funny thing about SOAP, the “Simple Object Access Protocol,” is that it is not at all object oriented. Services designed to be exposed using SOAP messages actually look a lot more like traditional procedure function calls might: atomic methods that accept large
parameter lists that perform their work based entirely upon the information passed to them,
and when finished, are destroyed completely (see Figure 1-7, the class on the right).
Running Codes
0 comments:
Post a Comment