EBS - Checklist / Capabilities

http://www.ebizq.net/topics/esb/features/6132.html

MSDN: The Internet Service Bus

The Internet Service Bus

Summary: Web applications are an extremely common application model, and they will become increasingly dominant. Almost all applications in medium to large businesses offer a Web user interface. In this article, we will use the term enterprise to encompass medium to large enterprises, and the software vendor and integrator companies. Desktop and client/server applications are increasingly using the browser for the UI engine and making calls to data and services through Web protocols.

Software, application models and the Web itself are undergoing a revolutionary transformation. This transformation will have as large an effect on computing as the client/server model or the initial emergence of the Web itself. The Web will evolve from connecting users to applications provided by sites into a model in which:

· The application executes “in the Web.”

· End-users develop their own applications for accessing the Web, transforming it into an end-user developed workspace for access to Web services.

This paper focuses on a small number of elements of the transformation. Other papers will expand the vision.

Several technologies and trends provide the impetus for the revolutionary transformation described above. Some examples are: multi-core processors; virtualization; application scenarios that federate many devices, such as mobile phones and tablets; Service-Oriented Architecture (SOA) and Web services; Web 2.0; and Software as a Service (SaaS).

We will discuss the effect of some of these trends, but our primary focus is SOA, Web 2.0, and Software as a Service (SaaS). These concepts and their relationships are not well understood. The technologies often appear to conflict. The paper describes the elements of a high-level reference architecture that brings the concepts together into a consistent whole.

Many of the preceding technology trends have broad acceptance and awareness. This paper discusses a third trend that is more controversial: ubiquitous programming ability. A large percentage of high school and college graduates have basic programming skills when entering the workforce; many students have developed simple PHP or Visual Basic applications and built Web sites. The professionals’ primary job responsibilities may not include programming, but in many cases professionals will do simple programming if it makes them more productive. They may also develop simple applications because it is “cool.” We will use the terms end-user programming for this concept.

End-user programming is an extreme case of opportunistic development, which occurs in departments and Lines of Business (LOBs) in enterprises. LOBs and teams often build simple, “quick and dirty” SharePoint or PHP applications that solve an immediate business problem by extending packaged applications or enterprise-wide core applications.

Opportunistic development contrasts with systematic development. Systematic development is model-driven, replete with requirements gathering, use cases and stakeholder interviews, an application development life cycle that includes quality and assurance, and so forth. Systematic development is the predominant model of the enterprise development team (“the CIO team”). Many packaged application developers (independent software vendors or ISVs) and Systems Integrators (SIs) also produce systematic solutions.

There is a tension in enterprises between opportunistic development and systematic development. This tension will increase if end-user programming becomes common. End users will not be content to wait for the systematic development teams to develop or modify solutions. The reference architecture we describe provides an approach for reconciling the extremes of opportunistic and systematic development.

We use a scenario to illustrate the reference architecture. A core element that emerges and underpins the architecture is an Internet Service Bus (ISB). The reference architecture encompasses many elements, however, this paper provides detail only for the ISB. Other papers will describe other elements.



http://msdn.microsoft.com/en-us/library/bb906065.aspx

Enterprise Service Bus - per wikipedia

ESB architectureUse of the word “bus” stems from the physical bus that carries bits between devices in a computer. The ESB serves an analogous function at a higher level of abstraction. In an enterprise architecture making use of an ESB, an application will communicate via the bus, which acts as a message broker between applications. Such an approach has the primary advantage of reducing the number of point-to-point connections required to allow applications to communicate. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact to a particular application, the process of adapting a system to changes in one of its components becomes easier.

[edit] ESB as softwareIn such a complex architecture, the ESB represents the piece of software that lies between the business applications and enables communication among them. Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the ESB. To achieve this objective, the ESB must encapsulate the functionality offered by its component applications in a meaningful way. This typically occurs through the use of an enterprise message model. The message model defines a standard set of messages that the ESB will both transmit and receive. When the ESB receives a message, it routes the message to the appropriate application. Often, because that application evolved without the same message-model, the ESB will have to transform the message into a format that the application can interpret. A software “adapter” fulfills the task of effecting these transformations (analogously to a physical adapter). Commentators[who?] disagree whether or not these adapters should be considered part of the ESB.

ESBs rely on accurately connecting the enterprise message model and the functionality offered by applications. If the message model does not completely encapsulate the applications’ functionality, then other applications that desire that functionality may have to bypass the bus, and invoke the mismatched applications directly. Doing so violates all of the principles outlined above, and negates many of the advantages of using an ESB.


