SOAcollective

WCF Discovery

Neo — Tue, 20 Mar 2012 19:52:32 +0000

One of the complexities of maintaining an enterprise SOA architected system is keeping all of the service endpoint addresses and binding information updated on all client and server machines. This normally has to be done manually on each machine by editing configuration files. The absence of WCF Discovery becomes more evident as the number of services, hosting instances and environments grow with the configuration files getting out of control.
When .NET 4.0 was released there was a new feature added to WCF called Discovery. WCF Discovery provides a mechanism for services to announce themselves when they start as well as announce that they are stopping. There is also a mechanism for clients to probe for services to find out where a specific service type is running.
There are two discovery operational modes provided for WCF Discovery: Managed and Ad-Hoc. In Managed mode there is a centralized server called a discovery proxy that maintains information about available services. Services can announce to this central server when they start and when they stop. Client applications can send probe requests to this central server looking for specific service types, if there are any matches, a ProbeMatch response is returned. In Ad-Hoc mode, there is no centralized server. All discovery messages such as service announcements and client requests are sent by multicasting. The Ad-Hoc mode requires no coding of a central server so it is easy to use but has one major problem. The messages sent with multicasting are limited to the network subnet. This means that the WCF Discovery messages will not be broadcasted in all nodes in the network. For any system at the enterprise level, the Ad-Hoc mode is not even a choice.
True enterprise Discovery is implemented by the managed mode using a WCF Discovery proxy, but Microsoft does not provide such an implementation. As companies attempt to build a Discovery proxy, there are several interesting challenges with WCF services hosted in both IIS and AppFabric. The most important challenge to solve is the maintenance of the state of a WCF service. In IIS, a service is started when accessed. If the service is configured to announce itself on startup the ‘Announce’ message will be sent to the central proxy server. Considering the fact that a WCF service in IIS is automatically stopped after a period of inactivity, it causes the WCF service to send its stopped announcement and the service endpoints are removed by the central proxy server. But the endpoints are still there and activation can restart the service any time a request comes in. Does the endpoint exist? What is its real state? Maybe a dormant state? This scenario implies that the service has three states rather than two. If a client application is now probing looking for the WCF service being hosted in IIS, and the central proxy server does not account for this “dormant state” then the proxy does not have any knowledge of the endpoint to respond and thus ignoring the fact that when the endpoint is accessed by a client application, the WCF service being hosted in IIS would be restarted.
Link to Microsoft documentation on WCF Discovery http://msdn.microsoft.com/en-us/library/dd456791.aspx

Requirements in an SOA project using WCF

Neo — Tue, 20 Mar 2012 19:47:37 +0000

What is required to be in place to start an SOA project using WCF?

How easy it is today to adapt an SOA environment or a technology that is not open source or is not provided directly by popular software vendors? It seems that the answer is definitely negative since you feel that you will either be locked into something proprietary or that you will eventually fill in the gap with the vendor providing the technology as a standard.

So what do you do?

Well, you either go ahead and build it on your own or simply do nothing because you do not need it! Besides if you go ahead and build it, it is your own code and you can keep track of it at all times and you will grow it with time. After all, what do you care if you leave the company? Your code is so perfect that it is a blessing for anyone to take over it, right?

Considering these fundamentally wrong and destructive facts about making crucial software choices and the runtime complexity of an enterprise SOA environment that is fanatically ignored from start to finish, we have chosen to build a technology that implements everything outside of your own custom built services and is extremely critical to the runtime environment of SOA software.

Having the illusion that SOA services will be easy to manage, monitor, troubleshoot and diagnose critical issues or even recognize disastrous
issues from coming, SOAcollective is currently providing “SOA out of the box” with one big promise.

You do not need to write any code to either make your services light up in the enterprise or fallback to what you had before (the blind world). Just focus building WCF services the way you know how to build them and let the environment transparently take care of the rest.

In a typical SOA project, after business requirements are gathered, it is often the case that the architecture team on the project tries to define a critical set of features that are needed to support the SOA runtime environment. Since this is an environmental adaption, designers and developers should not have to worry about it and they should only focus on how to design and implement SOA services based on the business requirements and use cases. Usually what goes into this SOA environment depends on the level of expertise of the team and their experiences with SOA projects in production. Initially, the
usual candidate is the build and deployment procedures which are naturally needed.

What is importance to notice here is that several important mandatory SOA features and core functionality that are related to SOA runtime management, troubleshooting, topology and dynamic discovery are ignored or appear to be unknown as if all will be perfect once the services are running. If these features are so important why are they ignored?

To answer this question we need to focus on the fundamental differences between an SOA project and any other related project that targets business services development and integration like (EAI) with OOP. As UML does not go any further than to satisfy OOP designs, new challenges arise as to how to represent transactions, service instantiation modes, service boundaries, security, bindings, behaviors, WSDL representations and in general SOA concepts that do not hold true in the pure OOP programming environment.

Now that we have discovered that we have an issue as to how to create blueprints of our SOA designs, should we worry about the SOA runtime environment?

To make things even worse, due to the nature of SOA where each service lives in its own island, the majority of developers today believe that all services can be developed without any framework or dependencies, since it may be a violation of the SOA nature itself. While this may be partially true, it is not 100% correct. What seems to be needed more at the end it should be there from the beginning and this is due to the complex SOA runtime environment that is very difficult to track while in production. One fundamental architectural component that we discuss in a different document is WS-Discovery and how it significantly eliminates both complexity and cost.

SOAcollective’s goal is to provide the SOA runtime features listed below “out of the box”

1. Node Utilization

2. SOA Topology

