|
|
Browse by Tags
All Tags » BizTalk Services (RSS)
Sorry, but there are no more tags available to filter with.
-
We’re thrilled to announce that the BizTalk Services “R12” Community Technology Preview (CTP) is now available for general use. “BizTalk Services” is the code-name for a platform-in-the-cloud offering from Microsoft. Currently in active development, BizTalk Services provides Messaging, Workflow, and Identity functionality to enable disparate applications to connect quickly and easily. Combined together in an integrated offering, these capabilities deliver a Service Bus architectural pattern that is immediately usable by applications that need to connect across the Internet. Many enterprises employ the ‘Enterprise Service Bus’ pattern to interconnect disparate systems within an organizational domain. Built on Microsoft platform technology, an ESB might include building blocks such as Windows Server, Active Directory, BizTalk Server, as well as the Windows Communication Foundation and Windows Workflow Foundation technologies included in the .NET Framework. “BizTalk Services” extends the concept of an ESB to truly exploit the Internet, for instance by exposing individual service endpoints in a secure fashion or by selectively federating elements of distinct identity systems to facilitate cross-company collaboration. For ISVs and Solution Providers creating specialized business solutions that enable collaboration and information exchange across increasingly mobile and distributed work-forces, “BizTalk Services” provides the cloud-based platform building blocks to create sophisticated (Internet-) Service Bus solutions with broad reach that could otherwise only be realized by operating dedicated Data Centers of significant complexity – which is often out of reach for both, ISVs and their customers. Major Changes With the release of BizTalk Services “R12”, developers must update all clients and SDK installations to the new release. New in R12 - Workflow The most exciting new capability we’ve added in the “R12” CTP is Workflow. These new cloud-based Workflow capabilities enable ‘service orchestration’ from the cloud. This specialized cloud-based, or hosted, Windows Workflow Foundation runtime can orchestrate services that connect to systems in your enterprise, or to systems running anywhere on the Internet via Web services messages. This new power and capability will enable an entirely new set of application scenarios, and we’re very excited to see what people will do with it. In the SDK you will find samples showing how to create and control Workflow instances hosted on the BizTalk Services cloud, including a sample Workflow implementation that monitors the availability of a website and fires multicast events into the service bus indicating the state. New in R12 - Identity For R12, the BizTalk Services Identity Service has been expanded and enhanced to enable more flexibility for scenarios demanded by our customers. R12 introduces a new approach for creating, viewing, and managing access control rules. This approach relies on a few key principles outlined Read More...
|
-
The BizTalk Services CTP will be switched from the "R11" to the "R12" release starting in about 30 minutes and we expect to have a 2 hour time window (1400h-1600h PT/2300h-0100h UTC) where existing service accounts are being rolled over to the new release. We're expecting to be done with the migration by 1600h. Once the migration is done we'll give you an update on what's new in R12. Read More...
|
-
Heads up: If things go as planned, the BizTalk Services cloud will be unavailable for a few hours during the day on Tuesday 7/15 (U.S. Pacific Time) since we're doing an update to the services and to the SDK. I will post an update with the exact time window some time on Monday. Once we're back up and have verified that everything is working as intended we'll let you know about it and tell you what's new. Applications built on the R11 release (the release currently running in the data center) will have to be recompiled (and in some instances slightly changed) against the new R12 release's assemblies to run with R12. We've done some protocol adjustments in R12 that make this necessary - mind that we're still in "experimentation-only preview" mode here. Theory suggests that some compiled R11 applications will work against the R12 cloud, but it's not a combination we're explicitly testing as of yet. We obviously have that sort of backwards compatibility on the radar (it's SOA, should be easy, right?) but it'll likely take us a couple more revisions before we're happy enough with the baseline protocols. Read More...
|
-
I highly recommend reading Vittorio's most excellent and illuminating blog entry for how to use the new features we've added to BizTalk Identity Services for allowing you to use 3rd Party Managed Cards. Read More...
|
-
A flock of pigs has been doing aerobatics high up over Microsoft Campus in Redmond in the past three weeks. Neither City of Redmond nor Microsoft spokespeople returned calls requesting comments in time for this article. An Microsoft worker who requested anonymity and has seen the pigs flying overhead commented that "they are as good as the Blue Angels at Seafair, just funnier" and "they seem to circle over building 42 a lot, but I wouldn't know why". In related news ... We wrapped up the BizTalk Services "R11" CTP this last Thursday and put the latest SDK release up on http://labs.biztalk.net/ . As you may or may not know, "BizTalk Services" is the codename for Microsoft's cloud-based Identity and Connectivity services - with a significant set of further services in the pipeline. The R11 release is a major milestone for the data center side of BizTalk Services, but we've also added several new client-facing features, especially on the Identity services. You can now authenticate using a certificate in addition to username and CardSpace authentication, we have enabled support for 3rd party managed CardSpace cards, and there is extended support for claims based authorization. Now the surprising bit: Only about an hour before we locked down the SDK on Thursday, we checked a sample into the samples tree that has a rather unusual set of prerequisites for something coming out of Microsoft: Runtime: Java EE 5 on Sun Glassfish v2 + Sun WSIT/Metro (JAX-WS extensions), Tool: Netbeans 6.0 IDE . The sample shows how to use the BizTalk Services Identity Security Token Service (STS) to secure the communication between a Java client and a Java service providing federated authentication and claims-based authorization. The sample, which you can find in ./Samples/OtherPlatforms/StandaloneAccessControl/JavaEE5 once you installed the SDK, is a pure Java sample not requiring any of our bits on either the service or client side. The interaction with our services is purely happening on the wire. If you are a "Javahead", it might seem odd that we're shipping this sample inside a Windows-only MSI installer and I will agree that that's odd. It's simply a function of timing and the point in time when we knew that we could get it done (some more on that below). For the next BizTalk Services SDK release I expect there to be an additional .jar file for the Java samples. It's important to note that this isn't just a thing we did as a one-time thing and because we could. We have done a significant amount of work on the backend protocol implementations to start opening up a very broad set of scenarios on the BizTalk Services Connectivity services for platforms other than .NET. We already have a set of additional Java EE samples lined up for when we enable that functionality on the backend. However, since getting security and identity working is a prerequisite for making all other services work, that's where we started. There'll be more and there'll be more platform and language choice Read More...
|
-
Steve Maine explains what's in the newest revision of the BizTalk Services SDK, including quite a few (standalone-) surprises for WCF and WF developers. In case you haven't noticed, we've dropped a new and substantially expanded build of the SDK just a week after we published the first SDK. Stop. Don't leave yet. Before you say "What do I care about BizTalk?", you should know that while BizTalk has been more or less associated with the BizTalk Server 200x product line in the past few years, (Codename-) BizTalk Services is a complementary set of functionality that's not only interesting to BizTalk Server customers, but really to all .NET developers. Weird? Flip flopping? Confusing? No. The fact that BizTalk is not only BizTalk Server isn't really new. When BizTalk came out back in 2000 and I was very closely looking at what's going on (get it used for $2), the definition read like this in the press release : The BizTalk Initiative represents the collective set of investments that Microsoft is making to facilitate business process integration within and between organizations using Internet-standard protocols and formats. It includes the BizTalk Framework, the BizTalk.org community and business document library, as well as BizTalk Server 2000, a business process orchestration server and tools for developing, executing and managing distributed business processes. These investments are being made in conjunction with industry standards groups, technology and service providers, as well as key global organizations. While the envisioned schema exchange BizTalk.org fell flat since industry-wide message-level-schema standardization for "everything" more or less didn't happen in the way people initially expected, what came out of this initiative as a significant element was that the set of specifications then known as the BizTalk Framework 2.0 that acted as a foundation for quite a few of the WS-* specifications and the BizTalk Server product which evolved into a very successful and leading SOA/BPM suite that's soon seeing its next release, BizTalk Server 2006 R2 . Fast forward, read Steven Martin's blog entry where he writes: [...] We see BizTalk Services as a complement to "traditional" BizTalk Server uses on premise. As you need to coordinate SOA on a broader scale beyond the organization, we see the introduction of hosted services as one way to help support federation of business process, messaging, and identity across boundaries. Over time, we want to ensure that BizTalk Server customers will be able to easily use the cloud services in conjunction with their premise technology. [...] So all in all, a very sane way to think about BizTalk is that the software and services we publish under that name are providing functionality for messaging, process management and connectivity that go beyond the capability of the core .NET Framework. Read More...
|
-
I wrote a slightly Twitter-inspired, fun app over the weekend that's using the BizTalk Services Connectivity service and relay. In the spirit of Software+Services I'm going to give you half of it [for now] ;-) You must have the BizTalk Services SDK installed to run the sample. The server app, which I'm keeping to myself for the next few days as part of the experiment, is an extension (add-in) to Windows Live Messenger. The Messenger add-in monitors all chats with tweetiebot@hotmail.com and keeps circular buffer with the last 40 incoming messages. Using the client (which is in the attached archive), you can get a list of "Tweets" and add a new one (same as chatting) [ ServiceContract (Name = "TweetieBot" , Namespace = http://samples.vasters.com/2007/05/tweetiebot )] public interface ITweetieBot { [ OperationContract ] IList < Tweet > GetTweets( DateTime ? since); [ OperationContract ] void Tweet( string nickname, string text); } or you can subscribe to new tweets and get them as they arrive [ ServiceContract (Name = "TweetieEvents" , Namespace = http://samples.vasters.com/2007/05/tweetiebot )] public interface ITweetieEvents { [ OperationContract (IsOneWay= true )] void OnTweet( Tweet tweet); } The client application hooks up to the client (that lives right on my desktop machine) through the BizTalk Services ISB and the server fires events back through the ISB relay into the client as new tweets arrive. So when you run the attached client app, you'll find that it starts with a dump of the current log of the bot and then keeps spitting out events as they arrive. The client is actually pretty simple. The EventsClient is the subscriber for the pub/sub service (ConnectionMode.RelayMulticast) that writes out the received events to the console. The rest all happens in Main (parsing an validating the command line argument) and in Run . class Program { class EventsClient : ITweetieEvents { public void OnTweet( Tweet tweet) { Console .WriteLine( "[{0}] {1}:{2}" , tweet.Time, tweet.User, tweet.Text); } } static void Main( string [] args) { string usageMessage = "Usage: IMBotClient <messenger-email-address>" ; if (args.Length == 0) { Console .WriteLine(usageMessage); } else { if (! Regex .IsMatch(args[0], @"^([\w\-\.]+)@((\[([0-9]{1,3}\.){3}[0-9]{1,3}\])|(([\w\-]+\.)+)([a-zA-Z]{2,4}))$" )) { Console .WriteLine(usageMessage); Console .WriteLine( "'{0}' is not a valid email address" ); } else { Run(args[0]); } } } private static void Run( string emailAddress) { EndpointAddress serviceAddress = new EndpointAddress ( String .Format( String .Format( "sb://{0}/services/tweetiebot/{1}/service" , RelayBinding .DefaultRelayHostName, Uri .EscapeDataString(emailAddress)))); EndpointAddress eventsAddress = new EndpointAddress ( String .Format( String .Format( "sb://{0}/services/tweetiebot/{1}/events" , RelayBinding .DefaultRelayHostName, Uri .EscapeDataString(emailAddress)))); The URI scheme for services that hook into the ISB is "sb:" and the default address Read More...
|
|
|
|