Key benefitsFaster and cheaper accommodation of existing systems.
Increased flexibility; easier to change as requirements change.
Standards-based
Scales from point-solutions to enterprise-wide deployment (distributed bus).
Predefined ready-for-use service types.
More configuration rather than integration coding.
No central rules-engine, no central broker.
Incremental patching with zero down-time; enterprise becomes "refactorable".
[edit] Key disadvantagesUsually requires an Enterprise Message Model, resulting in additional management overhead. Potential difficulties integrating many disparate systems to collaborate via message standards.
Requires ongoing management of message versions to ensure the intended benefit of loose coupling. Incorrect, insufficient, or incomplete management of message versions can result in tight coupling instead of the intended loose coupling.
It normally requires more hardware than simple point-to-point messaging.
Middleware analysis skills needed to configure, manage, and operate an ESB.
Extra overhead and increased latency caused by messages traversing the extra ESB layer, especially as compared to point-to-point communications. The increased latency also results from additional XML processing (the ESB normally uses XML as the communication language).
Though ESB systems can require a significant effort to implement, they produce no commercial value without the subsequent development of SOA services for the ESB.[4]
[edit] See alsoEnterprise Integration Patterns
Java Business Integration
Business Process Management
Universal Integration Platform
Enterprise application integration
Business Service Provider
Message Oriented Middleware
Complex Event Processing
Event Stream Processing
Event-driven programming
Comparison of Business Integration Software
Comparison of BPEL engines
event-driven SOA
[edit] Commercial ProductsIBM WebSphere ESB
JBoss Enterprise SOA Platform
Microsoft BizTalk Server
Progress Fuse ESB
Progress Sonic ESB
Oracle Enterprise Service Bus
TIBCO ActiveMatrix
JBoss Enterprise SOA Platform
[edit] BooksDavid Chappell, "Enterprise Service Bus" (O’Reilly: June 2004, ISBN 0-596-00675-6)

What's New in Windows Communication Foundation .Net 4.0

Configuration Based Activation
Normally when hosting a Windows Communication Foundation (WCF) service under Internet Information Services (IIS) or Windows Process Activation Service (WAS), you must provide a .svc file. The .svc file contains the name of the service and an optional custom service host factory. This additional file adds manageability overhead. The configuration-based activation feature removes the requirement to have a .svc file and therefore the associated overhead. For more information, see Configuration-Based Activation in IIS and WAS, Configuration-Based Activation.
System.Web.Routing Integration
When hosting a Windows Communication Foundation (WCF) service in IIS, you place a .svc file in the virtual directory. This .svc file specifies the service host factory to use as well as the class that implements the service. When making requests to the service you specify the .svc file in the URI, for example: http://contoso.com/EmployeeServce.svc. For programmers writing REST services, this type of URI is not optimal. URIs for REST services specify a specific resource and normally do not have any extensions. The System.Web.Routing integration feature allows you to host a WCF service that responds to URIs without an extension. For more information, see System.Web.Routing Integration, SystemWebRouting Integration Sample.
Multiple IIS Site Bindings Support
When hosting a Windows Communication Foundation (WCF) service under Internet Information Services (IIS) 7.0, you may want to provide multiple base addresses that use the same protocol on the same site. This allows the same service to respond to a number of different URIs. This is useful when you want to host a service that listens on http://www.contoso.com and http://contoso.com. It is also useful to create a service that has a base address for internal users and a separate base address for external users. For more information, see Supporting Multiple IIS Site Bindings,
Routing Service
The Routing Service is a generic SOAP intermediary that acts as a message router. The core functionality of the Routing Service is the ability to route messages based on the message content, which allows a message to be forwarded to a client endpoint based on a value within the message itself, in either the header or the message body. For more information, see Routing, Routing Services .
Support for WS-Discovery
The Service Discovery feature enables client applications to dynamically discover service addresses at runtime in an interoperable way using WS-Discovery. The WS-Discovery specification outlines the message exchange patterns (MEPs) required for performing light-weight discovery of services, both by multicast (ad hoc) and unicast (utilizing a network resource). For more information, see WCF Discovery, Discovery (Samples).
Support for HTTP Decompression
WCF clients now have built-in support for HTTP decompression. A client can decompress received messages that were compressed with the gzip/deflate format.
The following table contains links that instruct how to enable an IIS server for compression.
IIS 6.0
http://go.microsoft.com/fwlink/?LinkID=189308&clcid=0x409
IIS 7.0
http://go.microsoft.com/fwlink/?LinkId=189309
By default, a WCF client sends an Accept-Encoding header to the server to notify that it can decompress data. This default behavior can be turned off by creating a custom binding based on the HttpTransportBindingElement and setting the DecompressionEnabled property to false.
Standard Endpoints
Standard endpoints are pre-defined endpoints that have one or more of their properties (address, binding, contract) fixed. For example, all metadata exchange endpoints specify IMetadataExchange as their contract, so the developer does not have to specify the contract. The standard MEX endpoint therefore has a fixed IMetadataExchange contract. For more information, see Standard Endpoints, .
Workflow Services
With the introduction of a set of messaging activities, it is easier than ever to implement workflows that send and receive data. These messaging activities allow you to model complex message exchange patterns that go outside of the traditional send/receive or RPC-style method invocation. For more information, see Workflow Services, Services, Services.
Target Framework Attribute
The target framework attribute is used to specify the version of the .NET Framework an application hosted in IIS or WAS is targeting. It allows you to build applications that target .NET Framework 2.0, 3.5, or 4 using Visual Studio. It is an attribute set within a tag in an application's Web.config file as shown in the following example.

