Search Results

Search found 8692 results on 348 pages for 'patterns and practices'.

Page 20/348 | < Previous Page | 16 17 18 19 20 21 22 23 24 25 26 27  | Next Page >

• How to make 2 incompatible types, but with the same members, interchangeable?

  - by Quigrim

  Yesterday 2 of the guys on our team came to me with an uncommon problem. We are using a third-party component in one of our winforms applications. All the code has already been written against it. They then wanted to incorporate another third-party component, by the same vender, into our application. To their delight they found that the second component had the exact same public members as the first. But to their dismay, the 2 components have completely separate inheritance hierarchies, and implement no common interfaces. Makes you wonder... Well, makes me wonder. An example of the problem: public class ThirdPartyClass1 { public string Name { get { return "ThirdPartyClass1"; } } public void DoThirdPartyStuff () { Console.WriteLine ("ThirdPartyClass1 is doing its thing."); } } public class ThirdPartyClass2 { public string Name { get { return "ThirdPartyClass2"; } } public void DoThirdPartyStuff () { Console.WriteLine ("ThirdPartyClass2 is doing its thing."); } } Gladly they felt copying and pasting the code they wrote for the first component was not the correct answer. So they were thinking of assigning the component instant into an object reference and then modifying the code to do conditional casts after checking what type it was. But that is arguably even uglier than the copy and paste approach. So they then asked me if I can write some reflection code to access the properties and call the methods off the two different object types since we know what they are, and they are exactly the same. But my first thought was that there goes the elegance. I figure there has to be a better, graceful solution to this problem.

  Read the article

• Is there a case for parameterising using Abstract classes rather than Interfaces?

  - by Chris

  I'm currently developing a component based API that is heavily stateful. The top level components implement around a dozen interfaces each. The stock top-level components therefore sit ontop of a stack of Abstract implementations which in turn contain multiple mixin implementations and implement multiple mixin interfaces. So far, so good (I hope). The problem is that the base functionality is extremely complex to implement (1,000s of lines in 5 layers of base classes) and therefore I do not wish for component writers to implement the interfaces themselves but rather to extend my base classes (where all the boiler plate code is already written). If the API therefore accepts interfaces rather than references to the Abstract implementation that I wish for component writers to extends, then I have a risk that the implementer will not perform the validation that is both required and assumed by other areas of code. Therefore, my question is, is it sometimes valid to paramerise API methods using an abstract implementation reference rather than a reference to the interface(s) that it implements? Do you have an example of a well-designed API that uses this technique or am I trying to talk myself into bad-practice?

  Read the article

• How should nested components interact with model in a GUI application?

  - by fig-gnuton

  Broad design/architecture question. If you have nested components in a GUI, what's the most common way for those components to interact with data? For example, let's say a component receives a click on one of its buttons to save data. Should the save request be delegated up that component's ancestors, with the uppermost ancestor ultimately passing the request to a controller? Or are models/datastores in a GUI application typically singletons, so that a component at any level of a hierarchy can directly get/set data? Or is a controller injected as a dependency down the hierarchy of components, so that any given component is only one intermediary away from the datastore/model?

  Read the article

• How to handle request/response propagation up and down a widget hierarchy in a GUI app?

  - by fig-gnuton

  Given a GUI application where widgets can be composed of other widgets: If the user triggers an event resulting in a lower level widget needing data from a model, what's the cleanest way to be able to send that request to a controller (or the datastore itself)? And subsequently get the response back to that widget? Presumably one wouldn't want the controller or datastore to be a singleton directly available to all levels of widgets, or is this an acceptable use of singleton? Or should a top level controller be injected as a dependency through a widget hierarchy, as far down as the lowest level widget that might need that controller? Or a different approach entirely?

  Read the article

• BlackBerry - Multiple Screens or Single Screen with Content Manager?

  - by Max Gontar

  Hi! I've seen projects which use many screens each one for different layout and functionality. I've seen projects with only one screen (like wizard workflow) where content is changed on user interaction (and this seems to be logical to use single screen in wizards). But also I've seen projects (apps like game or messenger or phone settings utility) which use single screen for different functionalities. I can see such advantages of having single screen in app: keep same decoration design and menu or toolbar (which may be also achieved with inheritance) keep single screen in ui stack (which may be achieved by pop/push screen) easy to handle data over application Can you tell other advantages/disadvantages of single screen app? When its better to use this approach? Thank you!

  Read the article

