With 2011 around the corner we, at Tellago and Tellago Studios, we have been spending a lot of times evaluating our successes and failures (yes those too ;)) of 2010 and delineating some of our goals and strategies for 2011. When I look at 2010 here are some of the things that quickly jump off the page:
When I look at our achievements, I am particularly proud of the fact that we didn’t have a single Tellago employee resign or being laid off this year :)
Talent, passion and teamwork
![Toscanini[1]](http://weblogs.asp.net/blogs/gsusx/Toscanini1_thumb_4F89B6E8.jpg "Toscanini[1]")
“No one can whistle a symphony. It takes an orchestra to play it.” At Tellago, we succeed or fail as a team. There are no individual talents bigger than our goals as a company. During 2010, we’ve achieve that by bringing together a set of very talented programmers that are passionate about technologies and, at the same time, are great team players. We firmly believe on hiring some of the best programmers in the Microsoft world, building great teams and wait for wonderful things to happen :). More importantly, we have worked really hard to make sure every developer at Tellago sees this company as the opportunity to work with some of the brightest engineers in the industry, break some rules, try to do things differently and work on things that matter.
Our own Chris Love summarized why he loves working at Tellago: http://professionalaspnet.com/archive/2010/07/15/Why-I-Love-Working-for-Tellago.aspx
Don’t be average: Build stuff that matters
![eifeel[1]](http://weblogs.asp.net/blogs/gsusx/eifeel1_thumb_0DA2D19A.jpg "eifeel[1]")
I’ve always been a firm believer on building things that matter and trying to make a difference. Tellago Studios has been a long time dream as a vehicle for building enterprise software that follows some of the modern techniques pioneered in Silicon Valley and that, frankly, defies the stigma that enterprise software mostly sucks! Our first product: SO-Aware it’s a solid testimony to those principles. In a matter of five months, we have a significant number of companies in production or active development as well as more than 270 companies currently evaluating the software. If you were happy with SO-Aware you should wait for our second and third product which are launching in February.
We’ve explained some of these concepts in our interviews at Microsoft’s Endpoint TV last summer: http://channel9.msdn.com/Shows/Endpoint/endpointtv-Meet-SO-Aware-Part-1
In addition to Tellago Studios, we have shown our commitment to open source but launching and maintaining Tellago DevLabs. In the next few months, we will be open sourcing some of the cool technology packages we have been using in our current projects.
What’s up for 2011
Without given a complete roadmap about our plans for 2011, I can tell you that we are looking as this upcoming year as a time to expand our services and software portfolio into technologies that has an impact in the current world. In that sense, we expect to increase our work into new technology areas with a lot of emphasis on open source technologies that complement and extend the current Microsoft stack. Additionally, this year we are going to obsess about agile processes as much as we do about technology. More to come soon….
BTW, did I tell you we are hiring? :)
Happy 2011!
With all the holidays madness I didn't realized that my "Integrating BizTalk Server and StreamInsight" paper is now available on MSDN. This paper was originally an idea of the BizTalk product team and intends to present some fundamental scenarios that can be enabled by the combination of BizTalk Server and StreamInsight.
Thanks to everybody who, directly or indirectly, provided feedback about this paper: Syed Rasheed, Mark Simms, Richard Seroter, Roman Schindlauer and Torsten Grabs from the StreamInsight team and my Tellago colleagues Dwight Goins, Don Demsak and Adrian Lopez.
Happy reading...
This is the first of a series of posts on which I am hoping to detail some of the most common SOA governance scenarios in the real world, their challenges and the approach we’ve taken to address them in SO-Aware. This series does not intend to be a marketing pitch about SO-Aware. Instead, I would like to use this to foment an honest dialog between SOA governance technologists.
For the starting post I decided to focus on the aspect that was once considered the keystone of SOA governance: service discovery
Scenario
In a real SOA enterprise infrastructure with hundreds of services, it is safe to assume that service endpoints are going to constantly be subjected to changes in areas such as location (URL), policy (security, etc) or contract (WSDL, operations). As SOA developers, we would like to make our applications as resilient to those changes as possible so that they don’t impose any constraints in the natural evolution of our SOA. A common practice to accomplish that is to have client application to resolve service metadata such as endpoints or policies against a service repository like is illustrated in the following figure:
![ServiceRegistry[1]](http://weblogs.asp.net/blogs/gsusx/ServiceRegistry1_thumb_224E5719.png "ServiceRegistry[1]")
The screwed-up traditional solution: The UDDI way
![Looking[1]](http://weblogs.asp.net/blogs/gsusx/Looking1_thumb_7963420F.png "Looking[1]") |
In order to address these challenges, the big SOA vendors (read Microsoft, Oracle, IBM etc) created a standard that with the purpose of modeling service metadata information that could be used to enable service discovery capabilities. The standard was baptized as Universal Data Discovery and Integration (UDDI) and, unfortunately, it became the cornerstone of SOA governance products such as SOA Software or Systinet.
|
Despite the several attempts to leverage it as part of SOA governance platforms, UDDI has proven to be an incredibly ineffective mechanism to enable service publishing and discovery. If you’ve ever used a UDDI registry, this shouldn’t come as a surprise.
For instance, the following SOAP message is required to discover a service endpoint using UDDI.
1: <soap:Envelope
2: xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
3: xmlns:xsd=http://www.w3.org/2001/XMLSchema
4: xmlns:soap=
5: "http://schemas.xmlsoap.org/soap/envelope/">
6: <soap:Body>
7: <find_service businessKey="Key1"
8: generic="2.0"
9: maxRows="15"
10: xmlns="urn:uddi-org:api_v2">
11: <findQualifiers>
12: <findQualifier />
13: <findQualifier />
14: </findQualifiers>
15: <name ="" />
16: <name ="" />
17: <categoryBag>
18: <keyedReference tModelKey="tModelKey1"
19: keyName="tModelKey1Name"
20: keyValue="tModelKey1Value" />
21: <keyedReference tModelKey="tModelKey2"
22: keyName="tModelKey2Name"
23: keyValue="tModelKey2Value" />
24: </categoryBag>
25: <tModelBag>
26: <tModelKey>tModelKey3</tModelKey>
27: <tModelKey>tModelKey4</tModelKey>
28: </tModelBag>
29: </find_service>
30: </soap:Body>
31: </soap:Envelope>
And the response is even more confusing:
1: <soap:Envelope
2: xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
3: xmlns:xsd=http://www.w3.org/2001/XMLSchema
4: xmlns:soap=
5: "http://schemas.xmlsoap.org/soap/envelope/">
6: <soap:Body>
7: <serviceList generic="2.0"
8: operator="MyCompany"
9: truncated="false"
10: xmlns="urn:uddi-org:api_v2">
11: <serviceInfos>
12: <serviceInfo serviceKey="ServiceKey1"
13: businessKey="Key1">
14: <name ="CRMSOAPService" />
15: <name ="" />
16: </serviceInfo>
17: </serviceInfos>
18: </serviceList>
19: </soap:Body>
20: </soap:Envelope>
What makes this process ridiculously hard is the complexity of the UDDI API and the model. Just think about what it will take for a client written in a dynamic language like Ruby(aka doesn’t do SOAP very well) to interact with a UDDI repository.
Bottom line, the SOA models created with UDDI are incredibly complex to implement and use and, quite often, end up becoming another bottleneck in your SOA.
A better solution: The SO-Aware way
When we were building SO-Aware, we decided to avoid the complexities of UDDI and instead enable a way simpler mechanism to facilitate the discovery and query of services. We achieved that by implementing a 100% RESTful API based on the OData standard that allows querying the entire service registry using plain HTTP GETs.
In this model, discovering a new service is just a matter of executing an HTTP GET like the following:
GET /SOAware/ServiceRepository.svc/Services('Service Name')
The response is an AtomPub payload with the service details:
1: <feed xml:base=" http://<WebHost>/ServiceRepository"
2: xmlns="http://www.w3.org/2005/Atom">
3: <title type="text">Services</title>
4: <id> http://<WebHost>/ServiceRepository /Services</id>
5: <updated>2010-10-01T02:33:55Z</updated>
6: <link rel="self" title="Services" href="Services" />
7: <entry>
8: <id> http://<WebHost>/ServiceRepository /Services(‘id’')</id>
9: <title type="text">CRMSOAPService</title>
10: <content type="application/xml">
11: <m:properties>
12: <d:Id m:type="Edm.Guid">Service ID</d:Id>
13: <d:Name>CRMSOAPService</d:Name>
14: <d:Description>This is a SOAP
15: endpoint that abstracts a CRM system</d:Description>
16: <d:Namespace>http://soaware.samples.com</d:Namespace>
17: <d:Style>SOAP</d:Style>
18: </m:properties>
19: </content>
20: </entry>
21: </feed>
Compare this approach with the complexity of the UDDI based model and draw your own conclusions. Basically, this model makes abstracts the interaction with the service registry as simple AtomPub HTTP GETs and POSTs messages. Given that the entire model is based on AtomPub, users can subscribe their favorite Atom reader so feeds that describe the relevant service events such as creation, updates, etc.
Our WCF Registry: SO-Aware keeps being evangelized throughout the world. This week Tellago Studios' Dwight Goins will be speaking at Microsoft events in Dallas and Houston (https://msevents.microsoft.com/cui/EventDetail.aspx?culture=en-US&EventID=1032469800&IO=ycqB%2bGJQr78fJBMJTye1oA%3d%3d) about WCF management best practices using SO-Aware. If you are in the area and passionate about WCF you should definitely swing by and give Dwight a hard time ;)