January 2005 - Posts
There might be a possibility to get some problems in the BizTalk configuration wizard to get connected to SQL Server.
This problem occurs due to windows authentication process and domain account.
The following are some suggestions for configuring BizTalk Server for SQL connection.
BizTalk Server 2004 supports local accounts only on a single-box configuration. You have to use Domain Accounts for multiple box configuration. This implies that the SQL Server and BizTalk server should be on the same machine in order to use local accounts.
More information on configuring BizTalk Server is provided here
One important point to note is that, BizTalk Server supports local group and user accounts only in
single computer configurations. BizTalk Server supports domain group and user accounts in both single and multiple computer configurations.
Refer this guide provides more information on how to configure BizTalk Server 2004 on multiple machines
BizTalk Server single box configuration is pretty straight forward.
SQL Server is needed for BizTalk to work, this is due to the reason that BizTalk keeps all its configurations in SQL Server. But it is not necessary for the application data to be in SQL Server, third party BizTalk adapters are available to communicate with other data sources.
But you have to have SQL Server installed as BTS relies heavily on SQL Server for its infrastructure needs.
There are certain cases where holding a state value in ViewState is not the best option. The most commonly used alternative is Session state, which is generally better suited for:
- Large amounts of data. Since ViewState increases the size of both the page sent to the browser (the HTML payload) and the size of form posted back, it's a poor choice for storing large amounts of data.
- Secure data that is not already displayed in the UI. While the ViewState data is encoded and may optionally be encrypted, your data is most secure if it is never sent to the client. So, Session state is a more secure option. (Storing the data in the database is even more secure due to the additional database credentials. You can add SSL for even better link security.) But if you've displayed the private data in the UI, presumably you're already comfortable with the security of the link itself. In this case, it is no less secure to put the same value into ViewState as well.
- Objects not readily serialized into ViewState, for example, DataSet. The ViewState serializer is optimized for a small set of common object types, listed below. Other types that are serializable may be persisted in ViewState, but are slower and generate a very large ViewState footprint.
View state is used primarily by server controls to retain state only on pages that post data back to themselves. The information is passed to the client and read back in a specific hidden variable called _VIEWSTATE. ASP.NET makes it easy to store any types that are serializable in view state.
However, this capability can easily be misused and performance reduced. View state is an unnecessary overhead for pages that do not need it. As the view state grows larger. it affects performance in the following ways:
Increased CPU cycles are required to serialize and to deserialize the view state.
Pages take longer to download because they are larger.
Very large view state can impact the efficiency of garbage collection.
Transmitting a huge amount of view state can significantly affect application performance. The change in performance becomes more marked when your Web clients use slow, dial-up connections. Consider testing for different bandwidth conditions when you work with view state. To optimize the page disable the view state if you do not use it.
Disable View State If You Do Not Need It
View state is turned on in ASP.NET by default. Disable view state if you do not need it. For example, you might not need view state because your page is output-only or because you explicitly reload data for each request.
To utilize the view state effectively we have to have minimal no of objects in view state. As you increase the number of objects you put into view state, the size of your view state dictionary grows, and the processing time required to serialize and to deserialize the objects increases. Consider the below scenarios before putting your object in to view state.
View state is optimized for serializing basic types such as strings, integers, and Booleans, and objects such as arrays, ArrayLists, and Hashtables if they contain these basic types. When you want to store a type which is not listed previously, ASP.NET internally tries to use the associated type converter. If it cannot find one, it uses the relatively expensive binary serializer.
The size of the object is directly proportional to the size of the view state. Avoid storing large objects.
BizTalk Server features a variety of built-in security functions, providing the framework for businesses to securely exchange data with trading partners.
BizTalk Server controls access to SQL Server by leveraging SQL Server integrated security. With SQL Server integrated security, SQL Server relies on Windows Authentication to grant access to SQL Server resources. By default, all accounts that need to access one of the SQL Server databases required by BizTalk Server must be given a SQL Server integrated logon and be granted access to the database.
BizTalk Server takes advantage of the following security features offered through Microsoft Windows 2000 security:
• Windows account security and local policies
• Integrated Windows and SQL Server logon security
• Microsoft Component Services security and roles
• Public-key infrastructure (PKI)
• Smart cards
• Kerberos protocol
BizTalk Server controls security between trading partners through the use of PKI and Secure Multipurpose Internet Mail Extensions (S/MIME). By exchanging public and private key certificates, trading partners can authenticate each other and encrypt communications through the use of X.509 digitally signed messages and S/MIME (or custom encryption using their own components).
Because BizTalk Server takes advantage of Windows 2000 Secure Sockets Layer (SSL), trading partners can create and use Web pages to securely exchange data over the Internet. SSL, which is implemented in Internet Information Services (IIS), is a protocol that provides privacy between a Web client and a Web server. The protocol begins with a handshake phase that negotiates an encryption algorithm, checks the keys (public and private), and authenticates the server to the client. After the handshake is complete and application data transmission begins, all data is encrypted by using the session keys negotiated during the handshake. Support for open PKI standards and secure protocols, such as IPSec, L2TP, SSL/TLS, and S/MIME, enables a network to be extended to suppliers and partners quickly, while protecting against impostors, data theft, and malicious hackers.
Application state is a global dictionary of late-bound objects. In ASP.NET, you can access application state through one of the following:
- Application property (which is defined in both HttpApplication and Page classes)
ASP.NET includes application state primarily for compatibility with classic ASP so that it is easier to migrate existing applications to ASP.NET. It is recommended that you store data in static members of the application class instead of in the Application object. This increases performance because you can access a static variable faster than you can access an item in the Application dictionary.
Do Not Store COM Objects in Application State
Avoid storing COM objects in application state. Storing COM objects in application state bottlenecks your application because the application uses a single thread of execution(STA Model) when it accesses the component.
1) Bear in mind that impersonation always comes with a cost. Adopt the “Trusted Subsystem Model” to allow the business components in your middle tier to run on a trusted identity (not the impersonated identity). The thread that executes some app logic in the business component will arbitrarily impersonate itself typically for doing a Role Based Check than should immediately revert itself back to the process token (the identity in which it was originally running). This technique will allow calls such as connecting to a database etc to be always done on the process token. This model places lot of trust on the process token, the only downside is in case the process token (identity) is compromised than a resource manager such as SQL Server has no way to authenticate the in coming request. This is most unlikely to happen as business components will be running within a trusted network. Anyway if a trusted network is compromised every thing is compromised
2) Impersonation – Delegation only works when you have Kerberos authentication protocol. Even in Win 2K machines having delegation to work is not default rather it has to be configured to make it work like for example the server machine that needs to use the delegated identity should be configured for “Trusted for Delegation”
Understand how security primitives such as Impersonation works, factor your security requirements right during your architecture (and design) stage. Let security not be an after thought. Also model your architecture and design to create sand boxed environments/boundaries to allow partially trusted assemblies to be isolated from assemblies that run on higher privileges
TechEd 2005, USA is going to be organized from June 5th 2005 to June 10th 2005 at Orlando, FL...
The registration for the same opened on (Jan 10th 2005) and the early bird registration ends on April 15th 2005...
Please visit the TechEd 2005 site to find more... Click Here
BizTalk is built to be a symbolic of two servers: processing server (send/receive, processing, applications) and persistence server (persistence, routing – SQL Server with databases, tables, and stored procs created remotely).
The processing server – actual BizTalk node – was architected to be stateless, that is containing no application state. This way if any BizTalk node gets down, it does not matter. There is no loss of state (or data) because there is no state on BizTalk nodes. Some other BizTalk node picks up the work from where it was last persisted in the SQL Server.
Just a few examples to get it clear. If HTTP message comes and the server goes down. If message was not yet persisted in the database (message box) then the sender did not receive “400” error info and HTTP connection will time out, so the sender will know that the message did not came through. Similarly, if instead of server goes down something else happened during the processing of the message, the sender will get some other message like “500” or other HTTP error. These cases are exactly the same as if connectivity is lost. These cases require the sender to send the message again.
When the message is received and persisted, the processing server health does not matter anymore, because the message is now in the database. Now the sender got its “400” and the message is returned and handled properly. If BizTalk node gets down, it does not matter anymore, because the message is in the database and it will be picked up by some other node.
Similar criteria is present for most other adapters and transports in BizTalk. It is also the case for BizTalk applications – orchestrations. When an orchestration sends or receives a message, its state is saved in the database, so even if BizTalk goes down, the orchestration will be revisited from the point after sending or receiving a message. And, putting the message for delivery into the message box and persisting the state of an orchestration is done in the same transaction. So, even if some simple steps may be repeated, no communications with an external world going through BizTalk are repeated or missed.
Basically, the “Stateless server” architecture helps to build scalable and proper messaging solutions and applications that continue to run despite individual hardware failures. The important part to understand here is, stateless server significantly simplifies the development. It allows to create applications (orchestrations) in a usual stateful manner, but when they run they have the advantages of stateless programs. As we all know, with 3-tier architectures, the main advantage of stateless components (data access components) is scalability. Their disadvantage is the need for a complete development and design discipline that needs to be enforced. With BizTalk you don’t have to do that, in fact, you can write a single application (orchestration) that spans several HTTP submissions from different sessions and different people – BizTalk infrastructure transparently takes care of the state.
What is BizTalk Server?
BizTalk Server is one another member in Microsoft Enterprise Server Family!
BizTalk Server focuses on the e-business market, promoting the ease of data exchange between external entities, integration of enterprise applications, and the automation of business processes.
BizTalk Server serves five key processes:
- document transport and routing
- data transformation
- application integration
- process automation
- scalability and manageability services.
We will explore each processes in detail on coming posts..
Each process is achieved through receive functions, channels, ports, schedules, and tools.
BizTalk can be utilized to orchestrate [organize] business rules, translate/transform a different data formats, and provides messaging and routing capabilities. BizTalk Server’s foundation is XML-based.
Many enterprise world wide prefer Microsoft BizTalk Server for message routing, transformation and orchestration of business rules for a E-Commerce (B2B). In the J2EE end-to-end application space, Websphere Business Integration Message Broker is used for the same functions.
BizTalk Server is currently used in a number of B2B E-Commerce applications for enterprises like Insurance, Banking and Mutual Funds.
We will see more on What is new in BizTalk 2004 and various features available in BizTalk Server for developers in following post.