• How to structure an application written in a functional language?

  - by fig-gnuton

  How is code commonly organized in FP applications? Along what lines do you separate files, modules, directories, etc.?

  Read the article

• How to Effectively Create Bullet Patterns

  - by SoulBeaver

  I'm currently creating a top-down shooter like Touhou. The most important factor of the game is that there are many diverse patterns and ways at which bullets are generated and shot at the player, see this video: http://www.youtube.com/watch?v=4Nb5Ohbt1Sg#start=0:60;end=9:53; At the moment, I'm using a class "Pattern" which has a series of steps on moving and shooting. However, I feel this method is quite laborous as I have to create a new Pattern for each attack and perhaps new Bullet classes that will implement a certain behavior. This question received a comment suggesting I should look into BulletML for easy creation and storage of bullets with a specific pattern. It looks decent, but it led me to wonder, what other solutions do you have that I should take into consideration? Update My current design is as follows: An example of an implemented pattern: My GigasPattern first executes a teleport which moves Alice to a certain point (X, Y) on the screen. After this is completed, the pattern starts using the Mover to move the sprite around (whereas teleporting has separate effects and animation). These are of no concern, really, as they are quite simple. The Shooter also creates various Attacks, which are classes again that the Shooter can use to create various patterns of bullets, much like the one in the question I posted. Once the Mover has reached it's destination, both it and the shooter stop and return to an inactive state. The pattern completes, is removed by the AI and a new one gets chosen.

  Read the article

• Why is C++ backward compatibility important / necessary?

  - by Giorgio

  As far as understand it is a well-established opinion within the C++ community that C is an obsolete language that was useful 20 years ago but cannot support many modern good programming practices, or even encourages bad practices; certain features that were typical of C++ (C with classes) during the nineties are also obsolete and considered bad practice in modern C++ (e.g., new and delete should be replaced by smart pointer primitives). In view of this, I often wonder why backward compatibility with C and obsolete C++ features is still considered important: to my knowledge there is no 100% compatibility, but most of C and C++ are contained in C++11 as a subset. Of course, there is a lot of legacy code and libraries (possibly containing templates) that are written using a previous standard of the language and which still need to be maintained or used in connection with new code. Nevertheless, maybe it would still be possible to drop obsolete C and C++ features (e.g. the mentioned new / delete) from a future C++ standard so that it is impossible to use them in new code. In this way, old and dangerous programming practices would be quickly banned from new code, and modern, better programming practices would be enforced by the compiler. Legacy code could still be maintained using separate compilation (having C alongside C++ source files is already a common practice). Developers would have to choose between one compiler supporting the old-style C++ that was common during the nineties and a compiler supporting the modern C++? style (the question mark indicates a future, hypothetical revision). Only mixing the two styles would be forbidden. Would this be a viable strategy for encouraging the adoption of modern C++ practices? Are there conceptual reasons or technical problems (e.g. compiling existing templates) that make such a change undesirable or even impossible? Has such a development been proposed in the C++ community. If there has been some extended discussion on the topic, is there any material on-line?

  Read the article

