Visual Web Developer 2005 Express Edition Beta

[DevGuy 0]

Hy Guy.. i just download beta Visual Web Developer 2005. Cool dude u can check it at http://lab.msdn.microsoft.com/express/vwd/

and this is beta for whidbey.

and u need .net framework 2.0

actually i think u need msdn subcriber to getthis tool.

now Visual studio 2005 Whidbey is Beta 1. i just finish download and try toplaying around..

so if u need this u can ask me or buy dvd and i can burn it for u ..

[DevGuy 0]

one more SQL Server 2005 Express Edition - technical Previeew.. it's free

go to this link http://lab.msdn.microsoft.com/express/sql/

the cool thing bout this product

freee

1.Integrated common language runtime (CLR) support. Stored procedures and 2.functions can be written using your favorite programming language.

Native XML support.

3.XCopy support for moving databases from one location to another.

4.Robust and reliable installation using either graphical user interface (GUI) or silent modes.

5.Automated servicing and patching.

6.Deep integration with Visual Studio to provide access to rich data controls like the DataGridView, DataNavigator, and DataConnector.

7.Support for databases up to 4GB.

8.Support for disconnected systems with SQL Server Service Broker and Replication.

9.SQL Server Express Manager, a new, easy-to-use database management and query analysis tool (available August 2004).

10.Easier deployment via Visual Studio ClickOnce (available in Beta 3).

[DevGuy 0]

anyway you guy can download this express edition.. its free. use this link

http://lab.msdn.microsoft.com/express/

anyway the product is

Visual Basic 2005 Express

Visual C++ 2005 Express

Visual C# 2005 Express

Visual J# 2005 Express

Visual Web Dev 2005 Express

SQL Server 2005 Express

but memang ada limitation ..

at least we can develop for future..

[aRmsTer 0]

devguy.. do u hv any WSE 2.0 documentation? bukan yg detailed punye..i mean just a slight preview n pros n cons compared to de ol' one.. kinda interested bhgn. boleh send/receive thru TCP(kalu xsilap la)

anyway.. whidbey roxXXsss!!! cannot imagine mcmmane rupa orcas plak pas nih

[DevGuy 0]

let mw check first.tapi wse 3.0 ada aa.nevermind i check for u.

[DevGuy 0]

opp sorry aku ingatkan SOAP Toolkit solly aa.wse documentation 2.0 aku checkkat this web blog..

http://cyberforge.com/weblog/aniltj/archiv.../06/23/593.aspx

anyway this is good resource.. sorry beb. anywya memang ada leh send/receive tcp sama macam SOAP Toolkit... but i never try. tapi kalau guna SOAP i try before..

oklahh

[DevGuy 0]

ni features and enhancement

Policy

WSE version 2.0 enables developers to use configuration files to specify requirements for receiving and sending messages. Previously, an application receiving a SOAP message had to contain code to verify message-receiving requirements, such as whether the SOAP message was digitally signed or encrypted. Likewise, the developer of the application sending the SOAP message had to know the receiver's message requirements and add code to the sending application. Now those requirements, known as policy assertions, can be expressed in a configuration file. When policy assertions are configured, WSE runtime checks incoming or outgoing SOAP messages to determine whether they comply with the policy assertions; when they do not, WSE runtime returns a SOAP fault. WSE has a set of predefined policy assertions, such as the requirement that the body of the SOAP message be signed with an X.509 certificate. In addition, the policy system can be extended to include custom policy assertions.

WS-Trust and Security Context Tokens

WSE's support of the WS-Trust and WS-SecureConversation specifications provides the capability to programmatically request a security token using a SOAP message, and that token can be used for a series of SOAP messages between a SOAP message sender and a target Web service. WSE allows you to build a security token service or configure one that issues security context tokens. When configured to issue security context tokens, a SOAP message sender can use the token to sign and/or encrypt a series of SOAP messages, known as a conversation, between a SOAP message sender and the target Web service.

Kerberos Security Tokens

WSE supports the use of security tokens based on Kerberos tickets. Kerberos tickets can be used to digitally sign and encrypt SOAP messages, along with authorizing access to a Web service based on a Kerberos security token.

Role-based Security Using Security Tokens

WSE supports role-based authorization for SOAP messages by constructing a principal from a security token in the SOAP message, such as the one used to digitally sign the SOAP message. Because there may be multiple security tokens in a SOAP message, WSE allows the application to configure which security token is used for authentication and authorization. When this security token is a user name and password or Kerberos ticket, the contents of the security token are used to authenticate against a Windows account. If the credentials are authenticated, a Windows principal is created and assigned to the Principal property of the security token used to sign the SOAP message. Using that Principal property, code in a Web service method can decide whether a given role is authorized to execute all or portions of the Web service method. Alternatively, role-based security can be declaratively set using policy.

Signing and Encrypting Security Tokens

