 Monday, 31 October 2005
In my previous post, I commented on the 4 tenets (i.e. principles) of a SOA. One of these tenets is, Services share schemas and contracts, not classes or types. Most developers understand what this means, however, in Visual Studio (VS), it isnt so easy to make this so because VS assumes an XML-based RPC view of Web Services. Here is what I mean.
The .NET Framework makes it extremely easy to create and deploy a Web Service, which is the primary delivery model for a SOA. The process in VS is deceptively simple you add an .asmx file to your project, add a couple of methods, then build your solution, and voila, you have a Web Service. In the background, VS generates a WSDL on the server side and a client proxy on the client side. VS quietly handles all of this for you, which is not necessarily a good thing as mentioned above, VS assumes an XML-based RPC view of web services.
There is concept in Web Services development called contract-first or contract-driven development. Basically, instead of letting Visual Studio generate a WSDL file for you, you should write this WSDL by hand using a WSDL, XML or text editor. BizTalk developers get the virtue of contract-first development, we have been doing it for years.
Btw, WSDL stands for Web Services Description Language. It is an XML format used to describe a Web Services interface by defining its operations and message exchange patterns. The actual messages are defined using a schema definition language like XSD.
Why would you want to write your WSDL by hand when VS generates this for you? Letting VS generate your WSDL for you is like picking up your cell phone from a phone company and then letting the phone company handle the contract for you. Sure, you get your cell phone, but you dont know what you are committed to from a contract perspective.
By writing your own WSDL, you have complete control over how your Web Service will be seen to the outside world, including its interface and data structures. In other words, you have designed it. This is really a continuation of the idea of contract-driven development that has been around for years - the idea of first creating a contract that your object will implement and that your clients will consume.
However, writing WSDL to your Web Services by hand is not such an easy task and there are not really any great tools out there to help out. In addition, the format takes a bit getting used to and then after you have created your WSDL, you then need to create the client-side proxy and the server-side Web Service code.
There is a great VS add-in called WSContractFirst that was written by Christian Weyer in an effort to make contract-first development easier. Using this VS add-in, you can generate the code for client-side proxies and server-side Web Services based on the WSDL file right inside of VS.
I found this "hack" in James Averys most excellent book called, . Thanks James!
Wednesday, 19 October 2005
Man, oh man, there is a ton of buzz (or is it hot air?) around this TLA. I have been in the software industry as a programmer type for 15 years and have never seen so much marketing hype and confusion around this term. Here is the technical truth.
What is SOA?
SOA is based on a systems environment specifically architected to utilize free standing units of functional code, each of which corresponds to a specific activity.
What is a Service?
A self-describing software component that is accessible over a network and has a published interface that does not require knowledge of the technology used to create and deploy it.
What is a Web Service?
Web services should be seen as the primary delivery model for SOA.
Key Attributes of a SOA
- Network-based architecture
- Standards-based defined architecture (XML, SOAP, WSDL)
- Has discoverable components
- Separates interfaces from functions
- Is a federated services model
- Is architected for reuse
The four tenets of Service Orientation
- Boundaries are explicit
- Services are autonomous
- Services share schemas and contracts, not classes or types
- Compatibility is policy-based
Fact: SOA is a modern type of software architecture design. Thats it! Nothing more, nothing less.
What amazes me is that the SOA hype is pushed by vendors and analysts to mean something (everything!) else other than simply a type of technical software architecture design. I have seen vendors brand their products as SOA products. How can a type of software architecture design be a standalone product? Makes no sense. I have also seen SOA described as a technology. Huh? The whole point around SOA is that it is technology independent.
Further, we have technical people trying to describe SOA to business people. Thats a mistake. How would a business person know anything about modern software architecture design? And why should they care? Business people just want their IT problems solved.
Eventually people will figure out that SOA is yet another TLA buzzword invented by someone, somewhere whose only meaning is simply modern software architecture design baby! Software Architects, including your truly, have been practicing the design of SOAs for some time and as written elsewhere, SOA This, SOA That, SOA What!?!
Thanks to Chris Pels of iDevTech for the no-nonsense technical definitions (a.k.a. the truth) of a SOA.
Wednesday, 14 September 2005
The title is a quote from Don Box while presenting Windows Communication Foundation at Microsofts Professional Developers Conference in LA. Many years ago I read some of Dons books and was always impressed on how he got Windows. I had the pleasure of seeing him live at this years PDC and saw what a dynamic speaker he is, in addition to the fact that he probably knows more about Windows then any other person on the planet.
Dons SOA comment goes directly to how goofy our industry has become where everyone has latched onto this latest TLA. I cant go anywhere in the software world without running across SOA. Like Don says, SOA what! To quote Don, Message, oh message, the truth is on the wire. There is nothing else. So much for SOA
I was able to catch Steven Sinofskys presentation on Office 12. The big news is the investment Microsoft has made in SharePoint Version 3. I thought SharePoint 2003 was pretty cool as that is how I make my living as an Architect, solving customer problems using SharePoint. However, version 3 is incredible! It is the center piece of Microsofts Enterprise Content Management (ECM) strategy for the Information Worker. It represents the 5 pillars of connected systems, Interaction (using Atlas), Messaging and Services (using Windows Communication Foundation), Workflow (using Windows Workflow Foundation), Identity and Access (using InfoCard and AD), and Data (using SQL 2005). Whats really surprising to me is that at this years PDC, nothing on ASP.NET web application development. It looks like that SharePoint is the web application of choice.
Speaking of Workflow, I got to see Windows Workflow Foundation in detail. Essentially it is a framework (i.e. a set of APIs) that allows you to embed workflow in your custom developed applications. Since it is part of the Windows platform, it is available for anyone to use and has built in support in Office 12 and the new version of FrontPage.
One really cool feature of WWF is to be able to draw a workflow as a state diagram. State diagrams are different than sequential workflows as they are more ad hoc in nature and makes a perfect match for many human business processes that are also ad hoc where workflow steps are skipped or even better, dynamic in nature. Dynamic update meaning we now have the ability to change the workflow logic while the workflow is running. This is pretty amazing and matches much closer to the real world then a static sequential workflow. This also means that you do not have to recompile. Cool!
Now I have been using workflow (a.k.a. orchestration) in BizTalk 2004 for some time and wondered how the two technologies work together. As I understand it, using WWF is great for workflow inside applications and BizTalk is great for using workflow across applications. Makes sense, but I am sure we will see a version of BizTalk that will use WWF in the future.
I also wondered how BizTalk 2006 (BTS) will work with Windows Communication Foundation (WCF). As explained to me, WCF is a great framework for building connected systems (Microsofts term for SOA), but has no facility for orchestration. In other words, point to point communications. Adding BTS works in concert with WCF for additional business process and integration server capabilities which adds another layer of abstraction in distributed systems design. Again makes sense, but I am sure there are other plans for BizTalk in the future which I will get to hear about tomorrow.
Also tomorrow, I will get to see and hear a session on Visual Studio Team System for Software Architects and Future Directions in Modeling Tools. I am quite excited by this as I believe this is another step in the industrialization of software, which is what my blog is all about. Till tomorrow.
Wednesday, 07 September 2005
In a previous post, I discussed a product called BRIDGEWERX, which uses BizTalk server as its COTS middleware engine. In that post is a diagram of the BRIDGEWERX logical component architecture in which you may have noticed a term called dynamic interrogation.
One of the coolest features about BizTalk is that you can dynamically interrogate an application you wish to communicate with on a network and query it to return all of its public (XML) message schemas that can be exchanged with this application. BizTalk uses an adapter that knows how to communicate with BizTalk on one end and the native interface of the application you want to communicate with on the other end. Currently there are dozens of third-party adapters available for BizTalk that use this standard interface mechanism, plus several adapters that come out of the box with BizTalk.
For example, in BizTalk, through the Visual Studio IDE at design time, I can install a BizTalk adapter that can communicate with SAP. Through a properties sheet in BizTalk, I can give the adapter a physical address that points to my SAP instance on my network. I can fill in security credentials that will allow BizTalk to communicate with the SAP application, through the adapter.
Still at design time, I can then tell BizTalk, through the adapter, to return all of the message schemas that are available for this specific instance of SAP. In other words, dynamically interrogate SAPs message interface. Those message schemas are actually the public message types that I can use to map to other schemas as part of my application integration solution. For example I can have SAP communicate with Great Plains and exchange financial data, even though the two message formats are different. BizTalk has a mapping tool that graphically maps one file format to another, but thats another topic.
This is a great example of a service oriented architecture (SOA) as through BizTalk and an adapter (bought or built) that knows how to communicate natively with the application, I can expose the public schema messages (i.e. at run-time, instance data) as a service to be consumed by any other application completely location independent.
Using BRIDGEWERX (BW) Designer, I can extend this service oriented architecture approach to dynamically interrogate any application in the world. Think of it this way, through BW Designer, as an on-line modeling tool, I can dynamically interrogate any application in which I have already installed an adapter on a BizTalk server for. Of course, this means having the right physical addresses and security credentials in place. Even though this is across the web, any competent Network or Security analyst can lock it down and secure the connections without any worries of security breaches. Its done all of the time.
The point is that dynamic interrogation using BRIDGEWERX, and BizTalks middleware engine, can allow any application to communicate messages to any other application, regardless of application type or geographical location. The fact that I can do this at design time, and with just a browser, allows me to 100% specify up front all of the application integration interactions for my designed solution. Because of this approach, we can code generate the application integration. Dynamic interrogation is another excellent example of advancing the industrialization of software.
© Copyright 2010 Mitch Barnett - Software Industrialization is the computerization of software design and function.
newtelligence dasBlog 2.2.8279.16125 Theme design by Bryan Bell
 | Page rendered at Saturday, 07 August 2010 05:11:20 (Pacific Daylight Time, UTC-07:00)
|
On this page....
Search
Categories
Software Engineering Links
Sign In
|