• JavaScript Class Patterns

  - by Liam McLennan

  To write object-oriented programs we need objects, and likely lots of them. JavaScript makes it easy to create objects: var liam = { name: "Liam", age: Number.MAX_VALUE }; But JavaScript does not provide an easy way to create similar objects. Most object-oriented languages include the idea of a class, which is a template for creating objects of the same type. From one class many similar objects can be instantiated. Many patterns have been proposed to address the absence of a class concept in JavaScript. This post will compare and contrast the most significant of them. Simple Constructor Functions Classes may be missing but JavaScript does support special constructor functions. By prefixing a call to a constructor function with the ‘new’ keyword we can tell the JavaScript runtime that we want the function to behave like a constructor and instantiate a new object containing the members defined by that function. Within a constructor function the ‘this’ keyword references the new object being created -  so a basic constructor function might be: function Person(name, age) { this.name = name; this.age = age; this.toString = function() { return this.name + " is " + age + " years old."; }; } var john = new Person("John Galt", 50); console.log(john.toString()); Note that by convention the name of a constructor function is always written in Pascal Case (the first letter of each word is capital). This is to distinguish between constructor functions and other functions. It is important that constructor functions be called with the ‘new’ keyword and that not constructor functions are not. There are two problems with the pattern constructor function pattern shown above: It makes inheritance difficult The toString() function is redefined for each new object created by the Person constructor. This is sub-optimal because the function should be shared between all of the instances of the Person type. Constructor Functions with a Prototype JavaScript functions have a special property called prototype. When an object is created by calling a JavaScript constructor all of the properties of the constructor’s prototype become available to the new object. In this way many Person objects can be created that can access the same prototype. An improved version of the above example can be written: function Person(name, age) { this.name = name; this.age = age; } Person.prototype = { toString: function() { return this.name + " is " + this.age + " years old."; } }; var john = new Person("John Galt", 50); console.log(john.toString()); In this version a single instance of the toString() function will now be shared between all Person objects. Private Members The short version is: there aren’t any. If a variable is defined, with the var keyword, within the constructor function then its scope is that function. Other functions defined within the constructor function will be able to access the private variable, but anything defined outside the constructor (such as functions on the prototype property) won’t have access to the private variable. Any variables defined on the constructor are automatically public. Some people solve this problem by prefixing properties with an underscore and then not calling those properties by convention. function Person(name, age) { this.name = name; this.age = age; } Person.prototype = { _getName: function() { return this.name; }, toString: function() { return this._getName() + " is " + this.age + " years old."; } }; var john = new Person("John Galt", 50); console.log(john.toString()); Note that the _getName() function is only private by convention – it is in fact a public function. Functional Object Construction Because of the weirdness involved in using constructor functions some JavaScript developers prefer to eschew them completely. They theorize that it is better to work with JavaScript’s functional nature than to try and force it to behave like a traditional class-oriented language. When using the functional approach objects are created by returning them from a factory function. An excellent side effect of this pattern is that variables defined with the factory function are accessible to the new object (due to closure) but are inaccessible from anywhere else. The Person example implemented using the functional object construction pattern is: var personFactory = function(name, age) { var privateVar = 7; return { toString: function() { return name + " is " + age * privateVar / privateVar + " years old."; } }; }; var john2 = personFactory("John Lennon", 40); console.log(john2.toString()); Note that the ‘new’ keyword is not used for this pattern, and that the toString() function has access to the name, age and privateVar variables because of closure. This pattern can be extended to provide inheritance and, unlike the constructor function pattern, it supports private variables. However, when working with JavaScript code bases you will find that the constructor function is more common – probably because it is a better approximation of mainstream class oriented languages like C# and Java. Inheritance Both of the above patterns can support inheritance but for now, favour composition over inheritance. Summary When JavaScript code exceeds simple browser automation object orientation can provide a powerful paradigm for controlling complexity. Both of the patterns presented in this article work – the choice is a matter of style. Only one question still remains; who is John Galt?

  Read the article

