System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnection owningObject, Boolean withFailover) at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject, Boolean withFailover) at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart) at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance) at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance) at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection) at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options) at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection) at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory) at System.Data.SqlClient.SqlConnection.Open() at System.Data.Common.DbDataAdapter.QuietOpen(IDbConnection connection, ConnectionState& originalState) at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) at ftp_controls.Common_.Utility_.GetCustomRegPropertiesByUrl(String url) FTPOnline - How SOA Benefits Developers
Welcome Guest!
Create Account | Login
Locator+ Code:

FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly

How SOA Benefits Developers
Developers can gain from SOA just as much as enterprise architects can. Here are five reasons for developers to get involved with SOA.
by Lee Sherman

Posted March 30, 2004

The Stick
Existing application architectures have failed to keep pace with changing business models. As enterprises struggle, not only to develop new applications in-house but also to integrate their applications with those of their partners, suppliers, and customers, they are running head-on into the limitations of monolithic, tightly coupled applications in which each subsystem is physically bound to the other subsystems at compile and run time. Not only does a change in one system cause the others to break, but it locks developers into what can become a seemingly endless cycle of coding, compiling, and testing. Developers must also deal with increasingly heterogeneous environments in which each application brings a new set of APIs to learn and interface with.

Earlier approaches to integrating applications across heterogeneous platforms such as CORBA have failed to live up their promise, in part because of a lack of standardization among object models, and in part because even CORBA didn't take into account the need for a more loosely coupled approach to rapidly developing, integrating, and reusing applications.

Within this context, a service-oriented architecture can be seen as the next evolutionary step in the development of application architectures, and one that replaces monolithic, tightly coupled applications with modular and loosely coupled ones.

SOAs use a modular approach in which each composite or virtual application is composed of a number of different discrete services, each derived from a freestanding application. Services can reside anywhere on a network, and are discovered and accessed using standard interfaces through both public and private registries. Services can be derived from existing applications, by exposing key functionality as services, as well as from new service-oriented applications.

SOA, unlike CORBA, is not a technology in its own right, though it takes full advantage of technologies such as XML, UDDI, SOAP, WSDL, and Java-based messaging. It's really a new mindset and architectural approach for coping with the need for flexibility in enterprise application architectures.

Object-oriented development is the victim of its own success. At this point in the evolution of enterprise software development, object-oriented languages (particularly Java), methods, and frameworks are now well understood. On the surface it might appear that the decision whether to use an object-oriented approach or a service-oriented one comes down to how tightly or loosely coupled the software you are developing is from the other software it will interact with. The conventional wisdom—that object-oriented development is good for tightly coupled integrations, while SOA makes sense for loosely coupled ones—while generally true, is a bit of an oversimplification. It isn't a choice of using one or the other. As many of the newest tools suggest, developers will need to understand both in order to address the full spectrum of enterprise applications they'll be tasked to build.

SOAs don't replace object-oriented development, which will remain the dominant means of development for individual applications. But while these architectures and frameworks will continue to be refined and maintained, the real action will be in developing an infrastructure that can support an ecosystem made up of collaborating applications. SOAs augment applications, whether they are object-oriented or not, and they help developers do that by providing generalized, reusable interfaces at the business level rather than the component level.

In addition, SOAs require a paradigm shift away from a client/server approach to application development to thinking about event-driven interactions. Because services can and will be inserted anywhere with a business process, developers must take a broader view of application development. The main difference is in how interfaces are crafted. In an SOA, the key is to develop interfaces that are coarse-grained and not based upon the application's component architecture. Application development, integration, and reuse in the context of an SOA thus dovetails with other disciplines such as business process modeling, workflow, and program-to-program communication.

Back to top

Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home