Copy
targetFramework="4.0">







When an application hosted in IIS or WAS targets a version of the .NET Framework that is not installed, an exception is thrown that indicates the problem. If the target framework moniker is not specified in the application's Web.config file, the value is inferred from the application pool version configured in IIS.
Because of this new feature, if you try to host a WCF service written with .NET Framework 3.5 on a machine running .NET Framework 4, you may get a ProtocolException with the following text:
Unhandled Exception: System.ServiceModel.ProtocolException: The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were: ' ...
This error occurs because the application domain that IIS is running within is running .NET Framework 4 and the WCF service is expecting to run under .NET Framework 3.5. For more information about how to fix this problem, see How to: Host a WCF Service Written with .NET Framework 3.5 in IIS Running Under .NET Framework 4.
WCF REST
Caching
The .NET Framework 4 enables you to leverage the declarative caching mechanism already available in ASP.NET in your WCF REST services. This allows you to cache responses from your WCF REST service operations. When a user sends an HTTP GET to your service that is configured for caching, ASP.NET sends back the cached response and the service method is not called. When the cache expires, the next time a user sends an HTTP GET, your service method is called and the response is once again cached.
The .NET Framework 4 also allows you to implement conditional HTTP GET caching. In REST scenarios a conditional HTTP GET is often used by services to implement intelligent HTTP caching as described in the HTTP Specification. For more information, see Caching Support for WCF Web HTTP Services, Caching and Automatic Help Page.
Formats Support
The WCF web HTTP programming model allows you to dynamically determine the best format for a service operation to return its response in. Responses can be set automatically for XML and JSON based on the accept header. Helper APIs have been added to programmatically set the format of an operation. For more information, see WCF Web HTTP Formatting, Automatic Format Selection, Advanced Format Selection.
HTTP REST Error Handling
WCF web HTTP error handling enables you to return errors from WCF REST services that specify an HTTP status code and return error details using the same format as the operation (for example, XML or JSON). For more information, see WCF Web HTTP Error Handling, .
Deployment Features
The configuration needed to run a service has been simplified and new standard endpoints have been introduced to further simply service configuration. For more information about the new simplified configuration see, Simplified Configuration. For more information about standard endpoints see, Standard Endpoints.
When hosting a Windows Communication Foundation (WCF) service in IIS you place a .svc file in the virtual directory. This .svc file specifies the service host factory to use as well as the class that implements the service. When making requests to the service you specify the .svc file in the URI, for example: http://contoso.com/EmployeeServce.svc. For programmers writing REST services this type of URI is not optimal. URIs for REST services specify a specific resource and normally do not have any extensions. The System.Web.Routing integration feature allows you to host a WCF REST service that responds to URIs without an extension. For more information, see System.Web.Routing Integration.
Cross Domain JavaScript
JSON Padding (JSONP) is a mechanism that enables cross site scripting support in web browsers. JSONP is designed around the ability of web browsers to load scripts from a site different from the one the current loaded document was retrieved from. The mechanism works by padding the JSON payload with a user-defined callback function name, for example:

Copy
callback({ “a” = \“b\” });
In the above example the JSON payload, {“a” = \”b\”}, is wrapped in a function call, callback. The callback function must already be defined in the current web page. The content type of a JSONP response is “application/javascript”. For more information, see JSONP.
WCF REST Service Help Page
.NET Framework version 4 provides an automatic help page for WCF REST services. This help page lists a description of each operation, request and response formats, and schemas. For more information, see WCF Web HTTP Service Help Page, Caching and Automatic Help Page.
http://msdn.microsoft.com/en-us/library/dd456789.aspx