• JavaScript Class Patterns

  - by Liam McLennan

  To write object-oriented programs we need objects, and likely lots of them. JavaScript makes it easy to create objects: var liam = { name: "Liam", age: Number.MAX_VALUE }; But JavaScript does not provide an easy way to create similar objects. Most object-oriented languages include the idea of a class, which is a template for creating objects of the same type. From one class many similar objects can be instantiated. Many patterns have been proposed to address the absence of a class concept in JavaScript. This post will compare and contrast the most significant of them. Simple Constructor Functions Classes may be missing but JavaScript does support special constructor functions. By prefixing a call to a constructor function with the ‘new’ keyword we can tell the JavaScript runtime that we want the function to behave like a constructor and instantiate a new object containing the members defined by that function. Within a constructor function the ‘this’ keyword references the new object being created -  so a basic constructor function might be: function Person(name, age) { this.name = name; this.age = age; this.toString = function() { return this.name + " is " + age + " years old."; }; } var john = new Person("John Galt", 50); console.log(john.toString()); Note that by convention the name of a constructor function is always written in Pascal Case (the first letter of each word is capital). This is to distinguish between constructor functions and other functions. It is important that constructor functions be called with the ‘new’ keyword and that not constructor functions are not. There are two problems with the pattern constructor function pattern shown above: It makes inheritance difficult The toString() function is redefined for each new object created by the Person constructor. This is sub-optimal because the function should be shared between all of the instances of the Person type. Constructor Functions with a Prototype JavaScript functions have a special property called prototype. When an object is created by calling a JavaScript constructor all of the properties of the constructor’s prototype become available to the new object. In this way many Person objects can be created that can access the same prototype. An improved version of the above example can be written: function Person(name, age) { this.name = name; this.age = age; } Person.prototype = { toString: function() { return this.name + " is " + this.age + " years old."; } }; var john = new Person("John Galt", 50); console.log(john.toString()); In this version a single instance of the toString() function will now be shared between all Person objects. Private Members The short version is: there aren’t any. If a variable is defined, with the var keyword, within the constructor function then its scope is that function. Other functions defined within the constructor function will be able to access the private variable, but anything defined outside the constructor (such as functions on the prototype property) won’t have access to the private variable. Any variables defined on the constructor are automatically public. Some people solve this problem by prefixing properties with an underscore and then not calling those properties by convention. function Person(name, age) { this.name = name; this.age = age; } Person.prototype = { _getName: function() { return this.name; }, toString: function() { return this._getName() + " is " + this.age + " years old."; } }; var john = new Person("John Galt", 50); console.log(john.toString()); Note that the _getName() function is only private by convention – it is in fact a public function. Functional Object Construction Because of the weirdness involved in using constructor functions some JavaScript developers prefer to eschew them completely. They theorize that it is better to work with JavaScript’s functional nature than to try and force it to behave like a traditional class-oriented language. When using the functional approach objects are created by returning them from a factory function. An excellent side effect of this pattern is that variables defined with the factory function are accessible to the new object (due to closure) but are inaccessible from anywhere else. The Person example implemented using the functional object construction pattern is: var john = new Person("John Galt", 50); console.log(john.toString()); var personFactory = function(name, age) { var privateVar = 7; return { toString: function() { return name + " is " + age * privateVar / privateVar + " years old."; } }; }; var john2 = personFactory("John Lennon", 40); console.log(john2.toString()); Note that the ‘new’ keyword is not used for this pattern, and that the toString() function has access to the name, age and privateVar variables because of closure. This pattern can be extended to provide inheritance and, unlike the constructor function pattern, it supports private variables. However, when working with JavaScript code bases you will find that the constructor function is more common – probably because it is a better approximation of mainstream class oriented languages like C# and Java. Inheritance Both of the above patterns can support inheritance but for now, favour composition over inheritance. Summary When JavaScript code exceeds simple browser automation object orientation can provide a powerful paradigm for controlling complexity. Both of the patterns presented in this article work – the choice is a matter of style. Only one question still remains; who is John Galt?

  Read the article

• Which book should I pick to improve my program designs/design patterns?

  - by zxcvbnm

  I want to learn about design patterns and from what I've seen the most recommended ones are the Gang of Four's Design Patterns and Head First Design Patterns. There are also language specific books, but I never see them recommended. I suppose it ties you to whatever strengths/weaknesses are inherent to each language, so not a good idea to learn design patterns in general. The Gang of Four's book is kinda old, so I'm wondering if there isn't a better alternative out today? I've heard the Heard First one isn't quite as good. But I'm not sure why, so it's really hard to pick either one. I've see some answers on this very site recommending both, but if I can only read one, which should I pick? I've been coding for 3+ years, though I've never had a good class on this subject. Also, would a book like Code Complete help me with this? One more thing: how often are these techniques supposed to be useful? For example, this question has me wondering if this stuff is worth the trouble. And please, tell me more than just "read x". I'd like to know why you're suggesting x.

  Read the article