When a security token is added to a SOAP message, it is added to the SOAP message in the form of an XML element in the WS-Security SOAP header. That XML element can now be digitally signed or encrypted. This can be very useful when the security token is a UsernameToken, which is based upon a user name and password — especially if the password is sent in plaintext. And when you use role-based security with a UsernameToken, the password must be sent in plaintext. Therefore, encrypting the UsernameToken containing a plaintext password can make it more difficult for an intermediary to steal a user's password.

SOAP Messaging

With SOAP messaging, WSE supports a flexible and lightweight mechanism for sending and receiving SOAP messages. This mechanism allows applications to switch between the TCP and HTTP transport protocols relatively easily. When the TCP transport protocol is used, the SOAP messages can be sent and received without using a Web server. A Web server, which only handles HTTP requests, operates based upon the HTTP specification requirement that every HTTP request receive an HTTP response. This request/response model is not always necessary when sending messages; a SOAP message sender might need to send several messages and may not need or expect any return SOAP messages. The SOAP messaging in WSE accommodates this type of messaging, while still allowing developers to take advantage of the other features of WSE, such as digital signature and encryption support.

Visual Basic .NET Sample Code

The QuickStarts and sample code throughout the documentation are provided in both Visual Basic and C#.

XML Security Token Support

WSE 2.0 now provides support for XML security tokens, such as XrML and SAML security tokens. To use XML security tokens, you must create and configure a custom XML security token.

Version Compatibility

Web Services Enhancements attempts to maintain a degree of backward compatibility between versions. However, changes to WSE that help improve security, correctness, or functionality require rewriting portions of code when upgrading to the latest version of WSE.

The following is a list of areas containing breaking changes between WSE 1.0 and WSE 2.0

SOAP Messages Do Not Interoperate Between WSE 1.0 and 2.0

Messages sent between applications running WSE 1.0 and 2.0 generate a SOAP fault. A SOAP fault is generated because WSE 1.0 and 2.0 implement different Web services architecture specifications. Specifically, WSE 1.0 implements the WS-Routing and WS-Security specifications, whereas WSE 2.0 implements the WS-Addressing and OASIS WS-Security specifications.

Running Multiple Versions of WSE Simultaneously

Multiple versions of WSE can be installed and run on the same machine simultaneously. However, a Web service running on that machine can use only one of the versions. A single Web service client can interact with Web services running WSE 1.0 and with Web services running WSE 2.0. However, the client must use fully qualified names in the code to specify which version of WSE is being used. For example, the client could not specify SoapContext but would have to specify either Microsoft.Web.Services.SoapContext or Microsoft.Web.Services2.SoapContext.

Getting a SoapContext from Within a Web Service

To get a SoapContext from within a Web service in WSE 2.0, use the static (Shared in Visual Basic) Current property of the RequestSoapContext or ResponseSoapContext class for a SOAP request or SOAP response, respectively. For WSE version 1.0, the static (Shared) RequestSoapContext and ResponseSoapContext methods of the HttpSoapContext are used to get a SoapContext from within a Web service.

IPasswordProvider Interface Is Obsolete

You no longer have to build a class that implements the IPasswordProvider interface and configure that class when a Windows user account is used with a UsernameToken. WSE now supports Windows authentication for a UsernameToken. When Windows accounts are sent in the UsernameToken, a class does not have to be built and configured. However, when a Windows user account is not used with a UsernameToken, a class deriving from the SecurityTokenManager class must be built and configured.

DecryptionKeyProvider Class Is Obsolete

Shared-secret encryption (also known as symmetric encryption) is now done using a security token based on a symmetric key instead of just the symmetric key alone. Security context tokens, which are issued from security token services, are based on a symmetric key that can be used to encrypt SOAP messages.

Using Custom Binary Security Tokens in WSE 2.0

Custom binary security tokens built using WSE 1.0 require modification to be used in WSE 2.0.

[DevGuy 0]

anyway WSE dah kuar baru beta 1 for asp.net 2.0. check kat this web site

http://msdn.microsoft.com/webservices/defa...ml/wsnetfx2.asp

ada features and pro and const..

anyway aku ada document dlm word. tapi cam ner nak hantar..

tak per laaa. i think from web pages can advice u.

[DevGuy 0]

this good article

http://msdn.microsoft.com/webservices/buil...program_topic10

[aRmsTer 0]

thanx for the links n info.. byk gile sampai xtau nak start dr mana.. bout dat word docs... i'll PM u my email add..

let mw check first.tapi wse 3.0 ada aa.nevermind i check for u.

wse 3.0 ?? dgr citer ada ws-rm ngn soap mtom.. betul ke?

[DevGuy 0]

still beta.but WSE ni include sekali UDDI,SOAP and XML.. so programmer need to choose which one when they want to create or build the system.depend on features.sbb every one ada features sendiri. i use SOAP for design call Center. oklahh gakk.easy sebab create dlm class