temp deliver for IBF, part one!

 

While using a template with empty elements, structure is organized as follows:

-Metadata Scopes

-Entities

-Views

-Menu Item Definition

-Actions

-Relationship

-View Locators

-Ports [empty]

-Operations [empty]

-Transformations [empty]

-Schemas [empty]

-Translations [empty]

-Groups [empty]

 

When we add metadata information, we add 'SayHello' under Metadata Scopes. It's reasonable, because we have the web service at "http://localhost/IBFSimpleSolution/SayHello.asmx". One purpose of the metadata here is for rendering that service. (am I using the correct word 'rendering'? Is it a right understanding? Not for sure, But I think so for now)

 

 

Remember in the IBFSimpleSolution, we defined a Friend class and a GreetingMessage class. They seems to be in the equal level, but here, they belongs separately, Friend in Entity and GreetingMessage in View. Why? In my point of View, there is misunderstanding here. As I illustrated above, what we're going to render here is the service represented by "http://localhost/IBFSimpleSolution/SayHello.asmx", instead of the classes we created at the server side. (we can take that as a reference, as it may represent the business objects in LOB, while the concern should be from the service aspect)

 

Ok, one question. "why it chooses 'Friend' as an entity and GreetingMessage As the view?" Here is a possible answer of my own. Bear in mind that we created one SayHello service with two operations: GetGreetingMessage & TestGetGreetingMessage. The second one is for testing, so let's focus on the first one. Let's see the definition of GetGreetingMessage.

 

Public GreetingMessage GetGreetingMessage(Friend aFriend){…}

The return type is GreetingMessage which is some kind of representation of aFriend. And aFriend is of Friend type which is the LOB oject in this case. because a "Friend"
object will be used as the starting point for invoking IBF Services. And The name of the friend can also be used to build a greeting message. Optionally, the name of the friend can be used to decide the type of message to be returned. How about the GreetingMessage Views? In the "Greeting Service" application, each Friend entity would have a greeting message associated with it. Hence, we shall define a view named "GreetingMessage". So the relationship between entity and view seems a little bit clear. Does it means that this kind of structure interprets the input and output direction of a procedure (service operation)? what is the truth? Don't know yet. Later research should be focused on more about the term such as 'Entity', 'View', etc.

 

For now, we've already know that, in the 'SayHello' metadata scope (which is used for rendering the service), we have the 'Friend' as our entity, and 'GreetingMessage' as the view of 'Friend'. What else do we know? Nothing.

 

It doesn't mean anything If we just stop here. We even don't know what "Friend" and "GreetingMessage" are. We need do something more. In the 'Beginner's reference 13/64', it says "The next step is to create Port elements to store the XML Schema definition for the Friend Entity and the GreetingMessage View." So, here, one question again. "what is a port? What does port really mean?" It's quite intuitive that when you want to input something, you should use the 'port', and if you want to get something, you should use the 'port'. Both 'ports' are standardized.  It looks quite reasonable to think of 'port' like this, but is it really true? I am not sure. Let's check it later.  For now, I just assume that the 'FriendPort' must be filled with an object which suits for the schema definition . And from the 'GreetingMessagePort', there must be a GreetingMessage object qulified by related schema definition. But it doesn't mean that the 'FriendPort' and 'GreetingMessagePort' already have set up some kind of relationships between 'Friend' entity and 'GreetingMessage' View for their similar names. I think you can also call them 'port1' and 'port2'. Let's see later if they would be binded or connected.

 

Now, as the reference illustrated, we need to set up the Schema elements corresponding to each of the ports created above. I was always wondering why we still need to create schema elements if we already have the schema definition for ports. Truly, you can see that, the schema definitions of ports are referenced in the schemas elements which means they are not duplicated information. But still why? Why do we need that? I'll think about it later.

 

(Oh, gush. I see it now. After you define the schema elements, we set up the 'Friends' DefaultReferenceSchemaName to the newly defined element. That's something like binding, and it's logically true because, there should be a binding. Imagine that there is a service. Of course, the operation parameter's type should be bound with the parameter itself. That makes sense. Got it! Conclution, schema elements are acting as a binding role.)

 

All right, now, as the author said in the reference, "at this stage, the Metadata contains all the information related to the data objects that will commute on this Virtual Information Bridge connecting Office applications to our Web Service". Let's make a review what we've already got.

 

1. entity and view (reference by the service operation)

2. ports (how to access entities and views)

3. schema element (not dup, but for what are we going to use it?  Binding! And contrarily, if we have schema, why do we use ports storing schema definition there? Is it something about the 'direction'? Input? Output? Maybe. Also binding)

4. Binding 'entity' and its type using schema, and the same to 'view'

 

And….Yes. I think that's the information we need to describe the service. So, now we have the outline the metadata structure which is suitable for describing and holding the service information.

 

Till now. I think all that mentioned above is about how IBF organizes the metadata in the rendering level. (how it describes a 'service',  'service function', a 'procedure', something like a CONTAINER)

 

Next, I will say something about the metadata organization in the operational level (as I name it).

 

Now, we already have the container (the metadata in the rendering level), I don't know if it locates at the client side or the server side. I think the metadata I've mentioned till now locates at the client side, here is a sample diagram for that.  What will the server side metadata (or metadata service) look like? I wondered.

 

Ok, let's move on. I remember in Java. When you've got a web service. It's something like the URI: "http://localhost/HelloWorldService/HelloWorld.WSDL". After you import the service, you can create a new service instance in your code to access the operations that are provided within the service. And here in IBF solution, there is a similar way. To access the service provided in the URI "http://localhost/IBFSimpleSolution/SayHello.asmx", you need to create a port for that (something similar with the service instance in JAVA). 

 

When you get the service in the port, now it's time for you to define the desired operations. In this case, it is the GetGreetingMessage operation. Oh, My Gush! I made a mistake. Here, the operation GetGreetingMessage is still used for describing the service. In java, when you create a new service instance (eg. myService), you can directly call directly 'myService.GetGreetingMessage'. In IBF (at least here), things are a little bit different. You need to define an operation and bind it with the service operation which is represented using the SOAP Action.

 

All right, Now, I can say that, we have already well prepared for describing the service. Can I now call it as the 'Rendering level' now? Probably…..