• Ruby Best Practices, de Gregory T Brown, critique par Idelways

  Idelways vous propose la critique du livre "Ruby Best Practices Increase Your Productivity - Write Better Code" [IMG]http://images-eu.amazon.com/images/P/0596523009.01.LZZZZZZZ.jpg[/IMG] Citation: Ruby Best Practices is for programmers who want to use Ruby the way Rubyists do. Written by the developer of the Ruby project Prawn (prawn.majesticseacreature.com), this concise book explains how to design beautiful APIs and domain-specific languages, w...

  Read the article

• Google I/O 2012 - Best Practices for Maps API Developers

  Google I/O 2012 - Best Practices for Maps API Developers Susannah Raub, Jez Fletcher The Google Maps API makes it easy to add simple maps to your applications, but we want to take you to the next level. In this session we reveal our recommended best practices for Maps API developers, including developer tools, testing, and API features that will save you time, avoid a headache or two, and delight your users. For all I/O 2012 sessions, go to developers.google.com From: GoogleDevelopers Views: 400 8 ratings Time: 48:52 More in Science & Technology

  Read the article

• Learn Best Practices at Oracle OpenWorld

  - by Oracle OpenWorld Blog Team

  By Joan JenkinsOracle Advanced Customer Support Services Knows BestLearn key best practices to maximize performance and availability from Oracle Advanced Customer Support Services. Plan to attend one or more of our sessions, with topics including Oracle Exadata best practices, Oracle E-Business Suite upgrades, Oracle GoldenGate, and Oracle Platinum Services. Or stop by the Support Stars Bar to ask questions and get more information. Find out more what you can learn from Oracle Advanced Customer Support Services at Oracle OpenWorld.

  Read the article

• Good practices for large scale development/delivery of software

  - by centic

  What practices do you apply when working with large teams on multiple versions of a software or multiple competing projects? What are best practices that can be used to still get the right things done first? Is there information available how big IT companies do development and management of some of their large projects, e.g. things like Oracle Database, WebSphere Application Server, Microsoft Windows, ....?

  Read the article

