Some highlights from AR / PR coverage (if you missed them) 1. AMR’s coverage of BizTalk RFID ( Microsoft BizTalk Server 2006 R2: RFID for Everyman ) 2. Manufacturing Business Technology – Microsoft touts new edition of BizTalk as low-cost solution for…(read more)
Although with very little publicity (!?), BizTalk 2006 R2 RTM’d 2 weeks ago. This new (evolutionary) version includes a very interesting set of new features, including an RFID server, the ability to expose and invoke services using WCF, EDI support, and lots of other new stuff. Here’s my first post about this a few months back, and BizTalk HotRod issue 1 has an article detailing the new features.
The evaluation version can be downloaded from here. The Developer edition ISO has been posted to MSDN Subscriber downloads yesterday.
I’m looking forward to try out this version in conjunction with BizTalk Services…
Back from an hot summer, I wanted to post about an article posted two years ago on Jeff Sutherland’s blog on Scrum: %u00abFuture of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects%u00bb. I am by no means an expert of Scrum, but I’ve been on two projects using this methodology, and I’ve been introducing its adoption at |create|it|, my almost 6 year old company (link in PT-PT). This article apparently created some discussion when it was published, but I’m finding it extremely interesting. It describes 3 ways to do Scrum, by varying the intervals between Sprints and anticipating some of the work done at those intervals. What I found most interesting, however, where the findings related to functional and technical specifications:
[…] This suggests that minimal functional specifications should be clear at the beginning of a Sprint and that design and technical specifications are best done within a Sprint. […]
An interesting notion, and one that I’d already been resorting to, lately – writing detailed functional specifications, as well as overall architecture documents, and then just proceed to development. I guess this is what Fowler calls Evolving Architecture (link in PT-PT).
The following paragraph has more interesting information:
[…] MacCormack’s multivariate analysis showed three primary factors that lowered defect rate (early prototype, design reviews, and integration or regression testing at code checkin) and two primary factors that increased productivity (early prototype and daily builds).
Releasing a prototype to customers that is only 40% functionally complete increases productivity by 36% and adopting the practice of daily builds increases productivity by 93%. […]
Incremental and early delivery of working software is at the core of the effectiveness of Agile processes.[…]
I’d been discussing just this issue today with my company’s management team colleagues: how to increase productivity and lower defect rates? (yes, we’re looking for the silver bullet, I am well aware of this). This article gives us some very interesting feedback, however. We’ve been developing packaged components for SharePoint 2007 lately (here is one of them – link in PT-PT), and we’re considering structuring a Scrum-based process to handle these components. I found, surprisingly, very little existing books or documents on “modern” product development methodologies, encompassing from envisioning to production and support. Any recommendations would be welcome.
I still haven’t finished reading the article, so I’ll post more when it’s done.
Recently
the time had come to upgrade my MP3 player. For Christmas I had gotten a Video
iPod from my wonderful wife, but it was stolen a short time later from my truck and
I’ve been without a portable MP3 player since then. Well a new client was suddenly
a 45 minute commute, one way, and that sealed the deal that it was time to get something
which I could use to travel with Audible books.
Enter the Creative Zen V Plus.
Having learned from my mistake, I was not going to spent another several hundred dollars
on a device, the goal was less than 100 dollars with the requirements that it play
Audible, store at least 1 gigabyte, and be reliable. The Zen V Plus more than
fit the bill, for just over $75 dollars you can get:
2 gigabytes of storage
FM Tuner
Audio Recorder (with Built In Microphone)
Line-In Audio Recorder
VIDEO player on 1.5″ screen (Low Res, but any video is a plus)
Simple and easy to follow interface
Now overall I’ve loved the device, but there are a few things I wish it did better.
The biggest is that a couple of times it has lost the place in my Audiobook when it
did an idle shutdown. You know, you pause because you need to focus on work
for a bit, and then hours later come back but in the meantime after 30 minutes of
no action it shutdown. This is to me somewhat unforgiveable, but I’ve been able
to work around it for the most part, hopeful a future firmware upgrade will address
this. Overall, 4 out of 5 stars.
Giving in to the fact that every blog should be able to tell you something about it’s
author, this post will serve as a bit of introduction to me and give you a little
bit of my history.
My name is Tim Rayburn, and I am currently employed as a Principal Consultant with
Sogeti and I ama Microsoft Most Valuable Professional (MVP) for BizTalk Server.
I’m fairly heavily involved with the Microsoft community, I am the President of the
Dallas BizTalk User Group, I commonly speak at user groups throughout Texas, Oklahoma,
and Arkansas as well as at conferences such as the Tulsa TechFest, Houston TechFest,
VSLive! Austin, Microsoft TechEd and the Microsoft SOA & Business Process Conference.
I grew up in New York City, moved with my family to Connecticut when I was entering
the 6th grade, graduated from Glastonbury High School and then after some community
college moved with my family again to the Dallas/Fort Worth area of Texas where I
reside still today even though much of my family no longer lives in this area.
I do not have a bachelor’s degree, but I have in the past attended Manchester Community
College (in Manchester, CT), and later the University of Texas at Arlington.
I still live in Arlington with my lovely wife Kate and ourAustralian Shepardnamed
Gandalf.
I am a certifiable geek, and unabashedly so. I own multiple gaming consoles,
play table top RPG’s, love board games of all sorts, and still have a weekly gathering
to play D&D (or whatever we’re playing at the moment) with my friends. In
the past I’ve also been deeply involved with a wonderful organization called the Society
for Creative Anachronism, but have not been active with them for many years.
I’m always happy to talk to folks in the community about their latest project or about
coming out to their conference, code camp, code mash, etc. Please feel free
to reach out at [email protected] if you
have questions or would like me to come out and speak.
Within BizTalk 2004 there are not such things as Physical Port and Logical Port. At first these terms started in several whitepapers, then they were “officialy approved” in BizTalk 2006 documentation. Why the Port was divided to Physical and Logical one?
As we try to understand what is “the Port” mean, we have to separate different things under this name. We have one name but different meaning in different contexts. For example, we create Port as a Port shape in Orchestration but it is not a real Port, but something that links us with “real” Port. The “real”, Physical Port works adapter and pipeline (or is it manage them? And this is a different story…) and exists as an independent artifact. By the way, looks like the “real” Port can create Instances (Or this is not a Port but some Messaging Agent? Or not a Port Instance but a Messaging Instance, isn’t it? This is a different story as well…)
We can crate the Port into the Orchestration, it is a part of this Orchestration, isn’t it? And we can create the Port independently with the BizTalk Explorer and the Administration Console. And we can see the Port list in the BizTalk Explorer and the Administration Console.
In this way, trying to differentiate the things in the Orchestration Editor and in the BizTalk Explorer were created terms the Logical Port and Physical Port. Logical Port it is a “Port-shape”, and Physical Port it is a “Full-featured, big” Port in the BizTalk Explorer.
What’s the problem with this model?
The problem is in terms.
Why both a Physical Port and a Logical Port were called the Ports?
Maybe because the BizTalk developers try to make the link between Physical Port and Logical Port as an implicit link. If it works well, we don’t need two different terms, all right. But it doesn’t work, the BizTalk experience is that the link between Physical Port and Logical Port usually an explicit link. For example, the publisher/subscriber pattern requests to separate these terms.
Sometimes hiding the internal mechanism is a way to decrease the model complexity. But in this case it was opposite. Endeavour to hide this mechanism is a way to create additional unnatural terms, to distort the real BizTalk architecture.
I will try to show how BizTalk architecture could be if I use slightly different term set. This model is more easy to me. It would be great to get your feedback on this model.
BizTalk MessageBox (= BizTalk-bus):
This term is used without change. All messages first come to BizTalk MessageBox. Messages are published. Then messages are passed to subscriber. BizTalk MessageBox workss as an Queue Server.
I’ll change term the Port.
Port is the thing linking BizTalk with outer world. Send Port sends information to the outer world. Receive Port receives information from the outer world.
I define the outer world as the different protocols and applications (or more precisely the APIs).
Now this is a new term, the Endpoint. OK, this is not a new term :), we can find it in the SDK to describe the Adapter sample and several low-level things. But this term is carefully hided by the BizTalk architects and documentation writers.
Now remember all those port-shape types in the Orchestration. How does it relate to this new model?
Say we create the Port shape in the Orchestration.
New Port: this creates an Endpoint (nothing about Port);
New Configured port / Specify Later : the same;
New Configured port / Specify Now : this creates an Endpoint, then a new Port with the Filter linking Endpoint of the new Port and Endpoint of this Orchestration. Here the BizTalk creators were tried to hide all this mechanism with Ports and Endpoints. And this is helpful in this case.)
New Configured port / Direct : this creates an Endpoint without Filter.
New Configured port / Direct / Routing between Ports… : creating an Endpoint and a Filter linking it with an Endpoint of the Port (Routing between this Orchestration and Port)
New Configured port / Direct/ Self Correlating : this creates an Endpoint and switch on the instance subscription mechanism.
New Configured port / Direct / To receive(send) message to(from) other Orchestration… : creating an Endpoint and a Filter linking those Orchestration and Endpoint (Routing between two Orchestration endpoints)
I’d say couple words about relationship of the old terms and new terms.
The old Port term is a secondary BizTalk artifact. From one side we can create the old port independently in the BizTalk Explorer. But the Orchestration Editor push us to look at the Port as an aftifact belonged to the Orchestration. And BTW, the port type could be saved only together with the Orchestration in assembly “belonged” to the Orchestration.
The old port is only the Port, the New Port is the combination of the Port and the Endpoint.
The old Orchestration can be coupled with Port, the new Orchestration does know nothing about Port.
“Endpoint” model:
The high-level artifacts: MessageBox, Ports, Orchestrations.
Endpoints: the high-level artifacts should be connected only through the Endpoints and MessageBox.
Port has only one Endpoint. Orchestration has one Endpoint or more.
One side of an Endpoint is always linked with the MessageBox. The other side is linked with a Port or an Orchestration.
Endpoint-Publisher transmits data TO the MessageBox.
Endpoint-Subscriber transmits data FROM the MessageBox.
This is not a new model, it was implicitly used in many BizTalk articles.
Here I’ve tried to use this model explicitly.
I’ve
spent a lot of time this summer traveling to various events and presenting my talk
“Introduction to C# 3.0” to people throughout the South Central area of the United
States. Well, it pains me to say I’m but one man, and there are way way way way to
many of you to reach through this manual process. Fortunately for me, there
are technological solutions to this problem : The Internet!
I’ve spent some time today recording my first of what I hope to be several webcasts.
These webcasts are made possible through the generation gift of a Camtasia license
from TechSmith. I’ve been a fan of Camtasia for
many years, and the latest versions are a joy to work with.
All of that said, following
this link to the Land of Oz and an Introduction to C# 3.0.
This is what I would like to see in HL7 v.Next. This entry I hopeserves to be launch pad for other entries. I have spent a great deal of time thinking over the following guideline in the HL7 standards, which are not followed in the BTAHL7 accelerator.
Ignore segments, fields, components, subcomponents, and extra repetitions of a field that are present but were not expected.
Let’s take a look at the current situation. You have all of these fields that are defined in the schema as required, and they are at various levels in the schema.
Here there is a obviously wrong implementation of the standard. If I don’t care about this, why is this element required, and why might it have to match a pattern and possibly have an enumeration that it needs to match against?
What I would like to do is four things initially:
which would automatically change the Target Namespace to this when I choose the Partner URI in the schema
It should be pretty easy to accomplish, shouldn’t it?
This is just something that I thought of this week while at MS-HUG. I do not doubt that there are many issues with my theory, but those three things would make implementing HL7 with BizTalkSO MUCH easier and bring Microsoft’s HL7 component much closer to the standard.
Send me an email thru my contacts page if you have more ideas.
Microsoft has released the developer edition of BizTalk 2006 R2 on MSDN. Along with Windows 08 RC0.
Anyone with MSDN access should now be able to access the software. Non-MSDN users can still access R2 but its a free trial version.
I'm not sure what the plans are for posting other editions on MSDN or what the time frame is.
Happy BizTalking!
Thanks to Tomas
Restrepo for pointing out that the Developer Edition of BizTalk 2006 R2 is now
up on MSDN. If you’re working with EDI and BizTalk server you seriously need
to check this out and realize what is coming your way.