3. WS-Discovery

4. Diagnostics

5. Metrics

We all know that Web services need monitoring and management and we all want to do it with:

1. The least environment impact. The environment does not even run where your services are hosted.

2. An easy SOA environment to adapt without dependencies.

3. Not to spend half of the budget on expensive web services broker solutions that
require a team of people to maintain them and often do not even target the WCF
specifics but rather apply to web services across the board.

4. Be able to ignore the SOA environment anytime and opt out of any value added
features.

SOAcollective today offers such an environment that is well supported by a company that listens to its clients. As a technology SOAcollective can run in any network and/or cloud. If companies feel that they run blind in their own networks, one can imagine how it is in the cloud. SOAcollective can be configured to easily support a hybrid/private and public modes with the same software with the same solution.

WCF Discovery or UDDI?

Neo — Tue, 20 Mar 2012 19:31:35 +0000

Some people are wondering if WS-Discovery is needed and even if updating configuration files is such a big deal. Someone can say I have one hundred different boxes that I have to update every time services move around. It is evident that the pain and maintainability grows not only on the number of servers but also on the number of services. The other important factor that needs to be taken into consideration is also the cost, the complexity and the runtime performance one may phase by building a reliable, fast and fault tolerant discovery implementation. As of today, such an implementation was not available out of the box and without any coding. SOAcollective has built a fault tolerant reliable discovery implementation that obeys all WS-Discovery standards and even provides more than the standard implementation to make it easier to access services wherever they are.

UDDI is a central registry that stores information that relate to available services. It is merely a cataloging scheme where consumers query services based on filter criteria. This directory services type database of information allows consumers to query for services by name, address, contract, category, or by other data. UDDI is the DNS of Web services. I consider UDDI old school and WS-Discovery a lighter and more appropriate discovery mechanism for WCF. If the WCF discovery proxy implementation takes into consideration transparent validation of services status in the background, efficient caching and fault tolerant algorithms as well as proving metadata that can be used for completely eliminating configuration files then there is no substitute Discovery mechanism for WCF.
WS-Discovery provides a protocol to discover services that are coming and going from a network. As a service joins the network, it informs its peers of its arrival by broadcasting a Hello message; likewise, when services drop off the network they multicast a Bye message. WS-Discovery doesn’t rely on a single node to host information about all available services as UDDI does. Rather, each service host forwards information about the status of its hosted service thru Named Pipes to the resident discovery proxy running on the same server. This reduces the amount of network infrastructure needed to discover services and facilitates bootstrapping.

SOAcollective Value Proposition

admin — Mon, 31 Jan 2011 03:08:51 +0000

SOA is fantastic – most people get that. What is often missed is the cost of entry. You begin to realize that you need to have quite a few things in place before you even think about business logic – let alone going into production. This is where SOACollective comes in; it closes the barrier to entry by giving you many of those core “things” like enterprise-wide WS-Discovery, metrics, logging and diagnostics right out of the box.

SOAcollective integrates seamlessly with your AppFabric SOA infrastructure and gives a huge lead time and security of investment to corporations by eliminating many of the silent and unknown factors that lead to failure in distributed service development. These factors are typically the lack of:

Common framework for SOA development
Life-cycle management of services
Proper SOA build and deployment procedures
Robust service management and diagnostics

As the enterprise grows, corporations lose track of what and how many services are running, what their usage is, who is responsible for maintaining them, where they run and what purpose each serves.

Features of SOAcollective Solutions

Reduces startup costs and risks of a service oriented architecture to provide the mandatory features that do not relate to pure business service development.
Allows for real time service management in the production environment. Administrators can visualize in real time all service activity from the browser.
Provides services life cycle management with full analytics on historical runtime statistics of services developed that run in the enterprise.

The goal of SOAcollective is to allow an enterprise start a project without the typical architecture and infrastructure investment, eliminate the SOA and WCF learning curve, and promote pure WCF development with zero restrictions and dependencies.

To speed up overall development, we have identified that before an SOA engagement starts the following have to be in place for business developers to rely on developing, testing and maintaining their services:

Runtime management
Diagnostics
Monitoring
Metrics
Validation
Caching

With SOAcollective, these factors and many others are eliminated through the power of the SOAcollective platform and the expertise of our SOA experts.

Why Choose SOAcollective?

admin — Sun, 30 Jan 2011 19:24:37 +0000

Choosing a service oriented architecture for your project comes with many advantages, but is not without challenges as well. By adopting SOAcollective solutions and team members, you can significantly reduce the amount of risk these design challenges present.

Utilize both our SOA solutions and team’s expertise to give you a huge head start into your SOA enterprise engagement. Our SOA solutions are in production with fortune 100 companies serving millions of critical requests every day. SOAcollective follows proven SOA design processes, build procedures, deployments, runtime management, monitoring and services cataloging that will:

Guarantee successful project completion and full runtime support.
Allow your corporation flexibility to produce new systems and execute any combination of requirements quickly.

SOA Project Fundamentals

We believe there are common, mandatory investments that need to be made on every project.

A framework architecture
Services lifecycle management support
Auto builds and deployments of SOA services
Cataloguing the services in a registry
Monitoring, enterprise service remote management
Services discovery

With any SOA engagement a company is required to put in an up front effort to build an SOA infrastructure to build, manage, monitor and catalog services. This effort can run in the millions in costs and take years to fully mature. Our SOA solutions have taken this maturity time and serve millions of service requests on a daily basis. Through its service lifecycle support critical business services have matured and companies have realized gains in productivity and stability.

Contact SOAcollective today to schedule a workshop featuring the SOAcollective solution stack.