• Announcing a functional best practices White Paper for SIM and RMS integration

  - by Oracle Retail Documentation Team

  Oracle Retail has published a document on My Oracle Support (https://support.oracle.com) that provides you with guidance on how to adopt best practices that best facilitate the integration between the Oracle Retail Merchandising System (RMS) and the Oracle Retail Store Inventory Management System (SIM). Doc ID: 1424596.1This paper highlights some specific functional best practices when integrating Oracle Retail Merchandising System (RMS) and Oracle Retail Store Inventory Management (SIM). The list in this paper is not comprehensive. Topics include: Inventory adjustments Returns to vendor (RTV) Transfer shipping Receipts Receipt unit adjustments Stock order reconcoliation Stock counts Transformable items

  Read the article

• Windows Server 2008 R2: Introducing the Best Practices Analyzer for AD Domain Services

  Windows Server 2008 R2 includes a new Best Practices Analyzer for Active Directory Domain Services, which facilitates the implementation of best practices in your Active Directory Domain Services environment.

  Read the article

• Partner Webinar Series CRM/CX Best Practices - Each Friday - 10am PST

  - by Richard Lefebvre

  A CRM/CX Best Practices Webinar will be led each week by the Oracle CRM/CX Sales Consulting team and focus on Demo best practices and previews Lessons Learned from Sales Cycles Competitive & product/solution positioning information Product updates& progress Replays are available from the webinar's portal. Please see the agenda and webinar details here and join us to learn about a new CX topic each Friday at 10am PT.

  Read the article

• Web Site Design Best Practices

  There are several ways to develop web pages but the best thing is that it should be developed in such a way that it appeals and attract other persons. In the field of web page designing a lot of practices are there. Here in this article we target few of the best practices for making and developing good web pages.

  Read the article

• MSDN Magazine: Patterns for High Availability, Scalability, and Computing Power with Windows Azure

  In this article, Joshy Joseph, a principal architect with Microsoft Services Managed Solutions Group, examines the typical cloud platform architecture and some common architectural patterns, along with their implementation on the Windows Azure offering from Microsoft....Did you know that DotNetSlackers also publishes .net articles written by top known .net Authors? We already have over 80 articles in several categories including Silverlight. Take a look: here.

  Read the article

• Web Site Design Best Practices

  There are several ways to develop web pages but the best thing is that it should be developed in such a way that it appeals and attract other persons. In the field of web page designing a lot of practices are there. Here in this article we target few of the best practices for making and developing good web pages.

  Read the article

• Important Tips to Increase Page Rank and Effective Search Engine Optimization Practices

  To increase page rank, there are important things to consider, especially if you want to learn effective search engine optimization practices. Through these practices, you can make your website popular in the Internet world.

  Read the article

• Integration Patterns with Azure Service Bus Relay, Part 3: Anonymous partial-trust consumer

  - by Elton Stoneman

  This is the third in the IPASBR series, see also: Integration Patterns with Azure Service Bus Relay, Part 1: Exposing the on-premise service Integration Patterns with Azure Service Bus Relay, Part 2: Anonymous full-trust .NET consumer As the patterns get further from the simple .NET full-trust consumer, all that changes is the communication protocol and the authentication mechanism. In Part 3 the scenario is that we still have a secure .NET environment consuming our service, so we can store shared keys securely, but the runtime environment is locked down so we can't use Microsoft.ServiceBus to get the nice WCF relay bindings. To support this we will expose a RESTful endpoint through the Azure Service Bus, and require the consumer to send a security token with each HTTP service request. Pattern applicability This is a good fit for scenarios where: the runtime environment is secure enough to keep shared secrets the consumer can execute custom code, including building HTTP requests with custom headers the consumer cannot use the Azure SDK assemblies the service may need to know who is consuming it the service does not need to know who the end-user is Note there isn't actually a .NET requirement here. By exposing the service in a REST endpoint, anything that can talk HTTP can be a consumer. We'll authenticate through ACS which also gives us REST endpoints, so the service is still accessed securely. Our real-world example would be a hosted cloud app, where we we have enough room in the app's customisation to keep the shared secret somewhere safe and to hook in some HTTP calls. We will be flowing an identity through to the on-premise service now, but it will be the service identity given to the consuming app - the end user's identity isn't flown through yet. In this post, we’ll consume the service from Part 1 in ASP.NET using the WebHttpRelayBinding. The code for Part 3 (+ Part 1) is on GitHub here: IPASBR Part 3. Authenticating and authorizing with ACS We'll follow the previous examples and add a new service identity for the namespace in ACS, so we can separate permissions for different consumers (see walkthrough in Part 1). I've named the identity partialTrustConsumer. We’ll be authenticating against ACS with an explicit HTTP call, so we need a password credential rather than a symmetric key – for a nice secure option, generate a symmetric key, copy to the clipboard, then change type to password and paste in the key: We then need to do the same as in Part 2 , add a rule to map the incoming identity claim to an outgoing authorization claim that allows the identity to send messages to Service Bus: Issuer: Access Control Service Input claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier Input claim value: partialTrustConsumer Output claim type: net.windows.servicebus.action Output claim value: Send As with Part 2, this sets up a service identity which can send messages into Service Bus, but cannot register itself as a listener, or manage the namespace. RESTfully exposing the on-premise service through Azure Service Bus Relay The part 3 sample code is ready to go, just put your Azure details into Solution Items\AzureConnectionDetails.xml and “Run Custom Tool” on the .tt files.  But to do it yourself is very simple. We already have a WebGet attribute in the service for locally making REST calls, so we are just going to add a new endpoint which uses the WebHttpRelayBinding to relay that service through Azure. It's as easy as adding this endpoint to Web.config for the service:         <endpoint address="https://sixeyed-ipasbr.servicebus.windows.net/rest"                   binding="webHttpRelayBinding"                    contract="Sixeyed.Ipasbr.Services.IFormatService"                   behaviorConfiguration="SharedSecret">         </endpoint> - and adding the webHttp attribute in your endpoint behavior:           <behavior name="SharedSecret">             <webHttp/>             <transportClientEndpointBehavior credentialType="SharedSecret">               <clientCredentials>                 <sharedSecret issuerName="serviceProvider"                               issuerSecret="gl0xaVmlebKKJUAnpripKhr8YnLf9Neaf6LR53N8uGs="/>               </clientCredentials>             </transportClientEndpointBehavior>           </behavior> Where's my WSDL? The metadata story for REST is a bit less automated. In our local webHttp endpoint we've enabled WCF's built-in help, so if you navigate to: http://localhost/Sixeyed.Ipasbr.Services/FormatService.svc/rest/help - you'll see the uri format for making a GET request to the service. The format is the same over Azure, so this is where you'll be connecting: https://[your-namespace].servicebus.windows.net/rest/reverse?string=abc123 Build the service with the new endpoint, open that in a browser and you'll get an XML version of an HTTP status code - a 401 with an error message stating that you haven’t provided an authorization header: <?xml version="1.0"?><Error><Code>401</Code><Detail>MissingToken: The request contains no authorization header..TrackingId:4cb53408-646b-4163-87b9-bc2b20cdfb75_5,TimeStamp:10/3/2012 8:34:07 PM</Detail></Error> By default, the setup of your Service Bus endpoint as a relying party in ACS expects a Simple Web Token to be presented with each service request, and in the browser we're not passing one, so we can't access the service. Note that this request doesn't get anywhere near your on-premise service, Service Bus only relays requests once they've got the necessary approval from ACS. Why didn't the consumer need to get ACS authorization in Part 2? It did, but it was all done behind the scenes in the NetTcpRelayBinding. By specifying our Shared Secret credentials in the consumer, the service call is preceded by a check on ACS to see that the identity provided is a) valid, and b) allowed access to our Service Bus endpoint. By making manual HTTP requests, we need to take care of that ACS check ourselves now. We do that with a simple WebClient call to the ACS endpoint of our service; passing the shared secret credentials, we will get back an SWT: var values = new System.Collections.Specialized.NameValueCollection(); values.Add("wrap_name", "partialTrustConsumer"); //service identity name values.Add("wrap_password", "suCei7AzdXY9toVH+S47C4TVyXO/UUFzu0zZiSCp64Y="); //service identity password values.Add("wrap_scope", "http://sixeyed-ipasbr.servicebus.windows.net/"); //this is the realm of the RP in ACS var acsClient = new WebClient(); var responseBytes = acsClient.UploadValues("https://sixeyed-ipasbr-sb.accesscontrol.windows.net/WRAPv0.9/", "POST", values); rawToken = System.Text.Encoding.UTF8.GetString(responseBytes); With a little manipulation, we then attach the SWT to subsequent REST calls in the authorization header; the token contains the Send claim returned from ACS, so we will be authorized to send messages into Service Bus. Running the sample Navigate to http://localhost:2028/Sixeyed.Ipasbr.WebHttpClient/Default.cshtml, enter a string and hit Go! - your string will be reversed by your on-premise service, routed through Azure: Using shared secret client credentials in this way means ACS is the identity provider for your service, and the claim which allows Send access to Service Bus is consumed by Service Bus. None of the authentication details make it through to your service, so your service is not aware who the consumer is (MSDN calls this "anonymous authentication").

  Read the article

• Google I/O 2012 - Go Concurrency Patterns

  Google I/O 2012 - Go Concurrency Patterns Rob Pike Concurrency is the key to designing high performance network services. Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution. In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code. For all I/O 2012 sessions, go to developers.google.com From: GoogleDevelopers Views: 169 2 ratings Time: 51:27 More in Science & Technology

  Read the article

• Are there any good videos out there on Java Design Patterns?

  - by Becky Reamy

  My team would like to spend some time at lunch learning design patterns. Previously, we watched some videos on Javascript which we found very useful as a way to start discussions. We would like to do the same thing with design patterns so that we don't have to spend a lot of time (outside of work) researching individual patterns in order to give a presentation. I did a little searching and came up fairly empty handed. Any help would be appreciated. It doesn't even have to be a video, even something that we can listen to (maybe a book on tape even).

  Read the article

< Previous Page | 16 17 18 19 20 21 22 23 24 25 26 27  | Next Page >