BizTalk: The Endpoint model depreciates the Physical and Logical Ports

by | Sep 27, 2007 | BizTalk Community Blogs via Syndication

One of the difficult part of BizTalk to understanding is a Port. Particularly I mean, Physical Port and Logical Port.

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.

There are two kind of the Endpoints: Endpoint-Publisher (EP) and Endpoint-Subscriber (ES).
Ports and Orchestrations use the Endpoints to interact with MessageBox.
EP sends data to the MessageBox. EP sends all messages to the MessageBox, and it doesn’t care of the consumers of the messages. If there are any at all.
It’s the duty of the MessageBox to pass the data to the subscribers or suspend it.
ES receives the data from the MessageBox. It receives only subscribed data. A filter on the ES is created for this purpose. It takes responsibility of data passed from the MessageBox to the ES.
Endpoint always has only two sides.
One side is always linked with the MessageBox. The other is linked with a Port or an Orchestration.
Orchestration receives data from the MessageBox through the one kind of Endpoints (the ES) and sends data to the MessageBox through the second kind of Endpoints (the EP). The Orchestration has not any others links with the MessageBox, the Ports, the other Orchestrations, it only has links with the MessageBox through the Endpoints.

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.

Now the Port is the first-level artifact, independent of the Orchestration.
Now the Port and the Orchestration are terms the same level, the same importance.

“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.

Webcast – Introduction to C# 3.0

by | Sep 27, 2007 | BizTalk Community Blogs via Syndication

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.

HL7 v.Next

by | Sep 27, 2007 | BizTalk Community Blogs via Syndication

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:

  1. When I start up a new project where I am going to need to create a new trigger message for a data source, I don’t want to have to hack into the schemas to change the target namespace for the base schemas (datatypes, segments, and tablevalues). Why can’t there be a way from within the schema to define a party that this message is defined to, and it have it derive a new definition off ofthe base schemas for that party?In the BTAHL7 Configuration explorer, it will automatically make the targetnamespace coincide with the party name. Something that looks like this:

    which would automatically change the Target Namespace to this when I choose the Partner URI in the schema

  2. I would like to open up the schema and be able to do a ‘Select All’ and then with the CTRL button go and de-select the fields I care about, and with the right click make all of the fields optional and override the data type to ST or TX with no enumeration or patterns.
  3. I would like to be able to see the enumeration lists for the base schemas even though I am looking at an inherited schema. When I click on PID 2.5.0 in the ORM^O01 schema, because it has imported that definition, I don’t see the enumeration. I have to go and open up the tablevalues schema and search thru it to change those valuesto have to recompile and redeploy. Why can’t I first see the values and second override theexisting values with values I know are going to come in, sometimes less, sometimes more values.
  4. The last thing is that everysegment, sub elementshould have the optional Trailer to consume additional data that might be there:

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.

Terracode Book Server – Server on a bookshelf

Terracode Book Server – Server on a bookshelf

by | Sep 26, 2007 | BizTalk Community Blogs via Syndication

Site TerraCode.com tells about a project to create a Windows Home Server based system that looks like a book and quitely sits on a bookshelf while serving music and video to PS3 or XBox360.


TerraCode Book Server
with permission from (c) Terracode.com


The most fun part of it is that it’s “Do-it-yourself” project with details on the parts and steps to perform. Looks real cool to me. I probably would not put clear plastic on top – I am not that concerned that guests will try to stick their fingers into the insides — but otherwise I’d love to create one for myself, if I would have time. Hats off to Terracode.com for a beautiful idea!


TerraCode Book Server %u043f%u043e%u0442%u0440%u043e%u0445%u0430
with permission from (c) Terracode.com

ESB Guidance August 2007 (CTP3) Release

by | Sep 26, 2007 | BizTalk Community Blogs via Syndication

 

The third CTP release of the ESB Guidance has been posted to CodePlex.

From Marty Wasznicky’s email, some of the new features include:

  • New Resolver and Adapter Provider Framework provides messaging-level and end point resolution for:
    • UDDI
    • WS-MetaDataExchange
    • Business Rules Engine
    • XPath
    • STATIC
  • Messaging-Level Transformation services (using the new Resolver Framework) allows BizTalk maps to be executed in pipelines based on the following resolution methods:
    • UDDI
    • WS-MetaDataExchange
    • Business Rules Engine
    • XPath
    • STATIC
  • Request-Response support for on and off ramps (partial)
  • WCF Adapter integration
  • UDDI publishing and query service
  • BizTalk runtime query service
  • New Dynamic Resolution sample
  • Third-party SOA Management and Governance integration:
  • ESB Guidance documentation in CHM format

Check out the new release at http://www.codeplex.com/esb.

MS-HUG Day 2

by | Sep 26, 2007 | BizTalk Community Blogs via Syndication

Well, unlike day 1, I was unable to dedicate a whole lot of time to the convention.

The only thing that I can attest to is that my discussion with Mark Singh brought some interesting ideas for the components of SEMRHIO

I also met with Eric Battalio again where I was grilled for more about an hour and a half. “Hands around my neck squeezing hard andforcing me to tell how documentation can be better.” Or something like that 🙂

Actually it was a great discussion, we discussed things that I did not like about the documentation, above and beyond my Documentation Rant.Hopefully something will come out of that, maybe some enhancements to the core product, some changes to the coreMSDN site, and other things. I hopethat documentationwill no longer be a second rate citizen in the eyes of Microsoft. My feelings that if thereis betterdocumentation (some documentation is better than others granted), but how we, the unenlightened, actually interact with thedocumentationthatmore resources of MS could be dedicated to making better software and not so many resources dedicated to supporting it.

I once again brought up that I use Google almost exclusively compared to Live Search because of the hit ratio.